都说用ets 写一个cache 太简单, 那就简单的搞一个吧, 具体代码就不贴了, 就说说简要的需求和怎么做(说设计有点虚的慌).
需求场景
>> 查询系统,对于主存储而言,一次写入多次查询
所以,cache 需要能实现:
UserA 在查询 RecordA 时, UserB 也需要查询RecordA, 就让UserB waiting, 待UserA 查询完成之后, 共享RecordA 的查询结果.
>> 限制单个ets 表的内存使用量,先进先出
那就需要个queue,求 queue length 的频率较大,考虑下RabbitMQ 的 lqueue
>> 限制单个Record 的内存使用量, 如果小于limit,就保留Record,反之,不保留
>> 辅助性的一些feature (reset memory limit, clean all cache, get cache informations, delete single cache ...)
Query 状态
既然UserA 在查询RecordA 时,若UserB 也需要查询,就让UserB等待.就需要保存查询的状态, cache 的结构:
{QueryTerms, QueryStatus, WaitingUser, QueryResult}
QueryTerms 即查询条件
QueryStatus 是查询状态, 正在处理查询为handling, 查询已经处理完毕为handled
WaitingUser 是等在查询的user, 若QueryStatus 为 handling, 就将 'erlang:self()' append 到WaitingUser, 若QueryStatus 为handled, QueryResult 即为需要的查询结果
QueryResult 查询结果
FIFO queue
cache 不能无休无止的消耗内存, 需要加一个memory total limit, 当超过limit 后, cache 就FIFO .
这样的话, gen_server 进程除了维持ets table 外, 还需要维护queue , 然后refresh queue len 和 memory .
refresh memory 的简单代码:
handle_info({refresh_mem}, #state{queue_mem = UNQueueMem,
queue = Queue,
etstable = EtsTable} = State) ->
QueueMem = UNQueueMem * 1024 * 1024 / 8,
case catch ets:info(EtsTable, memory) of
Mem when erlang:is_integer(Mem) ->
if
Mem > QueueMem ->
case lqueue:is_empty(Queue) of
true ->
{noreply, State, ?HIBERNATE_TIMEOUT};
_ ->
{{value, OldQueryTerms}, NewQueue} = lqueue:out(Queue),
delete_old_ets(EtsTable, OldQueryTerms),
erlang:send(erlang:self(), {refresh_mem}),
{noreply, State#state{queue = NewQueue}, ?HIBERNATE_TIMEOUT}
end;
true ->
{noreply, State, ?HIBERNATE_TIMEOUT}
end
;
_ ->
{noreply, State, ?HIBERNATE_TIMEOUT}
end;L1 处的 queue_mem 为 total memory limit
若超过 total memory limit 且queue 不为空, 就 queue out 并在ets table 中将Record 删除.
single cache limit
既然要作单条Record 内存使用量的限制, 就需要知道single Record 的内存占用量, 最简单的办法是:
ets:info(T, memory) ---> ets:insert(T, R) ---> ets:info(T, memory)
然后计算前后memory 的差值.
在"单进程写入/删除, 多进程读"的模式下,此方式不会出现什么问题.
多进程读写
"单进程(gen_server 进程)写入/删除,多进程读" 的方式应该是比较合理的模式,但是这种方式的弊端也显而易见:效率低,在重负载的单进程的压力增加,进程message queue 堆积,进而出现问题.(即便是能做好隔离,同样会对系统产生影响)
那多进程读写的方式呢?
多进程读写,然后将refresh memory的工作交给gen_server 进程. 这种方式,对于大多数功能,是没有问题的(得益于ets 的特性),但是对single cache limit feature 的实现,就会出现很大的影响.single cache limit 需要对ets 做三次操作:
ets:info(T, memory) ---> ets:insert(T, R) ---> ets:info(T, memory)
多进程读写的话,就很难避免在这三次操作中,穿插 delete/insert 操作, 就很难保证正确性.
这个时候, 就需要safe_fixtable 操作.在网上关于safe_fixtable 的资料比较少, 在此收集一些:
1, 坚强blog (http://www.cnblogs.com/me-sa/archive/2011/08/11/erlang0007.html)
2, google group 的讨论(https://groups.google.com/forum/#!topic/erlang-china/OnwM5uPVjmI)
其他功能
其他的feature 就没什么好说的了, 堆码而已.