分散式系統的最大難點就是各個節點如何保持一致。最近我在工作中就遇到這樣的問題，不同節點之間，彼此通過API，進行通訊，互動資料，但有些服務節點存在延遲等問題，導致我看到的並不是實時的資料，以及系統更新時，更新A服務，間接影響到B服務，而B服務受到影響後，C服務隨之受到影響，以此類推。對於公司技術架構平臺設計者之一的我而言，雖然採用一些臨時性措施解決了這些問題，但我不得不深入的去思考分散式一些本質上的東西，因為很多問題不從根本上弄清楚並解決，後面只會以一種或多種不同的狀態存在著。搞清楚理論並帶著直面的問題思考，或許能找到解決問題的最佳方式。
一、什麼是CAP理論(引用維基百科解釋)？
在理論電腦科學中，CAP理論，又被稱作布魯爾定理，它指出對於一個分散式計算系統來說，不可能同時滿足以下三點：
- 一致性(等同於所有節點訪問同一份最新的資料副本）；
- 可用性(每次請求都能獲取到非錯的響應——但是不保證獲取的資料為最新資料)；
- 分割槽容錯性(以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇)。
C對應的是一致性，A對應的是可用性，P對應的是分割槽容錯性。
二、為什麼說C、A、P只可同時滿足兩點，而不能三者兼顧呢？
一致性、可用性，分割槽容錯性，分割槽容錯性是一致性和可用性的前提。
這裡我引用《分散式服務架構:原理、設計與實戰》來解釋為什麼不能三者兼顧，該書是這樣概括:
CAP原理證明，任何分散式系統只可滿足以上兩點，無法三者兼顧。由於關係型資料庫是單節點無複製的，因此不具有分割槽容錯性，但是具有一致性和可用性，而分散式的服務化系統都需要滿足分割槽容忍性，那麼我們必須在一致性和可用性之間進行權衡。如果在網路上有訊息丟失，也就是出現了網路分割槽，則複製操作可能會被延後，如果這時我們的使用方等待複製完成再返回，則可能導致有限時間內無法返回，就失去了可用性；而如果使用方不等待複製完成，而在主分片寫完後直接返回，則具有了可用性，但是失去了一致性。
三、C、A、P究竟該如何取捨？
從我個人的角度來看，並結合目前的情況，分割槽容錯性和可用性於我們目前是最重要的，資料上我們可以允許有一定或部分的延遲。A和P是適合我們目前的情況。
四、那麼如何實現A和P呢？即如何實現可用性和分割槽容錯性？
最直接的方式就是分散式(分散式中的每個節點都需要叢集，通過叢集的冗餘極大的保證可用性，不同節點的職責保證系統的穩定性)，綜合利用多臺伺服器提高整體效能，這個效能包括提高容錯率、提高併發處理能力、各個節點的伺服器計算能力等。
之前寫過一篇文章《從單體架構到分散式微服務架構的思考》或許讓大家對分散式應用系統有一定的理解。
五、總結
近來遇到了很多問題，讓我不得不更深入地學習與思考，在不斷深入地學習與思考以及實踐過程中，摸索出適合公司的分散式架構體系，但這並不是一件很容易的事情，面對著很多突發情況和問題，我需要保持冷靜，並積極尋找問題解決的辦法。