分布式商城项目07分布式唯一ID实战

　　1背景
　　在电商业务系统中，对ID生成的系统的可用性要求极高，如果生成系统不稳定，大量依赖ID生成系统，比如订单生成等关键动作都无法完成。一般情况下，我们使用数据库自增主键作为数据ID，但是在大量数据的情况下，尤其是在分库分表之后，这样就会出现ID大量重复，难以满足业务的需求，此时一个能够生成全局唯一ID的系统是非常必要的。概括下来，那业务系统对ID号的要求有哪些呢？
　　全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
　　趋势递增、单调递增：保证下一个ID一定大于上一个ID。
　　信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。
　　2常见的分布式
　　2。1UUID
　　UUID（UniversallyUniqueIdentifier）的标准型式包含32个16进制数字，以连字号分为五段，形式为844412的36个字符，示例：550e8400e29b41d4a716446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID规范AUniversallyUniqueIDentifier（UUID）URNNamespace。
　　优点：
　　性能非常高：本地生成，没有网络消耗。
　　缺点：
　　不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
　　信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
　　ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用：
　　2。2雪花算法及其衍生
　　这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，Snowflake是Twitter开源的分布式ID生成算法。Snowflake把64bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64bit分别表示如下图所示：
　　第0位：符号位（标识正负），始终为0，没有用，不用管。
　　第141位：一共41位，用来表示时间戳，单位是毫秒，可以支撑241毫秒（约69年）
　　第4252位：一共10位，一般来说，前5位表示机房ID，后5位表示机器ID（实际项目中可以根据实际情况调整），这样就可以区分不同集群机房的节点，这样就可以表示32个IDC，每个IDC下可以有32台机器。
　　第5364位：一共12位，用来表示序列号。序列号为自增值，代表单台机器每毫秒能够产生的最大ID数（2124096），也就是说单台机器每毫秒最多可以生成4096个唯一ID。
　　理论上snowflake方案的QPS约为409。6ws，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
　　Snowflake优缺点是：
　　优点：
　　毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
　　不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
　　可以根据自身业务特性分配bit位，非常灵活。
　　缺点：
　　强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
　　2。3Mysql数据库
　　数据库方案的优缺点如下：
　　优点：
　　非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护。ID号单调自增，存储消耗空间小。
　　缺点：
　　支持的并发量不大、存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID没有具体业务含义、安全问题（比如根据订单ID的递增规律就能推算出每天的订单量）、每次获取ID都要访问一次数据库（增加了对数据库的压力，获取速度也慢）
　　2。4Redis
　　通过Redis的incr命令即可实现对id原子顺序递增。
　　为了提高可用性和并发，我们可以使用RedisCluster。
　　除了高可用和并发之外，我们知道Redis基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。很明显，Redis方案性能很好并且生成的ID是有序递增的。
　　不过，我们也知道，即使Redis开启了持久化，不管是快照（snapshotting，RDB）、只追加文件（appendonlyfile，AOF）还是RDB和AOF的混合持久化依然存在着丢失数据的可能，那就意味着产生的ID存在着重复的概率。
　　2。5分布式ID微服务
　　从上面的分析可以看出，每种方案都各有优劣，在我们的商城系统中则基于美团的Leaf实现了自己的分布式ID微服务。我们先来看看美团Leaf方案。
　　Leaf这个名字是来自德国哲学家、数学家莱布尼茨的一句话：Therearenotwoidenticalleavesintheworld（世界上没有两片相同的树叶）
　　Leaf分别在MySQL和雪花上做了相应的优化，实现了Leafsegment和Leafsnowflake方案。
　　2。5。1Leafsegment数据库方案
　　Leafsegment方案，在使用数据库的方案上，做了如下改变：
　　原MySQL方案每次获取ID都得读写一次数据库，造成数据库压力大。改为批量获取，每次获取一个segment（step决定大小）号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。
　　各个业务不同的发号需求用biztag字段来区分，每个biztag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biztag分库分表就行。
　　数据库表设计如下：
　　重要字段说明：biztag用来区分业务，maxid表示该biztag目前所被分配的ID号段的最大值，step表示每次分配的号段长度。原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1step。
　　例如现在有3台机器，每台机器各取1000个，很明显在第一台Leaf机器上是11000的号段，当这个号段用完时，会去加载另一个长度为step1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是30014000。同时数据库对应的biztag这条数据的maxid会从3000被更新成4000，更新号段的SQL语句如下：
　　Begin
　　UPDATEtableSETmaxidmaxidstepWHEREbiztagxxx
　　SELECTtag，maxid，stepFROMtableWHEREbiztagxxx
　　Commit
　　这种模式有以下优缺点：
　　优点：
　　Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
　　ID号码是趋势递增的8byte的64位数字，满足上述数据库存储的主键要求。
　　容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
　　可以自定义maxid的大小，非常方便业务从原有的ID方式上迁移过来。
　　缺点：
　　ID号码不够随机，能够泄露发号数量的信息，不太安全。
　　TP999数据波动大，当号段使用完之后还是会在获取新号段时在更新数据库的IO依然会存在着等待，tg999数据会出现偶尔的尖刺。
　　DB宕机会造成整个系统不可用。
　　对于第二个缺点，Leafsegment做了一些优化，简单的说就是：
　　Leaf取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB的网络和DB的性能稳定，这种情况对系统的影响是不大的，但是假如取DB的时候网络发生抖动，或者DB发生慢查询就会导致整个系统的响应时间变慢。
　　为此，希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999指标。
　　采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。
　　通常推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号1020分钟不受影响。
　　每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。
　　2。5。2Leafsnowflake方案
　　Leafsegment方案可以生成趋势递增的ID，同时ID号是可计算的，不适用于订单ID生成场景，比如竞对在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，美团提供了Leafsnowflake方案。
　　Leafsnowflake方案完全沿用snowflake方案的bit位设计，即是1411012的方式组装ID号。对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf服务规模较大，动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leafsnowflake是按照下面几个步骤启动的：
　　启动Leafsnowflake服务，连接Zookeeper，在leafforever父节点下检查自己是否已经注册过（是否有该顺序子节点）。
　　如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务。
　　如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。
　　除了每次会去ZK拿数据以外，也会在本机文件系统上缓存一个workerID文件。当ZooKeeper出现问题，恰好机器出现问题需要重启时，能保证服务能够正常启动。这样做到了对三方组件的弱依赖。
　　2。5。3美团Leaf现状
　　Leaf在美团点评公司内部服务包含金融、支付交易、餐饮、外卖、酒店旅游、猫眼电影等众多业务线。目前Leaf的性能在4C8G的机器上QPS能压测到近5万s，TP9991ms，已经能够满足大部分的业务的需求。每天提供亿数量级的调用量。
　　3分布式ID实战
　　从上面的分析可以看到，生成全局唯一ID的系统对于我们的项目来说是必须的，从诸多因素考虑，我们选用了美团的Leaf并根据项目的实际情况做了裁剪和改造。
　　首先，在我们的整个的商品系统中并没有安装Zookeeper而且也不考虑竞对，所以在ymbmallunqid中完全去除了有关Leafsnowflake的部分，从美团Leaf和我们的代码比较即可看出：
　　其次，在美团Leaf的实现中，可以看到对外提供ID的方法
　　很明显，一次只能提供一个ID，但是仔细考察商城系统的业务需求，比如订单，我们知道一个订单往往分为两个部分，订单的基本信息和订单详情，订单详情往往包含该订单的产品列表，在保存时我们往往也会用两张表来保存，一是订单表，二是订单详情表。订单表的ID很好说，每次从唯一ID服务取一个ID即可，但是订单详情表呢？我们会一次性插入一条订单记录和多条订单详情记录，如果对于订单详情记录的ID每次都从唯一ID服务取，这个无疑会对性能有影响，解决办法有两个：
　　1、订单详情记录的ID不保证全局唯一，依然使用数据库的自增主键；
　　2、订单详情记录的ID需要全局唯一，但并不每次从唯一ID服务，而是在生成订单时，一次性从唯一ID服务获得。
　　在我们的商城系统中，我们选择了第二种方式，很自然就需要对原来的美团Leaf进行改造：
　　可以看到，我们新增了一个批量获得唯一ID的方法，并限定每次可以获得ID的最大数量为5000个。
　　我们的ymbmallunqid本身是个无状态的服务，可以很方便的进行服务集群，以高伸缩性来应对服务的高可用、性能上的需求。