2.1 什么是一致性

指分布式服務(wù)化系統(tǒng)之間的 弱一致性卫漫，包括 應(yīng)用系統(tǒng)的一致性 和 數(shù)據(jù)的一致性打却。

2.2 一致性問題

同步調(diào)用超時闻牡、異步回調(diào)超時蔼紧、系統(tǒng)間狀態(tài)不一致蛾号、緩存和數(shù)據(jù)庫不一致仰剿、本地緩存節(jié)點不一致等

2.3 解決一致性問題的模式和思路

2.3.1 酸堿平衡理論

• 1. ACID（酸）
• 2. CAP（帽子原理）
     一致性通今、可用性沛厨、分區(qū)容忍性系馆。只能同時滿足2點。而分布式服務(wù)化需要滿足 分區(qū)容忍性搂蜓， 所以需要在 C和A間權(quán)衡狼荞。
• 3. BASE（堿）
     解決了CAP的A和P不可兼得的問題。
     其滿足CAP原理帮碰，但是通過犧牲強(qiáng)一致性獲得可用性相味。
     軟狀態(tài)：
     是實現(xiàn)BASE思想的方法，基本可用和最終一致是目標(biāo)殉挽。
     系統(tǒng)在進(jìn)行每步操作時丰涉，通過記錄每個臨時狀態(tài)，在系統(tǒng)出現(xiàn)故障時可以從這些中間狀態(tài)繼續(xù)處理未完成的請求或者退回到原始狀態(tài)斯碌，最終達(dá)到一致狀態(tài)一死。
     例如：
     持久化執(zhí)行的狀態(tài)和環(huán)境信息，通過定時任務(wù)撈取未執(zhí)行的數(shù)據(jù)傻唾。一般采用DB來記錄中間的 軟狀態(tài)

• 4.對酸堿平衡的總結(jié)
  記錄事務(wù)的軟狀態(tài)（中間狀態(tài)投慈、臨時狀態(tài)），若出現(xiàn)不一致冠骄，則系統(tǒng)自動化撈取修復(fù)伪煤。

2.3.2 分布式一致性協(xié)議

• 1. 兩階段提交
     存在的問題：單點阻塞、單點故障凛辣、數(shù)據(jù)不一致
• 2. 三階段提交
     改進(jìn)：增加了詢問（較少了鎖定沖突）抱既、增加了超時機(jī)制
     問題：數(shù)據(jù)不一致問題依然存在，只是減少了點而已扁誓。
• 3. TCC
     問題：復(fù)雜

2.3.3 保證最終一致性的 通用模式

引言：TCC也是過于復(fù)雜的防泵，要實現(xiàn)t，c跋理，c多個接口择克，略顯臃腫。現(xiàn)實系統(tǒng)的底線是 僅僅需要達(dá)到最終一致性前普，而不是需要復(fù)雜的一致性協(xié)議肚邢。以下是一些非常有效，并且簡單的模式拭卿。

• 1. 查詢模式
• 2. 補(bǔ)償模式
     補(bǔ)償：
     為了讓系統(tǒng)最終達(dá)到一致狀態(tài)而做出的努力都叫做 補(bǔ)償骡湖。
     補(bǔ)償操作根據(jù)發(fā)起形式分為：
     自動恢復(fù)：程序根據(jù)發(fā)生不一致的環(huán)境，通過繼續(xù)進(jìn)行未完成的操作峻厚，或者回滾已經(jīng)完成的操作响蕴，來自動達(dá)到一致狀態(tài)。
     通知運營：
     技術(shù)修復(fù)：
• 3. 異步確保模式
     是補(bǔ)償模式的一個典型案例惠桃，應(yīng)用在對響應(yīng)要求不高的場景浦夷。
• 4. 定期校對
     問題：如何發(fā)現(xiàn)需要補(bǔ)償?shù)牟僮?br> 答案：通過唯一ID串聯(lián)所有記錄
     問題：唯一ID怎么生成
• 5. 可靠消息模式
     引言：為什么需要
     回答：即使消息系統(tǒng)辖试，如kafka可以通過設(shè)定發(fā)送方式為同步發(fā)送來實現(xiàn)消息發(fā)送的同步性和ack。但是如果kafka短暫不可用劈狐，咋整罐孝？還是需要業(yè)務(wù)方通過DB先存儲一份，等kafka可用后再發(fā)送肥缔，這樣莲兢，無論如何都能保證消息可靠發(fā)送。
     當(dāng)然续膳，如果公司有kafka可以通過集群冗余+同步發(fā)送模式改艇，那么應(yīng)該可以保證消息發(fā)送后的不丟失，但是還是保證不了消息的可靠發(fā)送７夭怼Ｚ诵帧！
     a. 消息的可靠發(fā)送
     a.1 在發(fā)送消息之前將消息持久到數(shù)據(jù)庫社付，狀態(tài)標(biāo)記為 待發(fā)送舵变，然后發(fā)送消息，如果發(fā)送成功瘦穆，則將消息改為發(fā)送成功。定時任務(wù)定時撈取異常數(shù)據(jù)赊豌。
     當(dāng)然扛或，也可以由第三方來持久化消息+撈取
     b. 消息處理器的冪等性

• 6.緩存一致性模式
  用分布式緩存，不要使用本地緩存碘饼。
  數(shù)據(jù)庫與緩存只需要保持 弱一致性熙兔，而不需要強(qiáng)一致性（此觀點再議。艾恼。住涉。。）

2.4 超時處理模式

2.4.1 微服務(wù)的交互模式 - 分為3類

• 同步調(diào)用
  適用于 大規(guī)模钠绍、高并發(fā) 的 短小 操作舆声，而不適用于 后端負(fù)載較高（即處理邏輯較重、耗時）的場景柳爽。
  正例如：jdbc都是阻塞型的同步調(diào)用媳握，因為都是大規(guī)模、高并發(fā)磷脯、短卸暾摇（sql耗時短）。
• 異步調(diào)用：異步回調(diào)
  適用于非核心鏈路的 負(fù)載較高的環(huán)節(jié)赵誓，這個環(huán)節(jié)經(jīng)常耗時較長打毛、并對時效性要求不高柿赊。
• 消息隊列異步處理模式
  適用于 上游不關(guān)心下游的處理結(jié)果，下游也不需要向上游返回處理結(jié)果的場景幻枉。例如發(fā)布人員入職消息碰声，供各方監(jiān)聽。

2.4.2 同步與異步的 抉擇

如果性能不是問題展辞，或者處理的都是高并發(fā)短小操作奥邮，那么選擇同步比較理想，也能避免引入異步回調(diào)的復(fù)雜性罗珍。
如果業(yè)務(wù)允許洽腺、產(chǎn)品交互允許、處理耗時等覆旱，可以選擇異步蘸朋。

2.4.3 交互模式下 超時問題 的解決方案

A：同步調(diào)用的超時

• 引言：一般有2種方案
  兩狀態(tài)：成功、失敗
  三狀態(tài)：成功扣唱、失敗 和 處理中
• 兩狀態(tài)的同步接口
  快速失敗的方式藕坯。在失敗時，可采用重試噪沙，但要主要冪等
• 三狀態(tài)的同步接口
  返回給使用方一個中間狀態(tài)炼彪。
  傾向于給用戶更好的體驗，后臺盡最大努力成功處理用戶請求正歼。
  超時解決方案是：
  等待使用方查詢辐马，使用方可能采取重試，這樣服務(wù)方保證冪等局义。服務(wù)方不需要通知喜爷，也實現(xiàn)不了。

B：異步調(diào)用模式下的解決方案

• 引言：返回狀態(tài)一般有2種： 受理 和 未受理萄唇。 異步處理返回結(jié)果的通知也是2種：處理成功和失敗

• 異步調(diào)用接口超時
  超時解決方案：
  跟同步的兩狀態(tài)檩帐、三狀態(tài)一樣：通過 查詢 來補(bǔ)齊狀態(tài)，并根據(jù)狀態(tài)來判斷是繼續(xù)重試還是咋地另萤。

• 異步調(diào)用內(nèi)部超時
  超時解決方案：
  除了跟三狀態(tài)的一樣外湃密，還需要在 處理成功后，異步回調(diào)通知使用方四敞。

• 異步調(diào)用回調(diào)超時
  超時解決方案：補(bǔ)償兜底勾缭，確保回調(diào)通知一定可送達(dá)（以回調(diào)結(jié)果為準(zhǔn)）目养×┯桑回調(diào)頻率可采用 指數(shù)回退。

C：消息隊列異步處理模式的解決方案

• 生產(chǎn)者超時
  超時解決方案：參照 可靠消息模式部分（通過DB先落數(shù)據(jù)來解決癌蚁，類似于 WAL 預(yù)寫日志）
• 消費者超時
  消費者直到真正消費成功時幻梯，才能從服務(wù)器移除消息兜畸！

2.4.4 超時補(bǔ)償?shù)脑瓌t

• 補(bǔ)償模式有 調(diào)用方補(bǔ)償 和 接受方補(bǔ)償 2種。（上邊的超時處理方法也是2種 快速失敗 和 內(nèi)部補(bǔ)償）
• 服務(wù)間調(diào)用超時的補(bǔ)償原則
  1.接收方應(yīng)該先 持久化 消息或者數(shù)據(jù)碘梢，才能告訴發(fā)起方接收成功咬摇。隨后接收方才開始處理持久的消息。防止服務(wù)進(jìn)程被殺等導(dǎo)致數(shù)據(jù)丟失煞躬。
  2.如果接收方?jīng)]有給出明確的接收響應(yīng)（返回了異掣嘏簦或返回狀態(tài)不對），那么發(fā)起方應(yīng)該持續(xù)重試恩沛，直到接收方明確表示已經(jīng)接收消息在扰。（接收方冪等、濾重）