仓库源文，站点原文

layout: post title: 分散式事務系統架構設計與心得 categories:

- 筆記

前言

本文所研究之系統，應用場景為需要高度正確性、一致性、低故障後恢復時間的交易系統、金融系統

與需要高並發，低延時的網站系統、訂票系統，著重的特點略有不同

Intro.

分散式事務 Distributed transaction 或稱分佈式事務

一個資料庫事務通常包含了一個序列的對資料庫的讀/寫操作。它的存在包含有以下兩個目的：為資料庫操作序列提供了一個從失敗中恢復到正常狀態的方法，同時提供了資料庫即使在異常狀態下仍能保持一致性的方法。當多個應用程式在並發訪問資料庫時，可以在這些應用程式之間提供一個隔離方法，以防止彼此的操作互相干擾。

一個分散式應用系統(如交易系統、網站系統、網路遊戲系統等)內通常包含運算、傳輸、資料數據記錄等功能，其中對於資料數據的紀錄操作通常交由資料庫系統處理，即資料庫事務(database transaction)。在中小型系統架構中，可能以資料庫提供之資料表分表、資料庫叢集等功能以滿足系統的scalability和availability，即依賴的是資料儲存層。而一個大型系統可能橫跨多種資料庫系統或外部系統，這時就有在業務層自行實作分散式事務系統的需求性。

剛性事務 vs 柔性事務

剛性事務：必須滿足ACID理論，即事務進行期間，資源被鎖定，其他事務不能存取該資源柔性事務：滿足BASE理論，相對於剛性事務，分為幾種類型

補償型
二階段型
異步確認型
最大努力通知型

ref: http://kaimingwan.com/post/fen-bu-shi/fen-bu-shi-shi-wu-de-dian-xing-chu-li-fang-shi-2pc-tcc-yi-bu-que-bao-he-zui-da-nu-li-xing

對事務特性分類，有助於尋找不同使用情境下適合的演算法

一致性

強一致性

數據一旦更新後，任何讀取都能馬上返回剛剛更新的結果

弱一致性

不保證馬上更新，盡量在某個時間點後保證返回更新的結果

最終一致性

分散式事務的幾種可能作法

TCC事務 try/confirm/cancel (補償型)

對已提交的事務有取消後的補償回滾機制，適用此方法

2PC 二階段提交 (二階段型)

全局寫日誌以進行重建或回復

master發送訊息給所有slave，確認皆可完成後才提交

效能影響較大 (request次數、等待最慢slave)

延伸有3PC 三階段提交

消息狀態確認系統

發起方重送請求接收方透過滿足冪等性，解決重複請求問題

ref: http://www.cnblogs.com/LBSer/p/4715395.html

http://www.cnblogs.com/xybaby/p/7465816.html

http://www.cnblogs.com/xybaby/p/6871764.html

http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed

ref: 上海交易所的技術主管 http://blog.sina.com.cn/drwjf

以下待補

Paxos Raft, Message Queue

消息隊列系統 Message Queue

Quorum(NRW)算法

對數據分散式儲存如果利用多台機器允餘的作法

需要對所有機器寫入成功後從任一台讀取

而NRW算法透過鴿籠原理，減少寫入需要的機器數，增加讀取需要的機器數滿足

但內部仍然會維持所有機器數據相同

https://juejin.im/entry/5a1549786fb9a0451b0431ea

Software Transactional Memory

STM依賴語言或lib層面的支援，做於lock-free算法使用

保證變數存取間就算無鎖，也會讓多執行緒看起來不是交錯執行

從而保證修改前後的一致性(不會觀察到修改中的數值)

http://blog.yoco.io/2012/09/transaction-memory.html

Sharding-JDBC 源码分析 —— 分布式事务（一）之最大努力型