小米陈臻谈互联网分布式系统架构

个人简介 54chen（陈臻），分步式架构挑战者，参与设计开发了人人网海量存储系统。技术组织哥学社创始人，PHPChina内核版主，曾客串过清华万博智博中心特邀讲师。从事于互联网架构开发多年，曾就职于金山、雅虎、淘宝、人人网，现存小米科技负责米聊服务端开发工作。

QCon全球企业开发大会（QCon Enterprise Software Development Conference）是由C4Media媒体集团InfoQ网站主办的全球顶级技术盛会，每年在伦敦、旧金山、东京、北京召开。自2007年3月份在伦敦召开首次举办以来，已经有包括金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 各位朋友，大家好！现在我们是在InfoQ的Qcon大会现场，我们有幸邀请到了陈臻为大家进行一个关于分布式架构的探讨。你好陈臻。请先和大家做一个简短的自我介绍。

大家好，我是来自小米科技米聊团队的服务端成员陈臻。之前有大概两年多的时间一直在人人网研究Dynamo相关的一些系统。我们自己的Nuclear系统也是在这段时间产生的。因为个人的发展原因，在去年的11月份加入了现在的小米科技，也就是现在市面上经常出现的米聊的那个公司。

   

2. 现在很多人都愿意玩儿米聊。

对，有幸来参加这个Qcon大会分享一下过去两年的一些工作经验。

   

3. 那基于您下午要介绍的这些演讲内容，我提出来以下几个问题跟您一起交流或者探讨。第一个是对于MySQL加上MemCache这种类型的系统构架，在读写的实现方式上它是如何处理的。另外呢，节点之间的这种关系如何处理，在处理这些关系的时候我们有什么需要注意的地方？

这个是互联网企业里面比较常用的一种方式，就是MySQL在后面，然后中间业务层会在读写数据的时候，依赖这个Memcached。在业务量比较大的时候，可能会集中去管理一些Memcached的节点。然后在读的时候，一般情况会先看Memcached里面是不是有，如果Memcached有数据的话，这次读取就不会从MySQL那边读，而Memcached中没有的时候，就会从MySQL里面读出来，而且在访问数据的同时，可能也会写入这个Memcached。当然了，这是比较常见的一种处理方式，一般情况都是这样做的。而在写的时候，就会把缓存删掉，然后从MySQL里面把它去写一遍，而在Memcached相互的节点之间，最常见的就是一个一致性哈希的节点分布。现在比较好的集中式处理这种Memcached的一种机群，会按照业务的不同，会有一个不同的分区，这也是遇到比较大型的一种Memcached集中式管理时，比较常见的一种方案吧。

   

4. 下一个问题，对于这种Dynamo，如何保证它在节点变动的时候，将它的影响控制在最小的这种范围内，使影响不会无限的蔓延到其他地方，这个是如何做到的？

Dynamo系统里边有这样的一个理论，就是它把数据节点存放在一个虚拟分区里面。这个虚拟分区怎么说呢？当数据打到机器上的时候，它首先是先计算到某一个分区，而这个分区可能在多个机器上会存在，这里可能需要一个图会比较方便一点。在这个分区里边，如果说某一台机器宕掉了，那它影响到的也就是，这个机器所负责的这几个分区，而这些分区绝对不会是连续的，一般情况不会是连续的。它会是一个环上的无限多个相隔一定距离的一些分区上的数据，而在单位系统里边，它一般会有一个复制，它是相邻分区，而不是相邻节点的复制，而这个相邻分区，并不是在相邻节点上，所以当一个节点挂掉的时候，它并不会影响一片的数据，而是很零散的一条分散的数据，而这时候每一个分散的数据，都是在相邻的这个分区，就是在其他节点是有这个对应的数据备份的，而这样的影响就会是非常的小。

   

5. 那对于Dynamo当中有一个概念叫做NRW。那么NRW对于分布式架构中的这个很重要的概念就是CAP当中的C（Consistency）一致性，还有这个A（Availability）可用性，那么NRW它们这个取值对于一致性和可用性到底会造成什么样的一种影响？

CAP对这个Dynamo系统里面设置，严格的说，Dynamo系统是一个固定可扩展、可调整C和A的一个分布式系统。它的分区在于设计的开始，就是一个固定值，实际上我们的节点数量绝对不可能超过它的分区数量，从理论上来讲，Dynamo上面它不会，它一定会保证这个分区和节点数绝对是有关系的，也就是说我们的可扩展性其实在开始设计的时候已经是固定了的，而在NRW它这个里面，NRW来控制复制的份数，写入的次数，还有读出来的最大次数，因为这三个值完整的去控制这个C和A，就是数据的一致性，可以举一个简单的例子，下午会讲到更细节的。举个简单的例子，就说我们如果说N是一个复制，复制我们先不管它，假如说我们是R和W，如果R等于1的话，就代表读到一份便立刻返回。那也就是说不管这个数据是不是对的，我们读到就返回，那它的可用性是很高的，因为它读到就返回。但是它一致性是很低的，因为我们往往会复制很多份，这只是一个简单的例子，它可能取到的不一定是正确的数据，所以它的一致性就降低了。通过这个NRW来调节整个Dynamo系统的一个C和A的方法，这是Dynamo里面最核心的一个原则了。

   

6. 对于NRW它的取值是否应该有一些经验值？

经验值这个问题，在我们的实际业务中，为了达到一些性能特别特别高的目的时候，我们可能会用一个N复制两份，然后读一份写一份，也称为211。而在亚马逊的3里面，他们有一个Paper放出来，推荐的值是322，这个是一个他们那边业务的一个需求，他们要求一个99%的数据，99.9%的数据在三百毫秒以内返回，而我们在自己业务以前用的时候，都是可能会要求比它还高，可以牺牲一致性，但是我们可用性一定还要高。

   

7. 总之就是在CAP当中，你不可能说全都保证，如果要保证两个，可能要适当的牺牲到第三个？那么请您简单介绍一下Cassandra它的一个实现特点。

Cassandra它实际上，是Dynamo系统里面这个在亚马逊的这个核心开发人员出来加入了Face book，然后在Facebook做了这个Cassandra。一开始我们在08、09年关注Cassandra这个项目的时候，他们的Project主页上还提到了作者是来自亚马逊Dynamo系统的设计人员之一，然后慢慢，现在就看不到这一条消息了。

   

8. 现在它已经成为Apache的一个顶级项目了。

对，这个东西它怎么说呢？Cassandra实现的时候有一些偷懒的地方，也有一些做得比较不错的地方。他里面的比如说时钟向量8：38这一块，采取了一个很简单的办法。就是从各个节点取数据上来，需要对比数据是不是以各自不一样，或者说有冲突怎么办，他们用了一个最简单的办法就是，取最后写进去的时间，也就是说新鲜值越大的，这个数据我们直接就要，否则就不要写他的数据，这个就是他偷懒的一些地方。然后他做得比较好的，他的以前的存储引擎，把Bigtable实现了一遍，是一个基于列族的一个存储，而Dynamo的Paper本身并没有提到这个存储引擎的设计。他只是分布式架构的一个架构层面的设计。

   

9. 非常感谢陈臻先生能接受我们的采访。谢谢您。

谢谢。