提及分布式key-value 存储系统， Memcached, Voldemort, Cassandra,包括淘宝最近开源，我们一直在使用的Tair 系统，相信大家都不会觉得陌生。本文会从 Tair 入手，介绍分析一下传统分布式键-值存储系统的原理，架构和使用技术。错误之处，还望大家指正。 先看一下 Tair 的架构： 乍一看，会发现 Tair 的系统架构和 TFS 一样，都基于了 Google 的GFS 设计，主要包括三部分： 其中 ConfigServer 主要负责管理维护 DataServer 以及和 Client 端的部分通信； DataServer 则是存储对象的地方，数据的增/删/更新都在这里进行； Client 端向服务器请求插入/删除/更新数据； 看完上面的介绍，你可能会有以下几个疑问： 1.configServ er 的真正工作是什么？ 2. DataServ er 如何存储数据？ 3. Client 端只需要和dataServ er 通信吗? 4. 如何实现分布式？ 关于上述第四点如何实现分布式键-值存储系统，我们又要从分布式系统CAP 要求出发：数据一致性，系统可用性，系统分区宽容度（说白了就是如何解决分布式下Serv er 端机器的增减和容错问题）。这几个问题才是分布式应用中最棘手最重要的问题。 接下来，依据个人的理解，结合 Tair 相关知识，对上述问题做一下介绍。 首先，tair 中的configServ er 在物理上是以Master-Slav er 形式部署，作用大家都很清楚，在 Master 不可用或者宕机的时候，slav er 转为 master 对外提供服务。那么是不是configServ er 不能对外部提供就说明所有的客户端都不再可用？答案是否定的，因为configServ er 在 tair 中扮演的是一个非常轻量级的角色，如何理解？为解决这个问题，我们需要解决另外一个问题，如何保证来自客户端的数据在 tair 中均匀的分布，也就是如何对dataServ er 进行负载均衡，另外，如何保证 dataServ er 的数据不会失效？一个简单的模型就是取模，通过对 key 的hash 值对机器个数取模，将其存储到余数对应的机器上。比如有a,b,c,d 四个数据，3 台机器，hash 取 3 模后 a,c 存储到机器1，b 存储到机器2，d 存储到机器3 上。 貌似我们已经解决了问题。经过 hash 和取模操作后，在大数据量情况下，最后数据在三台机器上的分布肯定是比较均匀的，达到负载均衡的目的了？但是，分布式环境下，当机器量比较多时总是不能避免新机器加入或者某台正在使用的机器不可用了，如果是某台机器不可用，那来自客户端对它的所...
