世间万物,都有自己唯一的标识,比如人,每个人都有自己的指纹(白夜追凶给我科普的,同卵双胞胎DNA一样,但指纹不一样)。又如中国人,每个中国人有自己的身份证。对于计算机,很多时候,也需要为每一份数据生成唯一的标识。在这里,数据的概念是非常宽泛的,比如数据量记录、文件、消息,而唯一的标识我们称之为id。

  本文地址:http://www.cnblogs.com/xybaby/p/7616272.html

自增ID

  使用过mysql的同学应该都知道,经常用自增id(auto increment)作为主键,这是一个为long的整数类型,每插入一条记录,该值就会增加1,这样每条记录都有了唯一的id。自增id应该是使用最广泛的id生成方式,其优点在于非常简单、对数据库索引友好、而且也能透露出一些信息,比如当前有多少条记录(当然,用户也可能通过id猜出总共有多少用户,这就不太好)。但自增ID也有一些缺点:第一,id携带的信息太少,只能起到一个标识作用;第二,现在啥都是分布式的,如果多个mysql组成一个逻辑上的‘mysql’(比如水平分库这种情况),每个物理mysql都使用自增id,局部来说是唯一的,但总体来说就不唯一了。

  于是乎,我们需要为分布式系统生成全局唯一的id。最简单的办法,部署一个单点,比如单独的服务(mysql)专门负责生成id,所有需要id的应用都通过这个单点获取一个唯一的id,这样就能保证系统中id的全局唯一性。但是分布式系统中最怕的就是单点故障(single point of failure),单点故障是可靠性、可用性的头号天敌,因此即使是中心化服务(centralized service)也会搞成一个集群,比如zookeeper。按照这个思路,就有了Flicker的解决方案。

  Flicker的解决办法叫《Ticket Servers: Distributed Unique Primary Keys on the Cheap》,文章篇幅不长,而且通俗易懂,这里也有中文翻译。简单来说,Flicker是用两组(多组)mysql来提供全局id的生成,多组mysql避免了单点,那么怎么保证多组mysql生成的id全局唯一呢,这就利用了mysql的自增id以及replace into语法。

  大家都知道mysql的自增id,但是不一定知道其实可以设置自增id的初始值以及自增步长, Flicker中的示例中,两个mysql(ticketserver)初始值分别是1和2,自增步长都是2(而不是默认值1),这样,ticketserver1永远生成奇数的id,而ticketserver2永远生成偶数的id。

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

  那么怎么获取这个id呢,不可能每需要一个id的时候都插入一条记录,这个时候就用到了replace into语法。 replace是insert、update的结合体,对于一条待插入的记录,如果其主键或者唯一索引的值已经存在表中的话,那么会删除旧的那条记录,然后插入新的记录;如果不存在,那么直接插入记录。这个非常类似mongodb中的findandmodify语法。在Flicker中,是这么使用的,首先schema如下:

CREATE TABLE `Tickets64` (
`id` bigint(20) unsigned NOT NULL auto_increment,
`stub` char(1) NOT NULL default '',
PRIMARY KEY (`id`),
UNIQUE KEY `stub` (`stub`)
) ENGINE=MyISAM

  注意,id是主键,而stub是唯一索引,当需要产生一个id的时候,使用以下sql语句;

REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();

  由于stub是唯一索引,当每次都插入‘a'的时候,会产生新的记录,而新记录的id是自增的(则增步长为2)

  Flicker的解决办法通俗易懂,但还是没有解决id信息过少的问题,而且还是依赖单独的一组服务(mysql)来生成全局id。如果全局id的生成不依赖额外的服务,而且包含丰富的信息那就最好了。

携带时间与空间信息的ID

UUID  

  提到全局id,首先想到的肯定是UUID(Universally unique identifier),从名字就能看出,这个是专门用来生成全局id的。而UUID又分为多个版本,不同的语言,厂家都有自己的实现。本文对uuid的介绍主要参考rfc4122,如下图所示,一个uuid由一下部分组成:

    

  可以看到,uuid包含128个bit、即16个字节,其中包含了时间信息、版本号信息、机器信息。uuid也不是说一定能保证不冲突,但其冲突的概率小到可以忽略不计。使用uuid就不用再使用额外的id生成服务了。但缺点也有明显:太长,16个字节!太长有什么问题呢,占用空间?问题不大。主要的问题,是太长且随机的id对索引的不友好。在《Are you designing Primary Keys and ID’s???Well think twice..》一文中,作者也许需要用uuid来代替自增id,作者指出:
  So what do we do change ID’s to UUID as well. Well no, that’s not a good idea because we will simply increase work for our database server. It will now have to index a random string of 128 bit. The data will be more fragmented and bigger to fit in memory. This will definitely bring down the performance of our system.
  测试结果如下:

         

  第一例是当前db中有多少条记录,第二列是使用uuid作为key时插入1 million条记录耗费的时间,第三列是使用64位的整形作为key时插入1 million条记录耗费的时间。从结果可以看出,随着数据规模增大,使用uuid时的插入速度远小于使用整形的情况。

  既然uuid太长了,那后来者都是在uuid的基础上尽量缩短id的长度,使之更加实用。我认为,如果使用时间信息、机器信息来生成id的话,那么应该就是借鉴了uuid的做法,包含但不限于:twitter的snowflake,mongodb的ObjectId

MongoDB ObjectId

ObjectId is a 12-byte BSON type, constructed using:
  • a 4-byte value representing the seconds since the Unix epoch,
  • a 3-byte machine identifier,
  • a 2-byte process id, and
  • a 3-byte counter, starting with a random value.
  objectid有12个字节,包含时间信息、机器表示、进程id、计数器。在mongo.exe中,通过ObjectId.getTimestamp可以获取时间信息
mongos> x = ObjectId()
ObjectId("59cf6033858d9d5a85caac02")
mongos> x.getTimestamp()
ISODate("2017-09-30T09:13:23Z")
  MongoDb的各语言驱动都实现了ObjectId的生成算法,比如PyMongo,在bson.objectid.py里面。通过ObjectId的生成算法以及mongo shell、pymongo的例子,我们可以看到,objectid的生成是由驱动负责的,而不是MongoDB负责,这样减轻了MongoDB负担,也达到了去中心化服务的目的。

结构化ID思考

  这里的结构化ID,就是指按一定规则,用时间、空间(机器)信息生成的ID,上面介绍的UUID以及各种变种都属于结构化id。

  结构化ID的优点在于充足的信息,最有用的肯定是时间信息,通过ID就能直接拿到数据的创建时间了;另外,天然起到了冷热数据的分离。当然,有利必有弊,比如在ID作为分片键的分片环境中,如果ID包含时间信息,那么很可能在短时间内生成的数据会落在同一个分片。在《带着问题学习分布式系统之数据分片》一文中,介绍了MongoDB分片的两种方式:“hash partition”与“range partition“,如果使用ObjectId作为sharding key,且sharding方式为range partition,那么批量导入数据的时候就会导致数据落在同一个shard,结果就是大量chunk的split和migration,这是不太好的。

TFS文件名

  如果结构化ID中包含分片信息,那就更好了,这样就不会再维护数据与分片的信息,而是直接通过id找出对应的分片。我们来看看TFS的例子

  TFS是淘宝研发的分布式文件存储系,其的结构一定程度上参考了GFS(HDFS),元数据服务器称之为Nameserver,实际的数据存储服务器称之为Dataserver。TFS将多个小文件合并成一个大文件,称之为block,block是真实的物理存储单元。因此,DataServer负责存储Block,而NameServer维护block与DataServer的映射。那么小文件与block的映射关系在哪里维护呢?要知道小文件的量是很大的

  TFS的文件名由块号和文件号通过某种对应关系组成,最大长度为18字节。文件名固定以T开始,第二字节为该集群的编号(可以在配置项中指定,取值范围 1~9)。余下的字节由Block ID和File ID通过一定的编码方式得到。文件名由客户端程序进行编码和解码

  如图所示:

       

  从上图可以看到,最终的文件名是包含了block id信息的的,那么如何利用这个blockid信息呢,如下图所示:

    

  当需要根据文件名获取文件内容的时候,TFS的客户端,首先通过文件名解析出Block id与File id,然后从NameServer上根据Block id查询block所在的DataServer。然后从DataServer上根据Block id拿到对应的block,在根据file id从block中找到对应的文件。

  

  TFS用于存储淘宝大量的小文件,比如商品的各种尺寸的小图片,这个数量是非常大的,如果用单独的元数据服务器维护文件名与文件信息的映射,这个量是非常大的。而使用携带block id信息的文件名,很好规避了这个问题。但使用这种携带分区信息的ID时,需要考虑数据在分区之间的迁移情况,ID一般来说使不能变的,因此ID映射的应该是一个逻辑分区,而不是真正的物理分区。

 

总结

   本文介绍了分布式系统中,全局唯一ID的生成方法。ID主要有两种类型,一种是数字自增ID,如flicker的解决方案;另一种是携带时间、机器信息的组合ID,如uuid。分布式系统中,好的全局ID生成算法首先是需要避免单点,如果不需要中心化服务的话更好;另外,携带时间信息、分片信息的ID更加实用。

references

Ticket Servers: Distributed Unique Primary Keys on the Cheap

UUID(Universally unique identifier)

rfc4122

Are you designing Primary Keys and ID’s???Well think twice..

TFS

 
 

分布式系统中生成全局ID的总结与思考的更多相关文章

  1. 如何在高并发分布式系统中生成全局唯一Id

    月整理出来,有兴趣的园友可以关注下我的博客. 分享原由,最近公司用到,并且在找最合适的方案,希望大家多参与讨论和提出新方案.我和我的小伙伴们也讨论了这个主题,我受益匪浅啊…… 博文示例: 1.     ...

  2. 如何在高并发分布式系统中生成全局唯一Id(转)

    http://www.cnblogs.com/heyuquan/p/global-guid-identity-maxId.html 又一个多月没冒泡了,其实最近学了些东西,但是没有安排时间整理成博文, ...

  3. (转)如何在高并发分布式系统中生成全局唯一Id

    又一个多月没冒泡了,其实最近学了些东西,但是没有安排时间整理成博文,后续再奉上.最近还写了一个发邮件的组件以及性能测试请看 <NET开发邮件发送功能的全面教程(含邮件组件源码)> ,还弄了 ...

  4. 高并发分布式系统中生成全局唯一(订单号)Id js返回上一页并刷新、返回上一页、自动刷新页面 父页面操作嵌套iframe子页面的HTML标签元素 .net判断System.Data.DataRow中是否包含某列 .Net使用system.Security.Cryptography.RNGCryptoServiceProvider类与System.Random类生成随机数

    高并发分布式系统中生成全局唯一(订单号)Id   1.GUID数据因毫无规律可言造成索引效率低下,影响了系统的性能,那么通过组合的方式,保留GUID的10个字节,用另6个字节表示GUID生成的时间(D ...

  5. 高并发分布式系统中生成全局唯一Id汇总

    数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求:   1 不能有单点故障.   2 以时间为序,或者ID里包含时间 ...

  6. 高并发分布式系统中生成全局唯一(订单号)Id

    1.GUID数据因毫无规律可言造成索引效率低下,影响了系统的性能,那么通过组合的方式,保留GUID的10个字节,用另6个字节表示GUID生成的时间(DateTime),这样我们将时间信息与GUID组合 ...

  7. insert 一条数据 然后拿出这条数据在数据库中生成的ID

    [insert 一条数据 然后拿出这条数据在数据库中生成的ID] <insert id="insert" parameterType="management&quo ...

  8. 分布式系统下的全局id生成策略分析

    对于分布式系统而言,意味着会有很多个instance会并发的生成很多业务数据,比如订单.不同的机房.不同的机器.不同的应用实例会同时生成.所以,如何生成一个好用的全局id并不是一个简单的uuid就能够 ...

  9. 架构设计 | 分布式业务系统中,全局ID生成策略

    本文源码:GitHub·点这里 || GitEE·点这里 一.全局ID简介 在实际的开发中,几乎所有的业务场景产生的数据,都需要一个唯一ID作为核心标识,用来流程化管理.比如常见的: 订单:order ...

随机推荐

  1. php工具方法

    备忘常用方法 1.寻找子栏目(权限\菜单列表...) function getSon($list,$pid){ $arr=''; foreach ($list as $k=>$v){ if($v ...

  2. 处理 Vue 单页面应用 SEO 的另一种思路

    vue-meta-info 官方地址: monkeyWangs/vue-meta-info (设置vue 单页面meta info信息,如果需要单页面SEO,可以和 prerender-spa-plu ...

  3. C++中关于重载默认构造函数与默认全部参数的构造函数的使用注意

    # include<iostream>using namespace std;class Time{public:                            //公用成员函数  ...

  4. poj 3592 缩点+SPFA

    题意:给出一个矩阵,其中#代表墙,不可走,0-9代表权值,*代表可以选择传送.求从0,0点开始出发能获得最大权值. 思路:因为*的出现会有环的情况,先建图连边,将环进行Tarjan缩点,之后再从0,0 ...

  5. base(function strchr)

    函数原型:extern char *strchr(char *str,char character) 参数说明:str为一个字符串的指针,character为一个待查找字符.        所在库名: ...

  6. CentOS6.5下LNMP环境的搭建

    #写的不好,大牛勿喷 #其实我很努力 OS:CentOS6.5 1.关闭SELinux,关闭防火墙 原因:1.SELinux确实可以提高服务器的安全性,但是对于服务器的性能存在一定的影响,同时它的复杂 ...

  7. 事后诸葛亮分析(Beta阶段)

    设想和目标 1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 解决用户想要随时锻炼四则运算能力的问题:定义的很清楚:有清晰描述. 2.是否有充足的时间来做计划? ...

  8. 【Beta】 第七次Daily Scrum Meeting

    第七次meeting会议 [Beta] 第七次Daily Scrum Meeting 一.本次会议为第七次meeting会议 二.时间:10:00AM-10:20AM 地点:禹州楼 三.会议站立式照片 ...

  9. 201521123071 《JAVA程序设计》第二周学习总结

    1. 本周学习总结 在本周的学习中,主要学习了书上的String类以及Math类等知识,但是书上学到的东西只是理论,实际打起代码来的时候会学习到更多,比如在PTA上就有学习到StringBuilder ...

  10. 201521123035《Java程序设计》第十周实验总结

    1. 本周学习总结 1.1 以你喜欢的方式(思维导图或其他)归纳总结异常与多线程相关内容. 2. 书面作业 本次PTA作业题集异常.多线程 1.finally 题目4-2 1.1 截图你的提交结果(出 ...