分布式id主要用到哪些地方
在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。
分布式id创建的业务需求
要求如下所示
1.全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
2.趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
3.单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
4.信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。
5.分布式id里面最好包含时间戳，这样就能够在开发中快速了解这个分布式id的生成时间
上述123对应三类不同的场景，3和4需求还是互斥的，所以无法使用同一个方案满足。
同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高，想象一下，如果ID生成系统瘫痪，整个美团点评支付、优惠券发券、骑手派单等关键动作都无法执行，这就会带来一场灾难。由此我总结下一个ID生成系统应该做到如下几点：
可用性高：就是我用户发了一个获取分布式id的请求，那么你服务器就要保证99.999%的情况下给我创建一个分布式id
延迟低：就是我用户给你一个获取分布式id的请求，那么你服务器给我创建一个分布式id的速度就要快
高QPS：这个就是用户一下子有10万个创建分布式id请求同时过去了，那么你服务器要顶的住，你要一下子给我成功创建10万个分布式id
