如今微信已经成为很多人生活中不可缺少的一部分，无论是在社交、商业推广还是支付领域，微信都有着杰出的表现。自2011年诞生以来，截止到2015年第一季度，微信已经覆盖中国90%以上的智能手机，月活跃用户达到5.49亿，用户覆盖200多个国家、超过20种语言，使用微信支付的用户已经达到4亿左右。微信提供公众平台、朋友圈、消息推送等功能，用户可以通过“摇一摇”、“搜索号码”、“附近的人”、扫二维码方式添加好友和关注公众平台，同时微信将内容分享给好友以及将用户看到的精彩内容分享到微信朋友圈。无论是在火车上、公交车上，还是在餐厅、社区，使用微信的人随处可见，而且微信支付已经越来越成为一种新的消费时尚，微信公众号也越来越多的成为很多商家推广企业文化和各种促销活动的重要途径。
本文将从微信的系统架构、通信泛型、存储一致性、容灾机制等四个方面来分析微信这种分布式系统的特征。
1微信的系统架构
1.1系统架构
微信有着数亿的客户群体，是亚洲地区最大用户群体的移动即时通讯软件，服务业务丰富，每天有海量的数据通信和存储，单是漂流瓶一项服务的文本存储量就有几百G，面对如此强大的功能需求，系统架构的设计也需要满足一些要求。
高性能。对成本的控制是支持移动互联网公司能否存活的问题之一。移动互联网的客户源虽然很高，但是微信不像淘宝，每天有上亿的人在使用微信通讯，跟每天有上亿的人在淘宝购物时不一样的，微信的商业转换率比淘宝要低，所以成本控制更为重要。另一方面，在没有积累到一定的客户数量和客户粘度之前，客户对于服务公司的选择成本很低，用户可以在很短的时间内完成软件的切换和服务公司的选择，可能只需要注册一个账户即可。如果服务质量出现问题，有可能在非常短的时间内造成客户流失。所以服务质量和成本控制是非常重要的。
高稳定性。不难看出，微信是一个海量系统，千万级用户同时在线，一个单独的功能上每天有百亿级的访问，同时还要保证将近百分之百可靠性和稳定性。在海量系统上应对项目开发会有很严谨的规范，都说要尽可能少的变化，因为90%-95%的错误都是在变更中产生的，如果系统一直不变更会获得非常高的稳定度，但是面对很多应用需求的升级和扩展，系统不可能一直不变。
微信的系统架构如图1所示。应用层提供各种服务业务，由接入集群接入服务器集群，中间有一个状态同步集群用于同步不同的服务集群和接入集群，使它们能够达到一致性的存储要求。另外还有诸如存储集群用来存储用户信息和应用信息，业务监控和业务统计等辅助功能模块。这种设计可以在保证服务质量的同时控制成本。
图1 系统架构
1.2腾讯分布式数据仓库
TWD（Tencent Distributed Data Warehouse，腾讯分布式数据仓库）是腾讯专用的分布式数据平台，其特点相对于其他企业级数据存储服务器的特点是成本低、性能高。企业级存储服务器对硬件要求很高，数据的存储和备份都在硬件基础上完成，并且需要昂贵的软件授权。而TWD则可以降低存储成本，构造廉价的分布式数据仓库。TWD是基于开源软件Hadoop和Hive进行构建，打破了传统数据仓库不能线性扩展、可控性差的局限，并且根据腾讯数据量大、计算复杂等特定情况进行了大量优化和改造。
TWD在公司中的作用主要有：
? 提供海量的离线计算和存储服务。TDW服务覆盖了腾讯绝大部分业务产品，单集群规模达到4400台，CPU总核数达到10万左右，存储容量达到100PB；每日作业数100多万，每日计算量4PB，作业并发数2000左右；实际存储数据量80PB，文件数和块数达到6亿多；存储利用率83%左右，CPU利用率85%左右。TDW是腾讯内部规模最大的离线数据处理平台，公司内大多数业务的产品报表、运营分析、数据挖掘等的存储和计算都是在TDW中进行。这是TDW提供的最基础的服务。
? 数据集中于共享功能。腾讯产品线较长，数据丰富，为了挖掘数据价值，经常需要访问多个产品的数据。TDW是腾讯公司级的数据仓库，这里集中了大多数业务的数据，业务在这里可以方便的进行数据共享和管理。
? TDW为其他大数据服提供基础和平台。这有两个含义，首先是TDW对腾讯内部开放各种API接口，很多业务的数应用、数据处理平台可以基于TDW之上，由TDW提供最基础的存储于计算，业务在TDW之上定制个性化的数据产品。其次，TDW内存放了腾讯大量有价值的数据，对于这些数据，各个业务有可能有一些不同的需求，这些需求可以抽象出一些固定的数据服务，如海量数据点查询、快速多维分析、流式计算等，这些服务是TDW衍生出来的精细化的服务
TDW的功能模块主要包括：HDFS、MapReduce、Hive、TDBank、Lhotse等。TDWCore主要包括存储引擎HDFS、计算引擎MapReduce、查询引擎Hive，分别提供底层的存储、计算、查询服务，并且根据公司业务产品的应用情况进行了很多深度订制。TDBank负责数据采集，旨在统一数据接入入口，提供多样的数据接入方式。Lhotse任务调度系统是整个数据仓库的总管，提供一站式任务调度与管理。
随着业务的快速增长，TDW的节点数也在增加，对单个大规模Hadoop集群的需求也越来越强烈。TDW需要做单个大规模集群，主要是从数据共享、计算资源共享、减轻运营负担和成本等三个方面考虑。
1. 数据共享。TDW之前在多个IDC部署数十个集群，主要是根据业务分别部署，这样当一个业务需要其他业务的数据，或者需要公共数据时，就需要跨集群或者跨IDC访问数据，这样会占用IDC之间的网络带宽。为了减少跨IDC的数据传输，有时会将公共数据冗余分布到多个IDC的集群，这样又会带来存储空间浪费。
2. 计算资源共享。当一个集群的计算资源由于某些原因变得紧张时，例如需要数据补录时，这个集群的计算资源就捉襟见肘，而同时，另一个集群的计算资源可能空闲，但这两者之间没有做到互通有无。
3. 减轻运营负担和成本。十几个集群同时需要稳定运营，而且当一个集群的问题解决时，也需要解决其他集群已经出现的或者潜在的问题。一个Hadoop版本要在十几个集群逐一变更，监控系统也要在十几个集群上部署。这些都给运营带来了很大负担。此外，分散的多个小集群，资源利用率不高，机器成本较大。
2通信泛型
微信的通信技术是一种即时通信（Instant Message，IM）技术，即时通信是一种基于网络的通信技术,涉及到IP/TCP/UDP/Sockets、P2P、C/S、多媒体音视频编解码/传送、WebService等多种技术手段。它们大都基于相同的技术原理，主要包括客户/服务器(C/S)通信模式和对等通信(P2P)模式。
在微信的通信技术中，主要采用的是P2P通信模式。在P2P通信网络中，所有的用户没有主从之分，每一个用户都是平等的，都可以承担服务使用者和服务提供者两个角色。用户之间进行直接通信，没有中央节点的集中控制，系统的伸缩性较强，也能避免单点故障，这样有利于提高系统的容错性能。但由于P2P网络的分散性、自治性、动态性等特点，造成了某些情况下客户的访问结果是不可预见的。例如，一个请求可能得不到任何应答消息的反馈。所以当前使用的IM系统大都组合使用了C/S和P2P模式。在登录IM进行身份认证阶段是工作在C/S方式,随后如果客户端之间可以直接通信则使用P2P方式工作，否则以C/S方式通过IM服务器通信，如下图所示：
图2 IM通讯原理图
使用微信可以通过网络快速发送语音短信、视频等。其原理与腾讯QQ类似。当登陆微信时，不管是TCP还是UDP协议，微信都会有一个TCP来保持其在线。当发送消息时，采用UDP协议，通过服务器中转方式。且为了传输的可靠性，腾讯公司采用了上层来保证。当用户发送消息时，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。
2.1 SYNC通信协议
微信的同步协议叫做SYNC，参考了微软的Active SyncSYN chronous Communication：同步通信没有数据发送时，传输线处于MARK状态。为了表示数据传输的开始，发送方先发送一个或两个特殊字符，该字符称为同步字符。当发送方和接收方达到同步后，就可以一个字符接一个字符地发送一大块数据，而不再需要用起始位和停止位了，这样可以明显地提高数据的传输速率。采用同步方式传送数据时，在发送过程中，收发双方还必须用一个时钟进行协调，用于确定串行传输中每一位的位置。接收数据时，接收方可利用同步字符将内部时钟与发送方保持同步，然后将同步字符后面的数据逐位移入，并转换成并行格式，供CPU读取，直至收到结束符为止。用一个Key来实现状态同步。这样一种协议在后台实现上比业界通用方案要复杂许多，但是能把客户端的实现大大简化，同时在很大程度上能够满足iPhone，安卓等多个操作系统的不同需求。
2.2 数据可靠性
消息存储可靠性：WAL+持久化；数据存储多副本；存储节点自动failover；
消息传输可靠性：ACK机制；数据CRC校验；
消息投靠可靠性：producer->broker数据存储后才返回成功确认；broker->consumer数据处理完成后需进行确认；
服务质量级别：不能丢消息；发送消息可能会有重复；极端情况下通过客户端进行数据去重。
2.3 数据顺序性
局部有序：数据在多个队列之间是按发送时间有序的，即每个队列的数据都是在相似的时间间隔范围上按时间递增分布的，局部有序优点就是支持多队列能够提供更高的发送性能，适用于消费端对数据的消费没有绝对要求但是又不能在数据局部时间差距太大的场景。
绝对有序：数据落地到单队列上，发送端只能用单线程同步发送消息并且每发送下一条消息之前都需要保证已收上一条消息的成功返回确认，由于是单队列单线程同步发送因此吞吐量会有所下降，适用于发送峰值不高且对数据消费有绝对顺序要求的场景。
绝对有序性能提升规划：参照TCP协议的实现原理，TCP为了保证数据包的顺序为每个数据包的发送颁发一个顺序且唯一标识当前数据包的ID，为了最大化点利用网络资源并提升性能，采用批量发送的方式而不是逐一发送确认的方式，利用每个数据包发送来回的窗口时间迭代发送多个数据包，最终在服务端进行组包排序。对于丢包的情况，发送端对没有收到服务端回应的包在一定的超时时间之后进行重发。同理消息的发送可以采用相同的方式，服务端只会持久化消息ID连续的消息，对于有间断的情况则需要等待相应空缺的消息ID所对应的消息（可能是网络延迟抵达晚了，可能是丢包了在等待超时机制触发重试）抵达后再进行持久化。这种方式能够解决上述绝对有序的单线程同步发送的低性能场景，通过异步发送的方式达到提升发送吞吐量的目的。
2.4 多点登陆
微信最开始并不支持多点登陆，后来陆续增加的Web版、Mac版，最新的版本已经允许移动端和web/mac端同时在线。
服务器不用保存完整消息历史，通过客户端对push消息的ack保证消息送达，协议保证消息至少一次推送到主客户端，然后消息即可删除；服务器只存储未下发到主客户端的消息。
多点时：主客户端依然采用Push推送消息(只是应该会保留一小段时间消息记录等待从Sync)，从客户端Sync消息；如果主不在线，消息记录不会删除，等主重新连上下载离线消息。
服务器不存储消息历史，一个是安全，再者节省硬件成本，大量短消息的存储和读取成本是非常高的，因为基本都是随机IO。whatapp用500台机器，支撑1亿在线，100w/s消息，只离线消息存储量是很少的。
未读数同步的解决方案是如果客户端知道自己处于多端在线情况下时，进入会话时，需要告诉服务器消息已读。消息已读也保存为一条消息，再通过Sync协议，同步到另外的客户端。web微信会调用同步未读算法。未读变化也当成一条消息存储，且只在多端情况下存在，单点在线时未读数由客户端维护。
删除消息不管是否多点在线任何删除消息操作都会同步到服务器，避免删除的消息下次有不小心同步回来了，服务器可能及时删除、也可能长期保存，客户端每次上报就没错了。移动客户端消息删除不会同步到web版。
3存储一致性
3.1一致性问题
因此我们设计了新一代消息系统Hippo以满足具有高可靠高可用应用场景的业务需求，用以支撑广告计费，交易流水等高价值数据的业务。消息中间件的优势主要有以下几点。
屏蔽异构平台的细节：发送方、接收方系统之间不需要了解双方，只需认识消息。
异步：消息堆积能力；发送方接收方不需同时在线，发送方接收方不需同时扩容（削峰）。
解耦：防止引入过多的API给系统的稳定性带来风险；调用方使用不当会给被调用方系统造成压力，被调用方处理不当会降低调用方系统的响应能力。
复用：一次发送多次消费。
传统消息系统数据丢失风险点：消息系统最大的作用是解藕系统之间的依赖及异步化各系统间的调用。作为系统间消息存储和转发环节，其可靠性对于某些有着精确要求（消息一条都不能丢失）的系统来说显得特别重要。在探讨Hippo的实现之前先来窥探下消息从发送到被存储再到被消费的整个环节存在数据丢失风险的场景。
数据的发送：数据从生产端Producer发往存储端Broker的过程
3.2通信情景
成功：最常见的场景，broker端收到消息并存储成功，给producer返回成功响应且producer收到成功响应信息。
失败：broker端由于繁忙处理不过来直接向producer响应失败，且producer端收到失败响应信息。
超时：对于这种不确定的场景（网络波动、系统异常、连接异常等）所带来的超时则相对复杂。producer收到超时异常可能由如下几种场景导致，可能是发送过程中连接发生异常，数据在到达broker端之前就丢失了，也可能数据到达了broker端且在broker端存储成功了但是在给producer返回结果时发生了超时或网络异常。
从以上三种场景可知，前两种producer收到确定的结果都很好处理，失败做相应的记录或者重发即可。但是对于超时则无计可施，这是网络方面的一个老大难题，超时对于分布式系统来说就简直就是一个噩梦，客户端没有足够的信息判断broker端到底是否处理成功。假设为了保证可靠我们对于所有超时的场景都统一当失败处理进行消息的重发，那么就有可能导致broker端存储到重复的消息，这又引发了对数据进行去重的问题，对于分布式系统做去重就需要引入一个全局的校验节点，毫无疑问这会让系统的整体性能大打折扣。
3.3基于TWD的Hippo系统架构
Hippo系统[5]存在四种角色，分别为生产者（producer）、消费者（consumer）、存储层（broker）、中心控制节点（controller）
Controller:以组的形势存在，三台controller一主两备组成一个组（主备controller存在心跳检测以便在主故障的时候能够自动failover）承担着整个系统节点数据的收集、状态的共享及事件的分发角色。提供控制台界面，根据当前收集到的正常运行的broker节点信息，可以指定给某个特定的broker组下发topic及queue添加事件。
Broker：以组的形势存在，三台broker一主两备组成一个组，由主broker向controller定期汇报心跳以告知controller当前组的存活状态，心跳携带当前组所管理的topic及queue信息。数据在broker以多副本的方式存储，Masterbroker为数据写入入口，并把数据实时同步给同组的两台Slavebroker，主备broker之间存在心跳检测功能，一旦Slavebroker发现Masterbroker故障或者收不到Masterbroker的心跳那么两台Slavebroker之间会从新发起一次选举以产生新的Masterbroker，这个过程完全不用人工介入系统自动切换。因此在broker端不存在单点情况，数据冗余存储在不同的物理机器中，即使存在机器宕机或磁盘损坏的情况也不影响系统可靠对外提供服务。
Producer：轮询发送：向controller发布某个topic的信息，controller返回相应topic所在的所有broker组对应的IP端口及queue信息。producer轮询所获取的broker组信息列表发送消息并保持与controller的心跳，以便在broker组存在变更时，能够通过controller及时获取到最新的broker组信息。
Consumer：负载均衡：每个consumer都隶属于一个消费组，向controller订阅某个topic的消息，controller除了返回相应topic对应的所有broker组信息列表之外还会返回与当前消费者处于同一个组的其它消费者信息列表，当前消费者获取到这两部分信息之后会进行排序然后按照固定的算法进行负载均衡以确定每个消费者具体消费哪个队列分区。同时每个consumer都会定期的向controller上报心跳，一旦消费组有节点数量的变更或broker组存在变更，controller都会及时的通过心跳响应返回给当前组所有存活的consumer节点以进行新一轮的负载均衡。
消费确认：consumer进行消费的过程中对队列分区是以独占的形式存在的，即一个队列在一个消费组中只能被一个消费者占有并消费。为了保证消费的可靠对于每次拉取的数据，都需要consumer端在消费完成之后进行一次确认，否则下次拉取还是从原来的偏移量开始。
限时锁定：为了使某个consumer宕机其占有的队列分区能够顺利的释放并被其他consumer获取到，需要在每个消费者拉取数据与确认回调之间设置一个超时时间，一旦超过这个时间还没确认，那么队列自动解锁，解锁之后的队列最终能够被别的存活消费者占有并消费。
图3 系统逻辑交互图
图4 系统交互图
3.4 数据可用性
Broker宕机或硬件故障
对于broker组只要每个组内依旧有超过半数的节点存活，那么这个broker组便能继续对外提供服务。如果SlaveBroker宕掉不会对生产消费端有任何影响，如果是MasterBroker宕机那么会自动的从两个slave中选出一个新的master。对于宕掉的机器通过监控手段发现后人工重启便会自动的同步宕机过程中滞后于同组节点的数据，直到追上最新数据为止。
Controller宕机或硬件故障
对于controller与broker的情况类似，但是即使controller整个组都同时宕机也不会对当前的系统造成不可用的情况，当前系统将会继续维持目前的平衡状态，任何的broker组变更，consumer变更都不会再次触发系统的均衡，直到controller恢复为止。
存储层容错特点：集群内部过半的服务器写成功才给客户端响应成功；
服务故障自动切换对用户透明；宕机恢复后自动同步数据；机器、磁盘故障无法恢复情况，提供运维工具将故障机器从当前组移出加入新机器即可；
Batchfetch：可自定义批量拉取的条数，通过一次拉取多条消息以减少网络交互的次数提升消费端性能。数据优先从内存获取，只有缓存没有命中的情况才访问磁盘。多队列并行消费提高性能：对于单个队列数据的发送是并行的，但出于保证数据互斥消费（只被一个消费者消费）的需要消费必须是互斥串行的，并行发送串行消费在发送量很大的场景下就会造成消费端处理不过来从而造成消费滞后，为了避免消费滞后可以通过将数据分散到多个队列中去，通过多队列并行消费以提升消费端性能。
3.5 数据稳定性
线程隔离：由于不同接口操作存在特征差异，CPU密集型操作通常能够迅速释放线程，对于IO密型操作则可能会导致线程长时间由于等待IO而被占用，为了保证系统某些关键路径不被流控或由于没有空闲线程而无法得到执行，采用不同线程池隔离不同特征的接口，防止接口间相互干扰，保证系统稳定运行。
流量控制：为了保证系统在高水位运行时不被压垮，需要对系统的整体读写流量做相应限制，采用有界队列的方式积压由于当前系统繁忙而不能马上处理的请求，队列大小可配置，根据系统每秒吞吐量设置相应的阀值。一旦队列没有可用空间（线程处理不过来，请求已经出现积压）为了避免对系统造成进一步的压力broker端此时会拒绝继续服务而直接给请求端响应失败以达到流控的目的。
集群隔离：根据业务的特征分集群部署隔离，防止业务之间相互干扰
3.6 数据重复性
在极端异常情况下可能导致数据重复的场景有两个，一是生产端发送数据时出现超时，这时重发数据可能导致broker端存储到相同的数据。第二种场景则是在consumer消费时成功拉取到数据且已消费完成但在提交的瞬间consumer宕机了，这时当前被消费的队列就可能由于负载均衡而被其他consumer占有并拉取到被之前consumer消费完但未提交的数据。对于第一种场景的解决方案是在服务端进行去重。对于第二种场景则需要在consumer端定义去重接口由业务方自己实现去重逻辑，因为只有consumer端知道数据的消费情况。这两种方案都会给系统引入更大的复杂性和增加一定的性能损耗。由于网络的不可确定性（经典的拜占庭将军问题），消费端数据重复在异常情况下是无法避免的问题，因此consumer进行消费时需确保消费逻辑的幂等性。
服务端去重规划：：broker端在特定消息条数范围之内进行去重，producer生产的每条数据都会携带一个去重特征值用于服务端缓存并进行去重校验，由于producer生产数据是轮询的方式，因此问题关键在于如何将超时重发的数据发往同一个broker端，通常的做法是采用hash方式，但hash的弊端也很明显，其问题在于无法应对hash空间变化的场景，一旦broker缩容或扩容hash定位就会失效。可以通过在消息发送时记录当前消息的发送目标路径并对于失败和超时两种场景区别处理，对于超时则给消息打上超时标记对于失败则不做任何标记，在重试时通过超时标记来预判采用之前记录的发送路径还是轮询的方式以达到去重的目的。服务端去重只能保证接收到发送端的数据不重复存储，从服务端投递到消费端的数据的去重依旧必须由消费端自己保证。
4容灾机制
2014年5月，微信发生大规模连接故障，多地用户反馈无法连接服务器，三小时后部分恢复正常。原因是市政道路施工致机房光缆被挖断，影响服务器连接所致。作为全球下载量和用户量最多的通信软件，这一故障引发连锁反应。可能产生股价下跌、客户流失等灾难性后果。故而容灾处理能力的建设非常重要。
4.1几种常见的容灾案例
Quorum_KV是微信开发的一套数据强一致性存储系统，主要支持key-table和string-value两种存储模型。系统目前支持的特性有:
? 强一致性的Quorum容灾方案，支持读写容灾，双机互备，双向可写；
? 丰富的业务开发模型：
? 支持类SQL接口(不支持事务)，提供丰富查询和更新接口；
? 支持string-val的高性能key-val接口；
? 支持专用于存储索引的64bit有序数组接口；
? 支持多机房部署容灾，目前支持kv2和kv6两种部署模式；
? 支持自动化数据迁移扩容；
? 高性能，在string-val模式下，已到达20wqps。
系统采用强一致性的Quorum协议，它借鉴了paxos的思想，实现上更加简洁，解决了在多台机器并发写入时的数据一致性问题。
而在最终一致性策略上，不同的系统有不同的策略或者其组合方式，包括：Quorum的NWR策略、两阶段提交协议、第三方、时间戳、版本号等。比如hold/ckv/tair都加了一个第三方来检测主备数据一致性，大家在落地+同步+对比检测修复的思路基本一样。
4.2 Quorum容灾方案
在分布式系统中，冗余数据是保证可靠性的手段，因此冗余数据的一致性维护也就非常重要。一般而言，一个写操作必须要对所有的冗余数据都更新完成了，才能称为写成功。比如一份数据在5台设备上有冗余，因为不知道读数据操作会在哪一台设备上进行，所以一次写操作，必须5台设备都更新完成，写操作才能返回。Quorom是用来保证数据冗余和最终一致性的投票算法，其主要数学思想来源于鸽巢原理。在有冗余数据的分布式存储系统当中，冗余数据对象会在不同的机器之间存放多份拷贝，但是同一时刻一个数据对象的多份拷贝只能用于读或者用于写，只有这样才能保证同一份数据不会同时被两个访问对象读写，保证数据的一致性。
该算法要求分布式系统中的每一份数据拷贝对象都被投票一次。每一个操作必须要获得最小的读票数（Vr）或者最小的写票数(Vw）才能读或者写。如果一个系统中的数据对象有N份冗余拷贝，那么这最小读写票必须同时满足：
Vr + Vw > N
Vw > N/2
第一条规则保证了一个数据不会被同时读写。当一个写操作请求过来的时候，它必须要获得Vw个冗余拷贝的许可。而剩下的数量是N-Vw 不够Vr，因此不能再有读请求过来了。同理，当读请求已经获得了Vr个冗余拷贝的许可时，写请求就无法获得许可了。
第二条规则保证了数据的串行化修改，一份数据的冗余拷贝不可能同时被两个写请求修改。
4.2容灾切换
容灾切换是指一个地方的服务器发生故障的时候，鼓舞能迅速转移到备份处理器上，并且对用户透明的能力，即不会影响用户使用。类似的，容灾系统是指在相隔较远的异地，建立两套或多套功能相同的服务系统，互相之间可以进行健康状态监视和功能切换，当一处系统因不可抗因素停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个系统的影响，提供节点级别的系统恢复功能。
容灾切换方案总体来看就两类：一种是主设备切换模式，切换时提供短暂只读迅速恢复或者黑名单机制来保障灾难时服务的可用性，把损失降低到最低；另外一种是用类似paxos协议或者分布式锁和两阶段提交协议来保障强一致性，但是会牺牲一部分性能，多备份的扩展性也会略差。
参考文献
[1] 微信平台首份数据研究报告，龙兵华，靳志辉
[2] 腾讯TDW：大型Hadoop集群应用
[3] http://www.useit.com.cn/thread-10587-1-1.html
[4] http://www.cnblogs.com/netfocus/p/3622184.html
[5] 分布式高可靠消息中间件－Hippo
[6] 大数据分析的分布式MOLAP技术，宋杰，郭朝鹏，于戈