说说操作系统的进程ID和MongoDB _id主键

说说操作系统的进程ID和mongoDB _id主键

在分布式系统中，数据之间的合并成为常态，单机系统中的数据库可以使用自增加ID作为主键，简单省事。可是在分布式系统中，数据合并存在了巨大的困难。数据主键的选取就成为了很大的问题。一个常规的解决方法就是使用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被空闲出来。空闲出来的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~~

尹曙光