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