2.1 什么是一致性

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

2.2 一致性問題

同步調(diào)用超時(shí)、異步回調(diào)超時(shí)、系統(tǒng)間狀態(tài)不一致、緩存和數(shù)據(jù)庫不一致、本地緩存節(jié)點(diǎn)不一致等

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

2.3.1 酸堿平衡理論

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

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

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

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

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

引言：TCC也是過于復(fù)雜的，要實(shí)現(xiàn)t，c，c多個(gè)接口，略顯臃腫?，F(xiàn)實(shí)系統(tǒng)的底線是 僅僅需要達(dá)到最終一致性，而不是需要復(fù)雜的一致性協(xié)議。以下是一些非常有效，并且簡單的模式。

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

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

2.4 超時(shí)處理模式

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

• 同步調(diào)用
  適用于 大規(guī)模、高并發(fā) 的 短小 操作，而不適用于 后端負(fù)載較高（即處理邏輯較重、耗時(shí)）的場(chǎng)景。
  正例如：jdbc都是阻塞型的同步調(diào)用，因?yàn)槎际谴笠?guī)模、高并發(fā)、短?。╯ql耗時(shí)短）。
• 異步調(diào)用：異步回調(diào)
  適用于非核心鏈路的 負(fù)載較高的環(huán)節(jié)，這個(gè)環(huán)節(jié)經(jīng)常耗時(shí)較長、并對(duì)時(shí)效性要求不高。
• 消息隊(duì)列異步處理模式
  適用于 上游不關(guān)心下游的處理結(jié)果，下游也不需要向上游返回處理結(jié)果的場(chǎng)景。例如發(fā)布人員入職消息，供各方監(jiān)聽。

2.4.2 同步與異步的 抉擇

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

2.4.3 交互模式下 超時(shí)問題 的解決方案

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

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

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

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

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

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

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

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

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

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

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