今天看了朋友blog的一篇文章，也来谈一下ID生成算法。
对于一个大型系统，数据库ID的选择非常重要。以前做的一套系统，选择了GUID类型，导致数据库空间占用很大。记得还专门搞过一次会议讨论优化方案，可惜过于拘泥于分布式数据集中时对唯一性的要求，没有放开思路。
在开发新的系统时，这作为一个基本设计点被首先考虑。其实在编码上做点手脚，long型的ID也可以满足分布式数据ID唯一的要求，方法就是把SiteID作为ID的一部份。我们的ID规则是：SiteID(2位) + yyyymmdd(8位) + 流水号(7位)。7位流水号可以满足每天1000万个ID分配，并且算法上允许流水号溢出。这并无本质问题，无非是看上去应该在某一天分配的ID实际是在前一天分配而已。
IDGenerator在应用层提供，采用low-high算法，只有内存中位于low区段的ID号均被取走后，才需要一次数据库访问以便更新high。这是获得最佳性能的关键。例如，配置low区段大小为10万，则一个IDGenerator在分配10万个ID后才需要访问一次数据库。high的更新记录于数据库中，这意味着允许分布的App层多个IDGenerator并发使用。当然，你必须小心地编写数据访问代码，已确保独占更新。
最终的方案既获得了存储空间的节省，同时比GUID分配更快。