分布式技术原理与实战 学习第一篇

分布式系统特点

核心是可扩展性

通过对服务、存储的扩展，来提高系统的处理能力

通过对多台服务器协同工作，来完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务

单点故障

是指在系统中某个组件一旦失效，这会让整个系统无法工作，而不出现单点故障，单点不影响整体
就是分布式系统的设计目标之一

无状态

是因为无状态的服务才能满足部分机器宕机不影响全部，可以随时进行扩展的需求

讲解CAP理论

== 证明： ==

• 反证法
  
  
  首先构造一个单机系统，如上图，Client A可以发送指令到Server并且设置更新X的，Client 1可以从server读取该值，在单点情况下，即没有网络分区的情况下，通过简单的事务机制，可以保证 Client 1 读到的始终是最新值，不存在一致性的问题。
  

  我们在系统中增加一组节点，因为允许分区容错，Write操作可能在Server1上成功，在Server2上失败，这时候对于Client1和Client2，就会读取到不一致的值，出现不一致的情况。如果要保持 X 值的一致性，Write 操作必须同时失败， 也就是降低系统的可用性。

  可以看到，在分布式系统中，无法同时满足 CAP 定律中的“一致性”、“可用性”和“分区容错性”三者。

  在该证明中，对CAP的定义进行了更明确的声明：Consistency，一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的，写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序；Availability，对任何非失败节点都应该在有限时间内给出请求的回应（请求的可终止性）；PartitionTolerance，允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。

  CAP理论的应用CAP理论提醒我们，在架构设计中，不要把精力浪费在如何设计能满足三者的完美分布式系统上，而要合理进行取舍，CAP理论类似数学上的不可能三角，只能三者选其二，不能全部获得。…

  不同业务对于一致性的要求是不同的。举个例来讲，在微博上发表评论和点赞，用户对不一致是不敏感的，可以容忍相对较长时间的不一致，只要做好本地的交互，并不会影响用户体验；而我们在电商购物时，产品价格数据则是要求强一致性的，如果商家更改价格不能实时生效，则会对交易成功率有非常大的影响。

  需要注意的是，CAP理论中是忽略网络延迟的，也就是当事务提交时，节点间的数据复制一定是需要花费时间的。即使是同一个机房，从节点A复制到节点B，由于现实中网络不是实时的，所以总会有一定的时间不一致。

CP 和 AP 架构的取舍

在通常的分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（Replica），网络分区是既成的现实，于是只能在可用性和一致性两者间做出选择。CAP理论关注的是在绝对情况下，在工程上，可用性和一致性并不是完全对立的，我们关注的往往是如何在保持相对一致性的前提下，提高系统的可用性。

业务上对一致性的要求会直接反映在系统设计中，典型的就是 CP 和 AP 结构。

• CP架构：对于CP来说，放弃可用性，追求一致性和分区容错性。我们熟悉的ZooKeeper，就是采用了CP一致性，ZooKeeper是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和一致性问题。其核心算法是
  Zab，所有设计都是为了一致性。在 CAP 模型中，ZooKeeper 是 CP，这意味着面对网络分区时，为了保持一致性，它是不可用的。
• AP 架构：对于 AP 来说，放弃强一致性，追求分区容错性和可用性。

和ZooKeeper相对的是Eureka，Eureka是SpringCloud微服务技术栈中的服务发现组件，Eureka的各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，只要有一台 Eureka 还在，就能保证注册服务可用，只不过查到的信息可能不是最新的版本，不保证一致性。

总结：CP和AP的选择要根据使用场景来决定的。对于分布式服务注册发现的组件，服务端和客户端可以选择长连接，对于一致性要求不必那么高，AP就很合适。对于类似库存、交易等分布式锁场景，要求数据必须准确，就要用CP了