高并发下分布式ID生成方案

方案1：UUID机制

  算法的核心思想是结合机器的网卡、当地时间、一个随机数来生成UUID

• 优点： 本地生成，生成简单，性能好，没有高可用风险。
• 缺点： 长度过长，无序不可读，对于MySQL的查询不方便(因为UUID是字符串，比对是否相等时需要将字符串解析成一个个字符，再转成ASCII码进行比对)，且容易造成叶子节点裂变（导致大量数据的拷贝，对性能有影响）。
• 适用场景： 业务场景简单，没有高并发量，只是简单的分散存储，而且不考虑后期可维护性的场景。

---

方案2：Redis自增ID

  Redis的所有命令操作都是单线程的，本身提供像incr和increby这样的自增原子命令，所以能保证生成的ID肯定是唯一有序的。

• 优点： 不依赖于数据库，灵活方便，且性能优于数据库，数字ID天然排序，对分页或者需要排序的结果时很有帮助。
• 缺点： 存放在Redis当中，如果内存淘汰策略选择不当，会导致丢失，不支持非连续性ID生成。

---

方案3：数据库自增ID

  使用数据库的ID自增策略，如MySQL的auto_increment。并且可以使用两台数据库分别设置不同步长，生成不重复id的策略来实现高可用。

• 优点： 数据库生成的ID绝对有序，高可用且实现方式简单。
• 缺点： 需要独立部署数据库实例，成本高，有性能瓶颈。

---

方案4：Twitter的雪花算法

  Twitter利用ZooKeeper实现了一个全局ID生成的服务Snowflake,不同的位代表了不同的含义。

优点： 高性能，低延迟，按时间有序，一般不会造成ID碰撞。
缺点： 需要独立的开发和部署，依赖于机器的时钟。

---

方案5：百度的UidGenerator

  底层是基于雪花算法去实现的，但是目前该项目的社群活跃度不高

---

方案6：美团的Leaf

  Leaf是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、ZooKeeper等中间件。