a: atom icity 原子性 乙個事務（transaction）中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節
c: consistency 一致性 事務開始之前和事務結束以後， 資料庫 的完整性沒有被破壞
i: isolation 隔離性 資料 庫允許多個 併發 事務同時對其資料進行讀寫和修改的能力，隔離性可以防止多個事務併發執行時由於交叉執行而導致資料的不一致。事務隔離分為不同級別，包括讀未提交（read uncommitted）、讀提交（read committed）、可重複讀（repea tab le read）和序列化（seriali zab le）
d: durability 永續性 事務處理結束後，對資料的修改就是永久的，即便系統故障也不會丟失
「補償」機制的意義
以電商的購物場景為例：
客戶端 ---->購物車微服務 ---->訂單微服務 ----> 支付微服務。這種呼叫鏈非常普遍。
那麼為什麼需要考慮補償機制呢？
正如之前幾篇文章所說，一次跨機器的通訊可能會經過dns 服務，網絡卡、交換機、路由器、負載均衡等裝置，這些裝置都不一定是一直穩定的，在資料傳輸的整個過程中，只要任意乙個環節出錯，都會導致問題的產生。
而在分布式場景中，乙個完整的業務又是由多次跨機器通訊組成的，所以產生問題的概率成倍數增加。
但是，這些問題並不完全代表真正的系統無法處理請求，所以我們應當盡可能的自動消化掉這些異常。
我們的思路是基於 dubbo 完成業務失敗後的補償 那麼需要考慮如下幾個問題
如何識別業務失敗？
是否所有的rpc呼叫在失敗後都需要補償
補償需要依據的資料從何處獲得？
如何進行補償？
補償失敗怎麼處理？
第乙個問題比較簡單 我們很容易想到和本地事務一起考慮 當本地事務出錯發生回滾的時候任務業務失敗 此時需要針對性的補償
某些rpc介面只是單純的進行獲取資料 當然無需進行補償需要補償的都是會對資料進行修改的 也就是說查詢類等介面是無需補償的
這個問題比較複雜 不過對於系統來說常見的方案就是依據【可補償rpc方法===》姑且這麼稱呼吧】的引數
或者返回值【比如返回了
id 等等】
由於 分布式 環境下的服務拆分 設想中補償應該也發生在微服務被呼叫方 因此依然需要通過rpc進行呼叫【需要注意的是補償方法不應該被業務呼叫】也就是說在發布服務方需要針對需要補償的方法做乙個特殊標記 同時針對該方法提供乙個補償方法 該補償方法包含一些必要引數【比如可補償方法的引數或者返回值等等】 當發生業務回滾需要被遠端呼叫
可以針對性的重試【注意方法
冪等 ，可以依靠狀態機等等 不要額外丟擲異常】當然重試也無法成功的話就通過日誌 郵件 等人工提醒兜底
簡單學習一下dubbo
什麼是dubbo？dubbo是乙個分布式服務框架，致力於提供高效能和透明化的rpc遠端服務治理方案，以及soa服務治理方案。什麼是rpc?什麼是soap？嚴格分離模組，使用介面呼叫服務 dubbo框架？0.服務容器負責啟動，載入和執行服務提供方 1.服務提供方啟動時向註冊中心註冊自己提供的服務 2....
dubbo的原理，實現
config 配置層 對外配置介面，以 serviceconfig,referenceconfig 為中心，可以直接初始化配置類，也可以通過 spring 解析配置生成配置類 proxy 服務 層 服務介面透明 生成服務的客戶端 stub 和伺服器端 skeleton,以 serviceproxy ...
dubbo擋板的實現
實際開發或者測試過程中，因為服務端的不穩定，希望能在客戶端實現擋板功能。下面介紹如何利用 dubbo reference的stub屬性來實現擋板功能。首先，看下dubbo官網對stub的描述 stub 服務介面客戶端本地 類名，用於在客戶端執行本地邏輯，如本地快取等，該本地 類的建構函式必須允許傳入...