Instagram 的ID生成策略[翻译]

项目中遇到一个ID生成策略的需求:需要在系统中为每个用户分配一个ID用作以后的用户标示。这个需求应该是非常普遍的,对于使用人数较少的系统而言不会是一个问题,不过对于向用户众多的互联网系统来讲这不是一个简单的问题。下面是翻译的最近最火爆的Instagram应用开发者的一篇文章,看看他们一个十几个人的公司是怎么解决这个问题的:

以下为简单翻译(不清楚的地方请参照原文):

                                                     Instagram 的分片和IDs

       每秒接收25副图片、90次"like"分享,Instagram存储了大量的数据。为了确保所有重要的数据都存入到了内存并且尽快地对于用户可用,我们将数据进行了分片---换句话说就是将数据存到很多小分片上,每个分片都持有数据的一部分。

       我们使用Django 和PostgreSQL 作为后台的数据库系统。在决定对数据进行分片后我们遇到的第一个问题就是是否仍旧将PostgreSQL作为我们主要的数据存储系统,还是换个其他的。我们评估了一些不同的NoSQL解决方案,但最终决定:最符合我们需求的是将数据分片到由多个PostgreSQL组成的服务器组上。

       在将数据写入到PostgreSQL服务器组之前,我们必须先解决如何为数据库中每一份数据指定相应的唯一标示(例如每一副发布在我们系统上的图片)。典型的解决方案在单个数据库中还行得通---直接使用数据库的自增来分配唯一标示;但要将数据同时插入到多个数据库时这种方案就不行了。这篇文章接下来的内容就指明了我们是如何对付这个问题的。

       在开始之前我们列出了几个系统中必须的几个功能:

       1.生成的ID必须可以按时间排序(这样一来,一组图片可以不用再查找其他相关信息就能排序)

       2.ID最好是64bit的(为了索引更小且方便存储在像Redis这样的系统中)

       3.新系统造成的不确定性(or改动)越小越好---我们之所以能用这么少的工程师搞定Instagram,很大的原因就在于选择简单、易懂、可靠的解决方案。

       现存的解决方案:

       对于ID生成问题现在已经有很多现存的方案,以下为几个我们可以考虑的:

       在web应用(web application)中生成ID

       这种方式将ID生成的问题全部交给你的应用程序,而不是数据库来解决。

       例如:MongoDB 的ObjectID 一共有12bytes长,并且将编码后的时间戳作为首要的组件。另一个常用的就是UUID。

       优点:

             1.每个应用程序线程都独立地生成ID,减少了故障和不一致。

             2.如果你使用时间戳作为ID的首要组件,ID就是可以按时间排序的。

       缺点:

             1.为了保证唯一性的可靠,一般需要更多的存储空间(96bit或更多)。

             2.有些UUID完全是随机的,不能自然排序。

      使用专门的服务生成ID

      例如:Twitter的 Snowflake---一个使用Apache ZooKeeper来整合所有节点然后生成64bit唯一ID的简洁的服务。

      优点:

            1.Snowflake生成的ID只有64位,只有UUID的一半大小。

            2.可以使用时间戳作为首要组件,可排序。

            3.分布式的系统,某个节点down掉也没事。

      缺点:

            1.会给整体架构引入额外的复杂性,和一些不确定内容(ZooKeeper, Snowflake servers)

      数据库"票务"服务器

      使用数据库的自增功能来保证唯一性。Flickr 使用了这种方法---但使用了两台数据库服务器(一台生成奇数,一台生成偶数)来防止单点当机。

      优点:

            1.数据库非常熟悉,有很多可预见的因素。

      缺点:

            1.会最终成为一个写瓶颈(根据Flickr的报告,即使在大规模并发的情况下这也不会成为一个问题)

            2.对于管理员而言额外多了一对机器。

            3.如果使用单个数据库则容易出现单点故障,使用多个则无法保证可以按时间排序。

      以上几种方法中Twitter的离我们想要的最为接近,但是运行一个专门的ID服务所造成的额外复杂性却是一个负面因素。

     替代地,我们选择了一个概念上与之相似的方法,并将它整合到了PostgreSQL中。

     我们的解决方案

     我们的分片系统由上千个逻辑分片组成,而这些逻辑分片在代码中与非常少的物理分片进行了映射。使用这种方法我们可以从很少的数据库服务器开始,最终转到更多的服务器:只需要将一些逻辑片从一台服务器移到另一台,中间不需要重新打包任何数据。为了易于编码和管理我们使用Postgres的schema功能来实现。

Schemas(不是SQL 中的表的schema) 是逻辑上的一组功能。每个Postgres 数据库可以拥有多个schema,每个schema中可以有一到多个表;表名在schema内是唯一的,在DB中可以不唯一;默认的,数据库将所有的信息都放在一个叫"public"的schema中。

     在我们的系统中每个逻辑分片都是一个schema,每个被分片的表都存在于每个schema中。我们使用PL/PGSQL(Postgres内置的编程语言)和Postgers自身的自增函数,为每个分片中的每张表都赋予了生成ID功能。

     每个ID由以下部分组成:

     1.41bits 存储毫秒格式的时间。

     2.13bits 表示逻辑分片ID。

     3.10bits 存储自增序列值对1024取模后的结果,这意味着每个分片每秒可以产生1024个ID。

     下面进行一个测试:假设现在是2011-09-09 下午05:00,我们的业务从2011-01-01开始运行。从开始到现在已经运行了1387263000毫秒,开始构造我们的ID,我们使用左移位的方式填充左面的41位:

      id = 1387263000 << (64-41)

     接着,我们获取即将插入的这份数据所在的分片ID,假设我们按用户ID来进行分片,系统中一共有2000个逻辑分片;如果我们的用户ID是31341,那么我们的分片ID就是31341 % 2000 -> 1341。我们使用这个值来填充接下来的13位:

    id |= 1341 << (64-41-13)

     最后我们使用任意生成的自增序列值(单个schema单张表内唯一)来填充其余的位数。假设我们要插入的那张表已经生成了5000个ID了,下一个值就是5001,我们对其使用1024取模(这样生成的数据就是10bits了),然后加上去:

     id |= (5001 % 1024)

    现在我们已经获取到了想要的ID,接下来可以使用return关键字作为insert过程的一部分返回给应用程序了。

    下面是以上整个过程的PL/PGSQL代码实现(例如:在schema实例5中):

CREATE OR REPLACE FUNCTION insta5.next_id(OUT result bigint) AS $$
DECLARE
    our_epoch bigint := 1314220021721;
    seq_id bigint;
    now_millis bigint;
    shard_id int := 5;
BEGIN
    SELECT nextval('insta5.table_id_seq') %% 1024 INTO seq_id;

    SELECT FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 1000) INTO now_millis;
    result := (now_millis - our_epoch) << 23;
    result := result | (shard_id << 10);
    result := result | (seq_id);
END;
$$ LANGUAGE PLPGSQL;

 下面是创建数据库表:

CREATE TABLE insta5.our_table (
    "id" bigint NOT NULL DEFAULT insta5.next_id(),
    ...rest of table schema...
)

就这样了!主键在我们的应用里面是唯一的(作为捎带的私货,为了易于映射含有分片ID)。我们已经将这个方法应用到了产品中,目前看来效果挺令人满意。有兴趣帮助我们解决这些问题?我们的联系方式      Mike Krieger, co-founder

相关推荐