增量ID处理

业务需求：

1:    IM的msgId

2:    商城的orderId

3:    挂号Id

解决1: 

 *  * SnowFlake 算法，是 Twitter 开源的分布式 ID 生成算法。
 *  * 其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 ID。
 *  *
 *  * 这 64 个 bit 中，其中 1 个 bit 是不用的，然后用其中的 41 bit 作为毫秒数，
 *  * 用 10 bit 作为工作机器 ID，12 bit 作为序列号。
 *  *
 *    0 | 0000000*****00000  |  10001  |  11001  |  0000 00000000
 * 1）第一个部分，是 1 个 bit：0，这个是无意义的；
 * 2）第二个部分，是 41 个 bit：表示的是时间戳；
 * 3）第三个部分，是 5 个 bit：表示的是机房 ID，10001；
 * 4）第四个部分，是 5 个 bit：表示的是机器 ID，1 1001；
 * 5）第五个部分，是 12 个 bit：表示的序号，就是某个机房某台机器上这一毫秒内同时生成的 ID 的序号，0000 00000000。
 */

解决二：

美团的Leaf-segment对数据库自增ID方案做了如下改变：

1）原方案每次获取ID都得读写一次数据库，造成数据库压力大。改为利用proxy server批量获取，每次获取一个segment(step决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力；
2）各个业务不同的发号需求用biz_tag字段来区分，每个biz-tag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biz_tag分库分表就行。

原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。