分佈式事務網摘

consul集羣 

http://www.cnblogs.com/shanyou/p/4695131.html

http://www.cnblogs.com/yatingyang/articles/4495098.html

raft算法

http://www.cnblogs.com/mindwind/p/5231986.html

 

ETCD

https://yq.aliyun.com/articles/11035

 

http://blog.chinaunix.net/uid-25267728-id-4615829.html

 

理解HTTP冪等性

  http://www.cnblogs.com/weidagang2046/archive/2011/06/04/2063696.html

 

Paxos實現庫

https://bitbucket.org/sciascid/libpaxos/src/d255f8b67a32d5e0ef43ac1a393b72cee23d8e0e/sample/?at=master

 

藍綠髮布的整個部署過程

http://www.tuicool.com/articles/2Iji2ue

分佈式事務：不過是在一致性、吞吐量和複雜度之間，作一個選擇

http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598134&idx=1&sn=f5f73354d162a7561b3d73c204a4d1f5&scene=0#rd

 

 

兩階段提交、三階段提交

這種分佈式事務解決方案目前在各類技術平臺上已經比較成熟：JavaEE架構下面的JTA事務（各應用服務器均提供了實現，Tomcat除外）。

但目前兩階段提交、三階段提交存在以下的侷限性，並不適合在微服務架構體系下使用：

• 全部的操做必須是事務性資源（好比數據庫、消息隊列、EJB組件等），存在使用侷限性（微服務架構下多數使用HTTP協議），比較適合傳統的單體應用；

• 因爲是強一致性，資源須要在事務內部等待，性能影響較大，吞吐率不高，不適合高併發與高性能的業務場景；

 

 

Sagas事務模型的實現機制：

• 每一個業務活動都是一個原子操做；

• 每一個業務活動均提供正反操做；

• 任何一個業務活動發生錯誤，按照執行的反順序，實時執行反操做，進行事務回滾；

• 回滾失敗狀況下，須要記錄待衝正事務日誌，經過重試策略進行重試；

• 衝正重試依然失敗的場景，提供定時衝正服務器，對回滾失敗的業務進行定時衝正；

• 定時衝正依然失敗的業務，等待人工干預；

Sagas長事務模型支持對數據一致性要求比較高的場景比較適用，因爲採用了補償的機制，每一個原子操做都是先執行任務，避免了長時間的資源鎖定，能作到實時釋放資源，性能相對有保障。

 http://www.cnblogs.com/wz12406/p/5712318.html

https://www.zhihu.com/question/35032171