最佳實戰-分布式一致性解決方案
接觸了業界一些針對於分布式服務的一致性解決方案後，接下來總結下自己在面對一致性問題的一些方案和思路，其實很多時候我理解分布式服務的一致性一定要以可靠性為基礎、簡潔性為目標去考量方案，當然前提是滿足我們的分布式需求、高併發高效能以及吞吐量為前提。總結了幾種比較高效的處理模式。
•主動查詢模式：所有的操作都提供乙個查詢介面，用於向外部輸出操作執行的狀態，服務操作的使用方可以通過查詢介面而得知服務操作執行的狀態。然後根據不同的狀態來做不同的處理操作。那麼這種模式通常可以針對於我們
q2的問題（同步呼叫超時），也就是同步呼叫超時的場景下使用 。
策略：servicea在請求serviceb，execute（params..）進行寫操作的同時，要帶著status狀態來標示操作是否成功，保障在出現超時熔斷的時候，servicea可以啟動主動查詢serviceb的操作status值來判斷結果；
1.效能要求高，即時性要求不高，可以使用資料庫來進行status狀態的儲存及主動查詢的目標；
2.效能要求高，即時性要求也高，那麼就不能使用資料庫來作為主動查詢方案的目標，寫庫的同時把status放入記憶體中，按照時間持久化原則後期在使用讀庫；
實際場景解決方案：乙個操作流程中包含三個關聯操作，servicea 操作本地資料庫table1做持久化操作，成功後請求serviceb對資料庫table做持久化操作，請求timeout100ms，如果serviceb操作成功並返回結果那麼servicea 在根據serviceb返回的資料對table2做持久化操作；
比如系統a呼叫系統b但是出現系統
a超時的情況，這個時候我們的系統
a主動呼叫發起查詢介面，去確認當前呼叫的處理方（也就是系統
b）的真實狀態，如果系統
b執行的預設任務返回成功，則系統
a可以繼續執行其他後續邏輯；如果系統
b執行的預設任務返回失敗，我們可以根據需求進行重試和直接對上游（也就是使用方）返回失敗等可確定性的操作。如果系統
b執行的預設任務返回未知狀態，我們也可以根據實際情況，具體需求去判斷到底需不需要重試，重試的話系統
b有沒有做到冪等，如果呼叫時間不可容忍也可以採用快速失敗策略，然後對系統
b去呼叫業務的逆向操作（或者記錄逆向操作日誌），然後後續進行回滾和補償系統
b的執行結果，最終達到雙方的一致狀態。
•補償模式：通常與主動查詢模式結合使用，目的都是為了實現上下游的服務最終一致性的努力確保機制。
•非同步確保模式、可靠性訊息模式：（對即時性和實時性要求不高的時候會採用）
非同步確保模式、可靠訊息模式：這兩種模式也是網際網路行業中經常需要使用的經典模式，很多時候我們的使用方對響應時間 要求不太高、或者說不需要特別強調實時性的場景，這一類的操作我們經常採用非同步化、或者解耦的方式，把其從主流程（核心鏈路上摘除） ，或者說我們劃分好業務邊界，然後再可以容忍的視窗期內做非同步確保和傳送可靠性訊息模式。這個方案最大的好處是能夠對高併發流量進行削峰，從而對服務上能夠提供解耦。比如我們電商系統中的物流、配送等，金融系統中的支付、計費入賬等等。
當下單的主資訊落庫成功後就返回下單成功的訊息給使用者，將其他訊息出入josn中，非同步分別落庫；注意要在給serviceb傳遞訊息的是要做到可靠性訊息傳遞模式，具體serviceb可能收到很多次訊息那麼serviceb自己做冪等性來保障；
•定期校對模式
：這種方式多用於網際網路金融行業，一般都是針對商戶與平台與銀行等第三方金融支付平台之間的乙個經典場景，因為涉及資金安全，所以對於網際網路金融行業會對其進行多重的一致性保證機制，比如商戶交易對賬、系統間一致性對賬、財務對賬等等。這種也是針對於場景而言的。一般對實時性要求最低，但是對準確性、一致性要求最高。
理論上來講
q2（同步）、q4（掉單場景）
都可以通過非同步確保、可靠性訊息、定期校隊模式去解決，但是具體實際問題還得具體分析和評估合理性。
快取一致性的問題
•在大規模分布式的系統中，乙個場景的核心需求就是億級別的讀需求，顯然關係型資料庫不是解決高併發的最佳方案，網際網路行業通常的做法就是使用快取來抗住讀流量，那麼如何保障快取和資料庫的一致性，我也大概彙總和劃分幾點必須要做和清楚的事情：
•如果效能要求不是非常高，則盡量使用分布式快取（reids），不要使用本地快取。
•寫快取時資料一定要完整，如果快取資料一部分有效，另一部分無效，則寧可在需要時回源資料庫抽取，也不要把部分資料放入快取。
•使用快取就犧牲了一致性，為了提高效能，資料庫與快取只能保證且只需要保持弱一致性即可，否則其他的做法即違背了快取的目的也浪費了太多的系統效能。
•讀的順序是先讀快取再讀資料庫，寫的順序一定要先寫資料庫再寫快取。
在網際網路企業不會使用分布式事務（使用策略解決），也不會使用事務。
分布式系統一致性問題解決實戰
業務背景 商戶提交表單資料至旺鋪 deco專案，以下皆稱為deco deco需要接入poi系統進行裝修內容的人工審核，詳細流程見下圖。店鋪裝修審核狀態在deco系統和poi系統之間不一致，下圖中1，2，3步提交流程會出現同一次提交審核流在deco系統中的裝修狀態為未裝修，而在poi系統為審核中。同樣...
分布式系統一致性問題解決實戰
業務背景 商戶提交表單資料至旺鋪 deco專案，以下皆稱為deco deco需要接入poi系統進行裝修內容的人工審核，詳細流程見下圖。店鋪裝修審核狀態在deco系統和poi系統之間不一致，下圖中1，2，3步提交流程會出現同一次提交審核流在deco系統中的裝修狀態為未裝修，而在poi系統為審核中。同樣...
分布式系統與一致性問題
分布式這個概念這幾年越來越火熱，今天也來談談專案改造過程中對於分布式系統的理解，傳統的應用是將所有的模組放在單體tomcat上執行，所以方法間的呼叫範圍都是在同乙個jvm內。這在業務初期時很有效的，畢竟業務初期開發資源 業務量都比較稀少，才用單體應用開發簡單 部署快速，出現問題可以快速定位，而且因為...