分布式ID

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 需求缘起   几乎所有的业务系统，都有生成一个记录标识的需求，例如： 1. 消息标识：message-id 2. 订单标识：order-id 3. 帖子标识：tiezi-id   这个记录标识往往就是数据库中的唯一主键，数据库上会建立聚集索引（cluster index），即在物理存储上以这个字段排序。这个记录标识上的查询，往往又有分页或者排序的业务需求，例如： 1. 拉取最新的一页消息： SELECT message-id ORDER BY time LIMIT 100 2. 拉取最新的一页订单： SELECT order-id ORDER BY time LIMIT 100 3. 拉取最新的一页帖子： SELECT tiezi-id ORDER BY time LIMIT 100   所以往往要有一个time字段，并且在time字段上建立普通索引（non-cluster index）.我们都知道普通索引存储的是实际记录的指针，其访问效率会比聚集索引慢，如果记录标识在生成时能够基本按照时间有序，则可以省去这个time字段的索引查询： SELECT message-id ORDER BY message-id LIMIT 100   再次强调，能这么做的前提是message-id的生成基本是趋势时间递增的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 目标： （ 1 ）全局唯一 （ 2 ）趋势有序 如何高效生成趋势有序的全局唯一 ID呢？ 一、需求缘起 几乎所有的业务系统，都有 生成一个记录标识的需求 ，例如： （ 1 ）消息标识： message-id （ 2 ）订单标识： order-id （ 3 ）帖子标识： tiezi-id 这个记录标识往往就是数据库中的 唯一主键 ，数据库上会建立聚集索引（ cluster index ），即在物理存储上以这个字段排序。 这个记录标识上的查询，往往又有 分页或者排序的业务需求 ，例如： （ 1 ）拉取最新的一页消息： select message-id order by time limit 100 （ 2 ）拉取最新的一页订单： select order-id order by time limit 100 （ 3 ）拉取最新的一页帖子： select tiezi-id order by time limit 100 所以往往要有一个 time 字段，并且在 time 字段上建立普通索引（ non-cluster index ）。 我们都知道普通索引存储的是实际记录的指针，其访问效率会比聚集索引慢，如果记录标识在生成时能够基本按照时间有序，则可以省去这个 time 字段的索引查询： select message