分布式协调服务-Zookeeper
分布式的一些概念
1、分布式环境的特点
1.1、分布式的概念：一个系统分成多个部分，这些部分分布在不同的节点上同时完成一个任务，这就是分布式。分布式主要提供整个系统的吞吐量和程序的性能,可控性，还有扩展性，还有可用性。
1.2、特点：
①、分布性：
整个系统可能部署在分布在不同国家，不同地域的，不同机房的，不同的服务器导致分布性。不是放到一台机器上的，而是部署到多个服务器上的系统。导致分布性。
②、并发性：
程序运行中并发性操作很常见。比如同一个分布式系统中的多个节点同时访问一个共享资源(数据库，分布式存储的服务器)。
比如是多个节点操作的是同一个的共享资源-比如操作库存。
一个节点去发生减的事务的操作，另外一个节点也继续发生减的事务的操作，这时就肯定会出现问题
③、无序性：
既然用到了分布式，必须用到远程的通信，因为是不同的子系统部署到不同的节点的机子上，子系统和子系统之间要通信，通信就涉及到顺序问题。比如：网络延迟，超时，都会导致顺序是无序性，导致在按指定的时间的内到达服务器。线程虽然无序但是可以通过队列线程 池来控制顺序。
2、分布式环境面临的问题
①、各个服务节点之间的通信问题：
网络延迟，网络本身的不可靠因素、断网，因此涉及一些网络
的通信的问题。每一个分布式项目都必须面临的问题。这个问题解决不了。但是可以克服。
②、网络分区(脑裂)
当网络发生异常的情况的时候，导致分布式系统中部分节点之间的网络延迟不断变大。最终导致组成分布式系统所有节点中只有部分节点能够正常通信，分布式系统出现小集群问题。
例如：redis集群导致脑裂：主从切换问题（redis容灾)
这个master能够正常通信的只是网路延迟增大， 导致网络阻塞从而实现。发过去的心跳不能及时的回复。这时就会执行主从切换。就会认为master挂掉了。由于三台导致网络延迟的通信。然后左边两个是正常的通信的认为不是延迟通信的，然后就挂在了master的下边。而又边三台发现master的网络延迟越来越大，发现没回应了。这三台从节点就会选举出一个主节点。这就是脑裂。
脑裂这个问题不是容易遇到的。是有机率出现的。
解决方案：
①、重试超时机制。重试3次不能连上，这边就会给它做个降级，还不行的话就会做master的降级，返回一个结果出来就可以了。然后靠人去维护，在重新去请求连接。这时就不会认为master挂掉了，这时就不会出现网络分区。
②、拒绝提供服务：两个之间去维护一个状态机，如果发现master挂掉了，就不会去往master发请求，把三个延迟的子节点就拒绝请求服务连接，这时就不会选举了。
3、分布式事务问题：
分布式：涉及到不同的节点机
事务：涉及到数据库的ACID问题，和数据库三范式不一样。
原子性，一致性，隔离性，持久性。=》事务特征
A、原子性：整个事务操作过程中，所有操作要么全部成功，要么全部失败。
C、一致性：整个数据操作的前后每一个时刻上的所有的数据都是保持一致的。
D:持久性：整个操作完以后，事务一旦提交成功，所有的数据不可能再改，不能再回滚了。
I：隔离性：事务和事务之间无感知的，事务和事务之间操作是完全隔离的。一个事务得执行不会影响另一个事务。
上面的四个特性再在一个节点上是完全可以保证的。本来关系型数据库是没有问题的。
分布式事务：所有的操作不在一台的机器上，而在不同得机器上。
由于在不同得机器上，并且顺序也是不一样得，网络得处理也是不一样的，这就是分布式得事务问题。
4、分布式理论：
4.1、CAP：Consistency一致性 ，Availability可用性。
Partition Tolerance 分区容错性：就涉及到了刚才得脑裂得问题[脑裂问题],本来分区出现的错误去提高容错性这也是一方面。所以说在做分布式得时候需要考虑这个两个理论的问题。CAP的提出在一个分布式得系统中不可能同时满足上面三种的。要么满足一致性，要么满足可用性。
4.2、分区容错是每一个分布式系统中都会遇到，因为这是涉及到网络得问题。所以说要么取PA或者PC。，可以取AC，那么网络中得问题就是最大得问题了。
4.3、一致性：包括强一致性和弱一致性
强一致性：整个操作过程中，每个副本中的数据实时一致的，同一个时刻，每一个节点中的数据都是一致的。实时同步的。
弱一致性：就是最终一致性，在一定范围内得允许有一小个时间段内各个节点上的数据部分不一致，但是最后得到得结果是一致的。
4.4、Availability:可用性,不管服务器宕机几台，不会影响系统得正常得运行的。对于用户的每一个请求在有限时间都会响应正常的结果-容灾。
4.5、分区容错、Partition Tolerance[脑裂问题]：
当分布式系统在遇到任何网络分区故障的时候，仍然需要保证对外提供可以提供一致性，可用性的服务，这就是分区容错，但是网络出现故障时不行的。可以把组成 分布式系统得每一个节点加入和退出都可以看成是一个网络得分区。即使发现了脑裂得问题，如果没有做容错得话，数据就会肯定不一致。数据有可能出现重复得，但是如果加入了这个P得话，仍然需要保证对外提供可以提供一致性，可用性的服务，即使出现了分区问题，我们这边的数据还会一致的。
总结：在一个分布式得理论中不可能同时满足上面得三个点,只能满足两个。CAP理论就是一个矛盾体。根据业务不同确定技术得选型。只能满足两个，这个CAP理论不适用关系型数据库，只针对于nosql得数据库。p在分布式系统中必须存在得。分区容错在分布式系统中是必须存在的。
5、Base理论:
5.1、基于在cap理论中是无法办证强一致性的，但是每个业务根据自身的特点采用适当的方式去保证达到系统一致性状态，不需要每个时刻都需要保持一致的这个就是base理论提出的思想。
5.2、basecially Avaliable:基本可用，能够正常提供得业务功能就可以了。指分布式系统在出现故障的时候允许损失部分的可用性保证核心可用就可以了，有点像服务降级。保证核心业务(根据业务断定得)就行了，有一些基本功能的损失。
5.3、soft-State(柔性事务/软状态）：系统存在中间状态。并且中间状态不会影响整体得可用性即允许系统在不同节点的副本，同步的时候存在延时这就是软状态。
5.3.1、比如在设计支付系统：我这里下了订单，通过这个订单去支付，发现这个订单处于处理中。最好的结果我不是等待它给我返回结果，而是我一支付，它这边给我返回处理中。但是我这里有一个中间得状态-支付中的状态。当那边处理完成之后这时发条消息过来把支付中改为支付完成。处理中改为处理完成。这就是最好得结果。在支付中不会影响可用性，不会导致系统不可用，因为及时的给你返回消息了，其他人下订单也可以。这就是一个软状态，和柔性事务，可以看成一个事务，不是一个很强烈的一种事务。
5.3.2、例如抢购：抢完之后，并没有提示你有没有抢到，会等一会告诉你有没有抢到。其实等待的那一会在做异步的处理，有的人一刷新就提示抢到了然后可以去下订单，没有抢到的人下不了订单，这就是用异步得方式在做处理。就是用队列得方式来对消息进行消费然后逐步的与数据库同步，这样既可以限流又可以减轻抢购在整个服务器之间的压力。
Envetually Consistency:最终一致性，允许一小段的时间得状态不一致，不需要保持实时一致，最终一致就可以了。类似于弱一致性。
base理论就是由cap理论演变而来得。
6、中心化，去中心化：
6.1、中心化，去中心化：在区块链中用得很多，中心化，去中心化在zookeeper/etcd(服务发现，协调)的组件里面都可以去做
6.2、中心化得思想：分布式集群中得节点机器按照角色分工。每一个节点机他都会有自己得角色。
例如：zk集群就是一个中间化，因为里面有leader，有flower：跟随者，有obsever:监控得意思，这就涉及 到了不同得角色得分工。
去中心化：没有任何得阶梯关系。
革命尚未成功，继续努力！！！！
如果觉的哪里不好的话，请各位大佬指出缺点，互相学习。