分佈式重複提交問題架構設計思路

數據列加惟一索引，重複數據保存失敗。

有多餘兩臺Web容器時，併發查詢，單機鎖不能確保查詢的準確性。

 

要用分佈式鎖：

http://www.cnblogs.com/younldeace/p/7462286.html

redis的單線程鎖，通常能解決，可是並不完美。弊端：redis的鎖租期，沒法續期，業務邏輯用鎖時間不可能肯定；單機redis容易單點故障，多節點的話，主從複製時，或者由於單點故障，主備切換數據同步時，均可能致使分佈式鎖的惟一性不成立的狀況。

進一步給redis加上鎖租期的能力就是用Redisson組件。

解決分佈式鎖的成熟組件：zookeeper，yahoo發明了一系列分佈式應用後發明的java的分佈式事務協調器。

etcd，也是CoreOS（kubenetes集羣特定發行版）的核心組件，go語言實現。

https://github.com/etcd-io/etcd

etcd is a distributed reliable key-value store for the most critical data of a distributed system, with a focus on being:

• Simple: well-defined, user-facing API (gRPC)
• Secure: automatic TLS with optional client cert authentication
• Fast: benchmarked 10,000 writes/sec
• Reliable: properly distributed using Raft

etcd is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log.

Paxos，算法是萊斯利·蘭伯特（Leslie Lamport，就是 LaTeX 中的"La"，此人如今在微軟研究院）於1990年提出的一種基於消息傳遞的一致性算法。

 

關於分佈式重複提交問題的解決方案，參見上一篇博客的相關處理案例：

http://www.javashuo.com/article/p-gsgkyvvn-n.html