我建议您使用ETS Tables
。我认为Array方法效率不够高。通过在应用程序后端中公开创建的ETS Table
,任何进程都可以在需要时立即查找项目。在当前较新版本的erlang中有ETS Tables
有并发访问的能力。
%% Lets create a record structure
%% where by the key will be a value
%% in the array.
%% For now, i do not know what to
%% put in the field: 'other'
-record(element,{key,other}).
create_table(TableName)->
Options = [
named_table,set,
public,
{keypos,2}, %% coz we are using record NOT tuple
{write_concurrency,true}
],
case ets:new(TableName,Options) of
TableName -> {success,true};
Error -> {error,Error}
end.
lookup_by_hash(TableName,HashValue)->
try ets:lookup(TableName,HashValue) of
Value -> {value,Value};
catch
X:Y -> {error,{X,Y}}
end.
使用这种安排,您将避免产生来自单个gen_server持有数据的
A Single Point of Failure
。这些数据是许多流程所需要的,因此不应该由一个流程来保存。这是任何时候只要需要查看就可以通过任何进程访问的表格。
数组中的值应该转换为格式为
element
的记录,然后插入
ETS Tables
。这种方法的
优点
1.我们可以创建许多
ETS Tables
尽可能
2.一种ETS表可以处理许多比数据结构以上的元素,例如列表或具有低得多的可比存储器消耗的数组。
3.
ETS Tables
可以同时访问的任何进程范围内,因此你将不需要一个中央进程或服务器来处理数据
4.一个进程或gen_server持有这些数据,意味着如果其妥协(由于一个完整的邮箱),它将不可用,因此需要该阵列的进程将不得不等待这一台服务器重启或者我不知道......
5.通过发送请求消息和制作来访问阵列数据相同数组的副本到每个需要它的进程不是“Erlangic”设计。
6。最后,
ETS Tables
所有权可以从流程转移到流程。当拥有的进程崩溃时(只有gen_servers可以检测到它们正在死亡[注意这一点]),它可以将
ETS Table
转移到另一个进程接管。点击这里:
ETS Give Away
这就是我的想法。