第七章 分布式K—V系统概述.docxVIP

提及分布式key-value存储系统，Memcached, Voldemort, Cassandra,包括淘宝最近开源，我们一直在使用的Tair系统，相信大家都不会觉得陌生。本文会从Tair入手，介绍分析一下传统分布式键-值存储系统的原理，架构和使用技术。错误之处，还望大家指正。先看一下Tair的架构：???乍一看，会发现Tair的系统架构和TFS一样，都基于了Google的GFS设计，主要包括三部分：??其中ConfigServer主要负责管理维护DataServer以及和Client端的部分通信；DataServer则是存储对象的地方，数据的增/删/更新都在这里进行；Client端向服务器请求插入/删除/更新数据；看完上面的介绍，你可能会有以下几个疑问：1.configServer的真正工作是什么？2. DataServer如何存储数据？3. Client端只需要和dataServer通信吗?4. 如何实现分布式？关于上述第四点如何实现分布式键-值存储系统，我们又要从分布式系统CAP要求出发：数据一致性，系统可用性，系统分区宽容度（说白了就是如何解决分布式下Server端机器的增减和容错问题）。这几个问题才是分布式应用中最棘手最重要的问题。接下来，依据个人的理解，结合Tair相关知识，对上述问题做一下介绍。首先，tair中的configServer在物理上是以Master-Slaver形式部署，作用大家都很清楚，在Master不可用或者宕机的时候，slaver转为master对外提供服务。那么是不是configServer不能对外部提供就说明所有的客户端都不再可用？答案是否定的，因为configServer在tair中扮演的是一个非常轻量级的角色，如何理解？为解决这个问题，我们需要解决另外一个问题，如何保证来自客户端的数据在tair中均匀的分布，也就是如何对dataServer进行负载均衡，另外，如何保证dataServer的数据不会失效？一个简单的模型就是取模，通过对key的hash值对机器个数取模，将其存储到余数对应的机器上。比如有a,b,c,d四个数据，3台机器，hash取3模后a,c存储到机器1，b存储到机器2，d存储到机器3上。貌似我们已经解决了问题。经过hash和取模操作后，在大数据量情况下，最后数据在三台机器上的分布肯定是比较均匀的，达到负载均衡的目的了？但是，分布式环境下，当机器量比较多时总是不能避免新机器加入或者某台正在使用的机器不可用了，如果是某台机器不可用，那来自客户端对它的所有请求都会命中失效；这个时候唯一的办法就是将所有的数据重新hash分配，因为取模分母变化了（假设你这个时候对所有数据是有备份的），如果数据量非常大，此项工作也是极其浪费时间的，客户端不可服务时间加长；如果是因为数据量增大，需要新增机器到这个集群中，我们面临的问题一样头疼无助。问题在哪里？因为我们每次取模的单位是机器个数，而机器个数是在不停变化的。所以简单的解决方案就是不要以机器个数取模，取一个恒定不变的值，但是如何应对动态变化的数据？又如何将数据与机器对应起来呢？二次转换是不可避免的了，看来这个解决方案不太可行。到这里，可能你会问，memcached,cassandra是如何处理这种问题的呢？答案是Consistent Hashing：一致性hash简单的说就是把数据对象和服务器(ip or name)都映射到一个32位的数值空间，即0～232-1，然后将这个范围首尾相连，组成一个圆环。这样，无论是数据还是机器都被映射到如下的圆环上。然后以每个数据为起点，沿顺时针方向找到离其最近的下一个服务器节点，那么这个数据就存储到这台机器上面；一致性，简单理解就是数据和服务器同时hash。如下图所示???然后，假设node2不可用，按照上述原则，只需要将node1和node2之间的数据迁移到node4上即可；如果在node2和node4之间添加一个节点node5，，只需要将node4和node5之间的数据迁移到node5上，这样，一来保证其他所有结点都是可用的（当然如果要保证当前正在迁移的节点也可用，只需要保证在迁移完成之前数据不删除即可）；另外一方面，我们需要迁移的数据量只是其中的一小部分而已，对性能要求不再那么高。然而，当前这个模型还是存在一个问题,如何保证数据在各个节点上分布平衡？一种完善方案是对每个节点设置多个虚拟的结点，以其ip+后缀hash均匀映射到圆环的各处。这样原本可能存储很多数据的节点就有可能被虚拟节点分成，从而达到一定的数据平衡。?????? Consistent Hash实现其实不复杂，可以参照以下例子：?[java]view plaincopyprint?import?java.util.Collection;??i