零零碎碎小知识

以下知识均是理论，如果您有好的解决方案可以留言交流

1分布式ID生成策略

zk 性能瓶颈，尤其是集群，集群越大，性能瓶颈越明显
redis，如果成功了可以，不成功就要不断尝试，造成延时，15-20毫秒不能响应，影响后续操作，影响用户下单。

业界主流分布式ID生成策略，提前加载，预加载机制，提前生成一批ID，放到内存中，不是redis的缓存中，有一块内存guava缓存，持久化到mongDB或者其他内存数据库，专门存放ID，用完了删掉就可以了。

使用分布式框架disruptor框架，直接调用我内存中的ID，并对数量进行监控，当数量少于40%的时候，可以用定时任务再去生成一批ID，用其他的服务，生成再存进来。
如果ID需要加上业务规则，比如分类，地区，行业，不同的业务线，此时可以配置不同的规则，用zookeeper，根据不同的规则生成不同的业务线的ID。

第二种，使用单点的方式生成，根据唯一的标识，机器码之类的。
好处，全局唯一，如果也涉及业务，那么机器码+时间戳+自增序列
注意NTP问题，服务器时间同步。超大高并发场景。
1：机器码+时间戳
2：服务器发生时间校准，在标杆时间之前，于是服务器回到订单之前的时间，产生回调如果再次下单。
3：机器码+时间戳 重复了！
所以+自增序列，自增序列永远在单点下保证自增，比如atomiclong，原子类。原子序列计数器。