1. 首先说下要解决的内容
1. 1 分布式：分布式session会话、分布式锁、分布式存储、分布式事务
1.2 集群：集群管理、负载均衡、熔断
2. 消息中间件：rocketMQ、rabbitMQ、KAFKA、HIVE MQ、zookeeper、ACTIVE MQ
3.提供分布式事务的：rocketMQ/SEATA SAGA/JTA(spring Atomikos)/mongodb 2PC （Mongo4.2）
4.分布式锁：Redis/zookeeper
5. 分布式存储搭建：可以使用云提供的存储、无需要考虑自己扩展的问题，必须使用MongoDB的云，它既提供了分布式事务，当然也提供了我们分布式存储的功能，当然如果往大的分布式存储的方向考虑就是使用大数据的分布式存储HIVE 和 HBASE
6. 集群管理：zookeeper，SPRING EUREKA
7. RPC调用: DUBBO、NETTY 、RMI(JAVA)/SPRING FEIGN、
8、 负载: NGINX 、 RIBBON 、 ZOOKEEPER , 基本上在中间件里都具备这些负载， 所以重点应该关注负载的一些基础原理：
9. 熔断/容错机制：既然在分布式中的各个中间件都是标榜给分布式带来高可用，就无比在每个中间件学习他们的熔断或者容错机制！
1. IP HASH 定向负载
2. 轮询
3. 随机负载
4. 有些还可以自己自定义的负载均衡的算法，想怎么来就怎么来，自己决定什么时候访问什么服务，不一定要按照既定的默认的方案
二、session会话
1. IP HASH 定向访问，就是用户第一次登陆的session访问哪个服务，之后的服务根据IP 进行匹配，让这个用户之后的所有访问都会经过这个服务处理，不过这里有的风险就是可能会导致单点故障
2. 服务之间进行session复制，Tomcat等提供这种自动化配置，让所有Tomcat节点自动地通过session，不过这个有个很大的问题，如果访问量很大的时候，这个通过的过程就会消耗很多的内存和时间，得不偿失
3. session统一集中化管理，把session统一管理起来，这里可以随便用个存储中心，可以用数据库，但最好是要考虑这个session每次校验的速度，所以还是建议使用内存型的数据库，不是IO型的数据库，所以Redis应运而生！
三、分布式事务
这里就是分布式的重头戏了，虽然网上已经很多的分布式事务的文章了，大部分也都是在讲分布式事务的方案原理，但是这样也没错，因为所有方案必须都是有共同的理论基础
1. 指导思想还是：CAP 和 BASE 理论
2. 解决方案：2PC、3PC、TCC、消息中间件的最终一致性解决方案
3. 实现解决方案的各种方案：TX-LCN/ ROCKET MQ/ SEATA SAGA /JTA(spring Atomikos)/mongodb 2PC
四、RPC 远程调用
1. 让程序员忽略网络调用细节，直接像本地一样调用接口
2. dubbo不只是只有zookeeper作为注册中心，zookeeper只是dubbo官方推荐的注册中心，其他还有redis/simple/multicast/default（dubbo内存自己做的）
3. dubbo大部分是在Spring场景下使用的，所以这个时候你可以抉择使用Spring dubbo或者Spring 自己的rpc 框架ribbon
4. 既然在分布式中的各个中间件都是标榜给分布式带来高可用，就无比在每个中间件学习他们的熔断或者容错机制！
为什么分布式事务相关的教程在网上没有那么多活跃的文章介绍，这个也主要是看业务场景把，其实可能99% 的业务场景和公司可能都不具备这样的业务场景吧，顶多要求在银行转账的这样的案例中要求非常强的一致性之外，其他业务几乎可能不用那么关注那么强的一致性问题，如果真的出现了分布式一致性的问题，这出现的概率和我们平常的一些BUG 也差不多，也可以通过日志分析和最后人工干预进行修补即可，还用不着大费周章的自己搞一套分布式事务算法实现流程，这样请一个高级的工程师或者就为了这个场景去开发，开发周期长，难度大，反而成本上还不划算。
所以99%的人可能都无法接触到分布式事务场景业务，虽然有时候也面试了一些高级的后台岗位，也比较少有机会去接触到一些高级的岗位
来源：oschina
链接：https://my.oschina.net/u/3697586/blog/4303043