分散式儲存 - MUD Game

做法不只一種，這裡只是舉例。

比較直覺的想法是，一個 .c 檔，其內存的資料透過像是
save_object 函數的處理後，會產生一個 .o 檔。

那假設以家族系統為例，經年累月下來，必定會產生很多
的家族，以及很多的家族成員資料，那如果這些資料都儲
存在同一個 .o 檔裡頭，就會使得 .o 檔過於肥大。

.o 檔肥大有時會產生兩個問題

一、.o 檔的載入 loading 過重

二、.o 檔的意外損毀(比方早期大於 198K 時)

那麼，就「家族資料」來說，因為儲存的資料主體多半是
玩家ID，則以玩家ID開頭做分流就變成直覺的想法:

laechan 這個玩家的家族資料，儲存在 group_l.o 裡

=> 設計一個 group_l.c，使它在做 save_object 時會
產生 group_l.o

=> 即 laechan 的家族資料是 set 在 group_l.c 裡的

則 group_l.c 的檔案內容如下

group_l.c
==================================================
mapping group_data=([]);

void create()
{
::create();
seteuid(getuid(this_object()));
if(file_exists(base_name(this_object())+".o"))
restore_object(base_name(this_object()));
}

// 呼叫這個函數時會做儲存
int save_room()
{
save_object(base_name(this_object()));
return 1;
}

mapping query_group_data(string names)
{
return group_data[names];
}
.
.
================================================

而其它的 group_X.c 其檔案內容也一樣(所以可以用繼
承來省略)。

然後，設計一個 group.c，讀取資料都透過它，底下是
程式片段

group.c
================================================
// 讀取某一玩家資料的例子
mapping query_group_data(string names)
{
object group_ob;

// 去找跟該玩家ID字頭有關的 group_X.c
if(!catch(group_ob=find_object(__DIR__+"group_"+names[0..0])))
return group_ob->query_group_data(names);
}

// 能讀取自然就能 set, del, add, ..
================================================

上面的意思可用底下的圖示來表示

query
────→ 判斷字頭 找到物件
set ┌─────┐ ┌─────┐
Request 方 ────→ │ group.c ├→┤ group_X.c├←存取對映.o檔
modify └─────┘ └─────┘
────→
.
.

這樣就可以把一個 group.o 檔，分拆成 36 個 .o 檔
，分別是 group_0.o、group_1.o、...、group_z.o。

底下是一個分拆後的實例:

> ls *.o
1 group_data_0.o 1 group_data_9.o 3 group_data_i.o 5 group_data_r.o
1 group_data_1.o 9 group_data_a.o 4 group_data_j.o 16 group_data_s.o
1 group_data_2.o 7 group_data_b.o 6 group_data_k.o 5 group_data_t.o
1 group_data_3.o 9 group_data_c.o 8 group_data_l.o 1 group_data_u.o
1 group_data_4.o 8 group_data_d.o 7 group_data_m.o 1 group_data_v.o
1 group_data_5.o 5 group_data_e.o 5 group_data_n.o 4 group_data_w.o
1 group_data_6.o 5 group_data_f.o 1 group_data_o.o 1 group_data_x.o
1 group_data_7.o 5 group_data_g.o 6 group_data_p.o 3 group_data_y.o
1 group_data_8.o 6 group_data_h.o 2 group_data_q.o 2 group_data_z.o


分拆的好處是..

一、每一分拆檔如上所示，檔案內容都很小，處理速度快。
資料不需集中儲存於同一個地方。

二、所有的家族資料，會在不同的時間載入。通常是有玩家
去呼叫到時，比方剛 shutdown 完，某家族族長去list
了自己的家族，那 group_X.c的部份只會載入跟它家族
有關的成員ID字頭的物件

三、當我們變動了一筆家族資料時，只需去動到跟該筆資料
有關的 group_X.o，其它的 group_X.o檔不會動到。

四、分拆後可儲存的家族資料可變多，底下是實例:

> list -easy
全部共 574 個族群、3714 個族員.

五、萬一發生資料損毀的情況，可避免全面性的資料損壞。


至於家族(或幫派)資料為何不儲存在玩家身上，而要另外儲
存呢？這是因為這樣一來即便家族裡頭有玩家離線，也不會
妨礙家族資料的存取及變更。當然實際上即便資料是存在玩
家身上，透過一些特殊做法同樣能不妨礙家族資料的存取及
變更。只是我不想去實作那些方法。

以上一點心得。


Laechan@Sanc

--