分布式系统

1、分布式技术概念

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

 2、分布式常见问题

1.分布式事务

 1.1 分布式事务基础

    事务的 特性：ACID:原子性、一致性、隔离性、持久性。

   1）CAP定理 

     C:一致性

     A：可用性

　 P：分区容错性,容忍网络中断。

   2）BASE理论 解决了CAP中没有网络延迟，用软状态和最终一致性，保证了延迟后的一致性。

      BA:基本可用

　  S:软状态

      E:最终一致性

 1.2 分布式事务解决方案 

  DTP事务模型

  DTP角色：

  AP:节点

  RM:资源管理器。数据库

  TM:事务管理器

  1. 2PC方案：基于XA协议的两阶段提交方案

   1)提交请求阶段

   2)提交执行阶段

   存在问题：

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）限流