分布式的特征和注意事项

1、分布式性环境特点

       1) 分布性,       服务器的位置

       2) 并发性，   程序运行过程中，不同进程的并发操作的很常见的（比如同一个分布式系统中的多个节点同时访问共享资源）

       3) 无序性       进程之间的消息通信，可能会出现顺序不一致的情况

2、分布式环境面临的问题

      1) 网络通信    网络本性的不可靠性， 比如不可控的断电，电缆线的端口

      2) 网络分区（在elasticsearch等集群中也叫脑裂）  当网络发生异常导致分布式系统中部分节点的网络延迟不断加大，导致不能正常通信

      3) 三态   成功。失败和超时三种状态

      4) 分布式事务  在不同的服务器上也需要保证ACID（原子性、一致性、隔离性、和持久性） ，之前是所有的事务范围都在同一个jvm环境中

3、中心化和去中心化（分户式环境中常用思想就是，当集群中故障发生的时候，集群中马上进行自动选举,比如zookeeper和etcd ）

      1) 中心化：主备思想（冷备和热备：热备就是两个master或leader但是只有一个在工作的状态，冷备就是主挂掉后马上进行选举）

      2) 去中心化：没有主备之分，好处就是至少保证只是一部分不能正常工作

4、CAP和BASE理论

      1) CAP：三者不能同时成立，最多只能保证两者成立（即:CA、CP、AP），由于分区容错是我们不可控的，所以我们一般选择CA，

                     并且CAP理论仅使用于Nosql场景，不使用于数据库的系统

            C：（一致性Consistency）所有节点上的数据原子时刻保持一致

            A：（可用性Availability）    每个情况都能收到一个相应，不论是三态中的哪个状态

            P：（分区容错 Partition-tolerance） 

       2) BASE   

            基于CAP理论并且不适用于数据库（因为更新一些错误的数据而导致的数据紊乱，无论什么样的数据库高可用都是徒劳），

            XA事务虽然可以保证数据库在分布式环境下的ACID特性，但是会带来性能方面的应用。

            eBay尝试了一种完全不同的思想就是将ACID的事务要求进行放宽，于是提出了BASE理论（柔性事务）：

            Basically available ：   数据库采用分片模式，比如将100w用户数据分布在多个实例上，若有一个或多个实例不可用，至少保证大部分用户可用  

            Soft-state（软状态）：在基于client-server模式的系统中，server端是否有状态决定了系统是否具备良好的水平扩展、负载均衡故障恢复等特性。

                                                  Server端承诺会维护进行一小段时间内的client端的数据状态，过后server端将会丢弃这个状态恢复正常状态。

                                          比如：用户系统调用订单系统生成订单，这时订单服务状态为处理中，并调用支付系统中的支付功能。当支付完成后将返回状态

                                                   给订单系统，此时才将订单处理中的状态修改为支付成功，而不是直接使用强一致性事务。

            Eventually consistent：数据的最终一致性