需求

表面上看，就是服務器崩潰重啟后，還能將關鍵數據恢復到崩潰前的那一刻，達到這種效果，角色的金錢、裝備和道具都能恢復到崩潰前的狀態，不會有嚴重的損失。

先假定所謂的關鍵數據都有哪些，以及這些數據有什么特性：

1.         角色基本屬性，比如姓名、年齡、性別、HP、MP和money什么的。

屬性數據頻繁修改，讀寫性強。

2.         角色物品，比如裝備、道具、技能和寵物等。

物品數據有歸屬性，總是屬于某個角色，或者無主被刪除。這種數據的歸屬性容易轉移，經常需要分配和釋放。

這些關鍵數據的數據結構通常是這樣子的：

struct Item

{

int id;

int belong;

int data[32];
};

struct Cha

{

  int id;

  int atb[ 128 ];

  Item* item_head;

};

能滿足易于修改，易于分配和釋放，并能像上面的數據結構那樣組織起來，只有內存能做到。但是，在崩潰重啟后，普通內存屬于不可恢復資源，因此就要考慮共享內存了。

共享內存

共享內存其實是文件，所以會有“指針變量改成偏移變量更合適”的這種想法，但是我期望能像操縱普通內存上的數據一樣操縱共享內存上的數據，指針是必須使用的。

另外，在需求上，角色的屬性數據和角色的物品數據都是數以千計、面臨不斷的分配和釋放的，而在文件上管理和維護離散的小塊的數據空間，不能像對付普通內存那樣直接。

因此，要想用共享內存實現上述需求，需要一個方案。

方案

要靈活的分配和釋放空間，就要打造一個基于共享內存的內存分配器，不僅如此，還必須能在崩潰后從共享內存文件中重建這個分配器。

1.      MemRecord

分配器用來記錄一次內存分配的相關信息，其結構如下：

----size | type id | data buffer----

其中size是data buffer的長度；

data buffer是應用戶請求分配的內存，其地址作為分配結果的返回值；

type id則表明了這段內存的用途。

通過MemRecord，一個分配器的基本管理元素就有了。

每次用戶請求內存，都相應的分配一個MemRecord，包含被請求的內存，和記錄這段內存的大小和用途；

每次用戶釋放內存，只要對內存指針做一下偏移，就能得到相應的MemRecord，然后把MemRecord放入空閑隊列，留待下次請求分配。

MemRecord里最重要的就是type id，直接關系到是否能從共享內存中恢復分配器的狀態。系統目前保留2個id值：

0-       表示這段內存是主內存，在沒有空閑的MemRecord的情況下，用戶請求的內存都從這里分配出去；

1-       表示這段內存是已經分配過并被釋放了的，標記為1的MemRecord總是放進空閑隊列中。

其他id值，則是留給用戶使用的，用戶必須指明他所請求的內存是什么類型/用途，以便于崩潰以后的數據恢復。

比如，struct Item的type id可以是10，struct Cha的type id可以是11。

通過MemRecord和type id，分配器就可以從共享內存中恢復狀態，并把已分配給用戶的內存交給用戶，由用戶恢復數據的邏輯意義。

2.      MemChunk

服務器上的角色和物品數量不少，因此共享內存通常都會一下子分配得比較大，比如200M。但是并沒有必要一開始就把200M的文件映射到進程的內存空間上，我們可以每次只映射一小部分，如20M，這每次20M的部分，就是MemChunk。

一個MemChunk最初會被初始化成一個type id值為0的MemRecord，即主內存，隨后用戶不斷的申請內存的分配和釋放，MemChunk就分成了一連串的MemRecord集合。

一個分配器的重建，其實就是旗下所有MemChunk的重建；而MemChunk的重建，就是區分不同的MemRecord的過程。

3.      FileHeader

再次強調共享內存其實是一個文件，既然在文件上有組織的保存數據，最好相應的有一個文件頭描述這種組織。

在當前方案下，文件頭至少要包含以下幾條，以便于從整個共享內存中重建分配器：

1.         文件大小

2.         每個MemChunk的大小

3.         已經分配出來的MemChunk的數量

因為FileHeader的基址和大小都是固定的，一開始就可以讀取的，因此是保存分配器整體信息的不二選擇。

實驗程序

這一篇的表達能力有限，我也看出來自己完全沒法把這個東西講解清楚，所以，代碼才是最好的表述。

點擊這里下載代碼

以下的程序按其啟動順序逐個簡述：

1.         test_daemon，共享內存守護進程。啟動后創建一塊200M的共享內存，然后死循環；

2.         test_write，啟動后讀取200M的共享內存，然后創建一批角色數據和物品數據，并隨機的刪除這些角色和物品；

3.         test_read，啟動后讀取200M的共享內存，并從中恢復test_write分配出來的角色和物品。

test_write和test_read在最后都dump了當前的角色和物品到文件上，比較2個文件就能判斷方案是否正確了。

遇上的問題

1.         字節對齊問題

說來慚愧，計算MemRecord中到最后一個變量m_data前的大小，我居然用sizeof(MemRecord)-1，結果出錯了。

因為存在字節對齊，所以大小應該是m_data的偏移量才對。

2.         MapViewOfFile的偏移量對齊問題

如果不是用到multi view，根本不用關心這個問題。每一個view的起始偏移地址，不是隨意的，必須是某個值的整數倍，我這里是65536。具體的值，通過SYSTEM_INFO. dwAllocationGranularity讀取。