一、分布式技术概念
1.负载均衡：
Nginx：高性能、高并发的web服务器；功能包括负载均衡、反向代理、静态内容缓存、访问控制；工作在应用层
LVS： Linux virtual server，基于集群技术和Linux操作系统实现一个高性能、高可用的服务器；工作在网络层
2.webserver：
Java：Tomcat，Apache，Jboss
Python：gunicorn、uwsgi、twisted、webpy、tornado
3.service：
SOA、微服务、spring boot，django
4.容器：
docker，kubernetes
5.cache：
memcache、redis等
6.协调中心：
zookeeper、etcd等
zookeeper使用了Paxos协议Paxos是强一致性，高可用的去中心化分布式。zookeeper的使用场景非常广泛，之后细讲。
7.rpc框架：
grpc、dubbo、brpc
dubbo是阿里开源的Java语言开发的高性能RPC框架，在阿里系的诸多架构中，都使用了dubbo + spring boot
8.消息队列：
kafka、rabbitMQ、rocketMQ、QSP
消息队列的应用场景：异步处理、应用解耦、流量削锋和消息通讯
9.实时数据平台：
storm、akka
10.离线数据平台：
hadoop、spark
PS: apark、akka、kafka都是scala语言写的，看到这个语言还是很牛逼的
11.dbproxy：
cobar也是阿里开源的，在阿里系中使用也非常广泛，是关系型数据库的sharding + replica 代理
12.db：
mysql、oracle、MongoDB、HBase
13.搜索：
elasticsearch、solr
14.日志：
rsyslog、elk、flume
二、分布式常见问题
1.分布式事务
1.1 分布式事务基础
事务的 特性：ACID:原子性、一致性、隔离性、持久性。
1）CAP定理:ZooKeeper保证的是CP
C:一致性
A：可用性
P：分区容错性,容忍网络中断。
2）BASE理论 解决了CAP中没有网络延迟，用软状态和最终一致性，保证了延迟后的一致性。
BA:基本可用
S:软状态
E:最终一致性
1.2 分布式事务解决方案
DTP事务模型
DTP角色：
AP:节点
RM:资源管理器。数据库
TM:事务管理器
1. 2PC方案：基于XA协议的两阶段提交方案
1)提交请求阶段
2)提交执行阶段
存在问题：
- 执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
- 协调者发生故障。参与者会一直阻塞下去，需要额外的备机进行容错。
2. 3PC:通过超时机制解决阻塞的问题。
1)询问阶段
2)准备阶段
3)提交阶段
存在问题：3PC的出现就是通过增加复杂度（性能也因此降低）来解决或优化2PC中的一部分问题。
3. TCC方案 Try:尝试执行业务，Confirm:确认执行业务，Cancel:取消执行业务。事务补偿。
第一阶段：主业务服务分别调用所有从业务服务的 try 操作，并在活动管理器中记录所有从业务服务。当所有从业务服务 try 成功或者某个从业务服务 try 失败时，进入第二阶段。
第二阶段：活动管理器根据第一阶段从业务服务的 try 结果来执行 confirm 或 cancel 操作。如果第一阶段所有从业务服务都 try 成功，则协作者调用所有从业务服务的 confirm 操 作，否则，调用所有从业务服务的 cancel 操作。
在第二阶段中，confirm 和 cancel 同样存在失败情况，所以需要对这两种情况做 异常处理 以保证数据一致性。
Confirm 失败：则回滚所有 confirm 操作并执行 cancel 操作。
Cancel 失败：从业务服务需要提供自动 cancel 机制，以保证 cancel 成功。
优点：TCC是对二阶段的一个改进，try阶段通过预留资源的方式避免了同步阻塞资源的情况。
缺点： 缺点还是比较明显的，业务侵入性太强，需要大量开发工作进行业务改造，给业务升级、运维都带来困难；在一些场景中，一些业务流程可能用TCC不太好定义及处理。
4. 基于消息的最终一致性方案
2.接口幂等性
1）对于每个请求必须有一个唯一的标识。
2）每次处理完请求之后，必须有一个记录标识这个请求处理过了。
3）每次接收请求需要进行判断之前是否处理过的逻辑处理。
例：用redis用orderId作为唯一键。
3.分布式锁
1)数据库：实现排他锁
2)redis分布式锁，redisson
3)zk分布式锁，curator
性能：redis > zk > 数据库
可靠性： zk > redis > 数据库。
4.分布式session
4.1
1)tomcat + redis
2)spring session + redis
4.2解决session一致性方案
1)session粘滞：配置简单，单点故障问题。
基于nginx的ip_hash策略来做负载均衡。原理：根据ip做hash计算，同一个ip的请求始终会定位到同一台tomcat。
2)session复制：不会丢失session，内存消耗大。
服务器session复制。原理：tomcat服务器创建session后，会通过组播方式把session发送到组播地址中的其他服务器上。
3)session共享(redis)：不会丢失session，适合大集群，系列化和反系列化消耗CPU性能。
5.分布式雪崩
1）熔断
2）隔离
3）限流