說說操作系統的進程ID和MongoDB _id主鍵

說說操作系統的進程ID和MongoDB _id主鍵

在分布式系統中，數據之間的合并成為常態，單機系統中的數據庫可以使用自增加ID作為主鍵，簡單省事?？墒窃诜植际较到y中，數據合并存在了巨大的困難。數據主鍵的選取就成為了很大的問題。一個常規的解決方法就是使用GUID作為主鍵。GUID作為數據庫主鍵也有兩個不太好的地方，一是，有些數據庫系統沒有GUID類型，只好用字符串替代，字符串長度為32位（16Byte字節的16進制表示）。二是Guid沒有順序規律，在排序的時候效率很差。

在MongoDB中，每個文檔都有一個_id，采用了一種生成算法，可以保證在分布式的情況下，產生不重復的ID。該算法中有一部分是進程ID。占用兩個字節，共支持進程編號65535個（0xFFFF）,我們查看操作系統API（Windows和Linux）的時候發現，進程ID是一個整數，那么MogonDB的算法會不會有問題呢？

在Linux中查看系統允許的最大進程ID：

# cat /proc/sys/kernel/pid_max
32768

可見，Linux中最大允許的進程ID為32768。另一個問題，進程ID整數，并且是遞增的，這個數夠用嗎？

實際上，Linux中不可能同時跑這么多個進程。當一個進程結束時，進程的ID被空閑出來?？臻e出來的ID也沒有被Linux系統及時回收，而是當PID持續增加到最大值的時候，才開始回滾。即在新建進程的時候，查找可用的進程號，找到后把該進程號分配給新的進程。

Linux沒問題，那么Windows呢？

Windows中的進程ID實際上是一個全局句柄表PspCidTable的偽索引。為什么是偽索引，請看以下的描述：

一個進程的句柄表包含了所有已被該進程打開的那些對象的指針。對象句柄是用來檢索句柄表的一個“偽索引”。對于句柄表機制，achillis<<Windows句柄表>>系列文章已經分析得很透徹了，只是對“句柄以4為步進”來源不明。經查，根源如下：

typedefstruct _EXHANDLE

{

union

{

 struct

 {

  ULONG TagBits:2;

  ULONG Index:30;

 }

 HANDLE GenericHandleOverlay;

 #define HANLE_VALUE_INC 4

 ULONG_PTR Value;

}

}EXHANDLE,*PEXHANDLE;

此結構正是用來定義句柄類型。低2位TagBits為標志位Windows用于其它用途，故句柄值低2位對其作為句柄表索引本身無意義，所以等于4的倍數。有了以上分析，自然，在用句柄值為索引取句柄表項時，句柄值必須/4。因此程序中用到的句柄值并不能直接用來索引句柄表，也就有了“偽索引”說法。

Windows的全局句柄表有65535個位置，所以windows系統最多只能提供65536/4=16384個可用的句柄數（如果在程序中不停的打開進程ID卻不及時關掉不用的進程句柄,會導致系統變慢程序崩潰）。

如何在Windows下查看進程ID：

1.按ctrl+alt+delete鍵調出任務欄管理器，依次點擊查看----選擇列---在彈出的窗口中在PID前面打勾，帶你及確定，在任務欄管理器的進程中PID下面的就是該進程的進程號！

2. 開始---運行----在對話框中輸入：cmd 然后回車---在彈出的控制臺中輸入 tasklist就會出現所有進程，同樣PID下面的是進程號！

好了，MogonDB的主鍵中的進程表示方法在Windows中也是沒有問題的。

再說題頭，MongoDB中的主鍵聲稱策略還是很有效的。MongoDB主鍵表示如下：

4位：時間戳（精確到秒）
3位：機器名哈希值
2位：進程ID
3位：自動增加的順序值。

在這個方案中，可以很好的借鑒作為我們自己信息系統的數據庫主鍵的生成策略。但是有一點筆者需要做一下標注，3位機器名哈希值可能會重復。

在一個環境中，如果可以保證機器名不重復的話，也很難保證機器名哈希之后的三個字節不重復。當然在機器只有幾臺或十幾臺的情況下，這個沖突的可能性比較低。

即使機器名哈希值重復了，碰巧了兩臺機器的進程ID一致，并且在同一秒內，碰到了統一個自增順序值，這樣產生的ID才會重復?？垂?，您可以計算一下這個概率有多低。

參考文獻。

http://www.newsmth.net/nForum/#!article/KernelTech/59502

http://www.cnblogs.com/Thriving-Country/archive/2011/09/18/2180143.html

http://zhidao.baidu.com/question/147564693.html

http://blog.csdn.net/scorpio3k/article/details/5835614

~~THE END~~

尹曙光