请选择 进入手机版 | 继续访问电脑版
设为首页 收藏本站
开启辅助访问

新浪微博登陆

只需一步, 快速开始

QQ登录

只需一步,快速开始

切换风格 立即注册 找回密码

Java教程网

Java教程网 门户 项目架构 查看内容

分布式ID生成器

2018-1-12 21:31| 发布者: wenzhilanyu| 查看: 256| 评论: 0|来自: 架构师之路

摘要: 一、需求缘起几乎所有的业务系统,都有生成一个唯一记录标识的需求,例如:消息标识:message-id订单标识:order-id帖子标识:tiezi-id这个记录标识往往就是数据库中的主键,数据库上会建立聚集索引(cluster index ...

一、需求缘起

几乎所有的业务系统,都有生成一个唯一记录标识的需求,例如:

  • 消息标识:message-id

  • 订单标识:order-id

  • 帖子标识:tiezi-id


这个记录标识往往就是数据库中的主键,数据库上会建立聚集索引cluster index),即在物理存储上以这个字段排序。

 

这个记录标识上的查询,往往又有分页或者排序的业务需求,例如:

  • 拉取最新的一页消息

    select message-id/ order by time/ limit 100

  • 拉取最新的一页订单

    select order-id/ order by time/ limit 100

  • 拉取最新的一页帖子

    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的生成基本是趋势时间递增的

 

这就引出了记录标识生成(也就是上文提到的三个XXX-id)的两大核心需求:

  • 全局唯一

  • 趋势有序

这也是本文要讨论的核心问题:如何高效生成趋势有序的全局唯一ID

 

二、常见方法、不足与优化

方法一:使用数据库的 auto_increment 来生成全局唯一递增ID


优点:

  • 简单,使用数据库已有的功能

  • 能够保证唯一性

  • 能够保证递增性

  • 步长固定


缺点:

  • 可用性难以保证:数据库常见架构是一主多从+读写分离,生成自增ID是写请求,主库挂了就玩不转了

  • 扩展性差,性能有上限:因为写入是单点,数据库主库的写性能决定ID的生成性能上限,并且难以扩展


改进方法:

  • 冗余主库,避免写入单点

  • 数据水平切分,保证各主库生成的ID不重复


如上图所述,由1个写库变成3个写库,每个写库设置不同的auto_increment初始值,以及相同的增长步长,以保证每个数据库生成的ID是不同的(上图中库0生成0,3,6,9…,库1生成1,4,7,10,库2生成2,5,8,11…

改进后的架构保证了可用性,但缺点是:

  • 丧失了ID生成的“绝对递增性”:先访问库0生成0,3,再访问库1生成1,可能导致在非常短的时间内,ID生成不是绝对递增的(这个问题不大,目标是趋势递增,不是绝对递增)

  • 数据库的写压力依然很大,每次生成ID都要访问数据库


为了解决上述两个问题,引出了第二个常见的方案。

 


12下一页

鲜花

握手

雷人

路过

鸡蛋

最新评论

关闭

站长推荐 上一条 /1 下一条

小黑屋|手机版|Archiver|Java教程网    

GMT+8, 2018-10-24 10:43 , Processed in 0.250000 second(s), 23 queries .

Powered by Discuz X3.2

© 2001-2013 JAVA教程网

返回顶部