分布式协议

分布式相关工具

raft

分布式一致性协议RAFT的动画演示：

    http://thesecretlivesofdata.com/raft/

glusterfs

分布式分布式文件系统glusterfs：

     http://navyaijm.blog.51cto.com/4647068/1258250

分布式自增Id

https://www.cnblogs.com/baiwa/p/5318432.html

Twitter分布式自增ID ： https://www.cnblogs.com/relucent/p/4955340.html

---

BT协议实现 

     http://m.blog.csdn.NET/article/details?id=51113358

Java torrent实现

    github:  https://github.com/mpetazzoni/ttorrent

浅析分布式系统

从开发运维到前段底层，请求到数据响应。把分布式系统的从上到下都分析了。

http://wetest.qq.com/lab/view/203.html?from=content_toutiao&hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

秒杀系统架构分析

构优化思路：

（1）尽量将请求拦截在系统上游（越上游越好）；

（2）读多写少的常用多使用缓存（缓存抗读压力）；

浏览器和APP：做限速

站点层：按照uid做限速，做页面缓存

服务层：按照业务做写请求队列控制流量，做数据缓存

数据层：闲庭信步

并且：结合业务做优化

参考链接

 Java系统调优

Java内存，性能调优，压测等一些列方式。

http://www.rowkey.me/blog/2016/11/02/java-profile/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

-------

分布式事物一致性 

实现策略：

两阶段提交：

   基于XA的两阶段提交策略（Tx、Tm）

   1、 准备，prepare 

   2、 提交，commit

 基于消息队列的两阶段提交策略（ 消息事务+最终一致性）

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下： 查看图片 1、A系统向消息中间件发送一条预备消息 2、消息中间件保存预备消息并返回成功 3、A执行本地事务 4、A发送提交消息给消息中间件 通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

• 步骤一出错，则整个事务失败，不会执行A的本地操作
• 步骤二出错，则整个事务失败，不会执行A的本地操作
• 步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息
• 步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务

基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作，其中B系统 的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到 B操作成功，这样就变相地实现了A与B的分布式事务。原理如下：  查看图片  虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

原文：https://gold.xitu.io/entry/577c6f220a2b5800573492be

http://www.cnblogs.com/chenjianxiang/p/6099023.html （分布式事物一致性）

https://segmentfault.com/a/1190000007484455 （nodejs分布式事物）

https://segmentfault.com/a/1190000004474144 （分布式事物介绍）

http://duanple.blog.163.com/blog/static/70971767201311810939564/ （两阶段提交论文）

http://www.roncoo.com/article/detail/124243（微服务分布式事物resolution）

 Java 平台中实现事务时要注意的常见错误

本地事物陷阱

spring  @Transactional 注释陷阱

spring  @Transactional 只读标志

REQUIRES_NEW 事务属性陷阱

事物回滚陷阱

http://www.ibm.com/developerworks/cn/java/j-ts1.html#ibm-pcon

分布式系统互斥性与幂等性问题

针对操作互斥性问题，常见的做法便是通过分布式锁来处理对共享资源的抢占。分布式锁的实现，很大程度借鉴了多线程和多进程环境中的互斥锁的实现原理。只要满足一些存储方面的基本条件，并且能够解决如网络断开等异常情况，那么就可以实现一个分布式锁。目前已经有基于Zookeeper和Redis等存储引擎的比较典型的分布式锁实现。但是由于单存储引擎的局限，我们开发了基于ZooKeeper和Tair的多引擎分布式锁Cerberus，它具有使用灵活方便等诸多优点，还提供了完善的一键降级方案。

http://tech.meituan.com/distributed-system-mutually-exclusive-idempotence-cerberus-gtis.html

分布式一致性原理与泛型

关于分布式系统的详细讲解，可参考《分布式系统原理与泛型》一书，里面详细介绍了分布式系统的一致性，包括锁、事物、二阶段提交、三阶段提交。以及数据同步、复制等。

----------------------------7章  一致性与复制

数据更新策略：

1、基于服务器的更新 ---推送

   服务器需要维护一个很大的用户订阅列表来保证及时推送给观察者。

2、基于客户端的轮训----拉取

      客户端需要轮训拉取数据，给客户端加重负担

3、结合两者的接口-------租期

一定时间内有服务器主动发起推送，租期到期后，续约或者客户端自己拉取数据。保证服务端只是盯着那些需要数据的用户。而放弃维护一些没必要的推送。