常见分布式ID解决方案的优缺点
分布式系统之所以难，很重要的原因之一是“没有一个全局时钟，难以保证绝对的时序”。
一、分布式ID的特性或要求：
- 唯一性：确保生成的ID是应用系统内唯一。
- 高可用性：确保任何时候都能正确的生成ID。
- 有意义：或者说包含更多信息，例如时间、业务等信息。如：有序性，通常都需要保证生成的 ID 是有序递增的。例如，在数据库存储等场景中，有序 ID便于确定数据位置，往往更加高效
- 紧凑性：ID 的大小可能受到实际应用的制约，例如数据库存储往往对长 ID不友好，太长的ID 会降低 MySQL 等数据库索引的性能；
二、分布式ID的生成方案
1. UUID
算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。
优点：本地生成，生成简单，性能好，没有高可用风险
缺点：长度过长，存储冗余，且无序不可读，查询效率低
2. 数据库自增ID
使用数据库的id自增策略，如 MySQL 的 auto_increment。并且可以使用两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。
优点：数据库生成的ID绝对有序，高可用实现方式简单
缺点：
- 需要独立部署数据库实例，成本高，有性能瓶颈
- 可用性难以保证：数据库常见架构是一主多从+读写分离，生成自增ID是写请求，主库挂了就玩不转了
- 扩展性差，性能有上限：因为写入是单点，数据库主库的写性能决定ID的生成性能上限，并且难以扩展
优点：避免了每次生成ID都要访问数据库并带来压力，提高性能
缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续
自增ID选择bigint类型，bigint的范围是 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型数据（所有数字）。可以批量生成ID，一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值。
假设每天100万记录，你可以使用922,337,203,685天，也就是 2,562,047,788 年。
3. Redis生成ID（推荐）
Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。
优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度&#x