分布式重复提交问题架构设计思路

数据列加惟一索引，重复数据保存失败。

有多余两台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