如今微信已經成爲很多人生活中不可缺少的一部分，無論是在社交、商業推廣還是支付領域，微信都有着傑出的表現。自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協議或者分佈式鎖和兩階段提交協議來保障強一致性，但是會犧牲一部分性能，多備份的擴展性也會略差。