我建議您使用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
這就是我的想法。