分布式基础知识

分布式环境的特点

分布性

并发性

在程序运行的过程中，并发性操作是很常见的。

• 比如：在一个分布式的系统中，多个节点同时访问一个共享资源。
• 数据库
• 分布式存储

无序性

进程之间的消息通信，会出现顺序不一致的问题。

• 比如：两个节点先后发起了请求，有可能后发起的请求先响应。

分布式环境下面临的问题

网络通信

网络本身的不可靠性，可能会涉及到一些网络通信问题。

网络分区（脑裂）

当网络发生异常导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式架构的所有节点，只有部分节点能够正常通信。
当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事物处理，这就对分布式一致性提出了非常大的挑战

三态

• 成功
• 失败
• 超时

分布式事务 //TODO

ACID

• 原子性（Atomicity）：
• 一致性（Consistency）：
• 隔离性（Isolation）：
• 持久性（Durability）：

中心化和去中心化 //TODO

冷备

热备

分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。
最典型的是： zookeeper / etcd

经典的CAP理论

• 一致性（Consistency）：集群中所有节点的数据，时刻保持一致。
• 可用性（Availability）：每一个请求，都一定能够收到一个响应，无论响应成功还是失败。当集群中的一部分节点故障后，集群整体是否还能响应客户端的请求（高可用）。
• 分区容错性（Partition-tolerance）：表示系统出现（网络分区）脑裂以后，可能导致某些server与集群中的其他机器失去联系。分区相当于对通信的时限要求，如果系统不能在时限内达成数据一致性，就意味着发生了分区的问题，必须就当前操作在C和A之间做出选择。

任何一个分布式系统，都不能够同时满足一致性，可用性，分区容错性。
各有取舍，在分布式系统根据需求可供我们选择的方案：CP、AP

• CP：选择了数据一致性和分区容错性，放弃了可用性。一旦发生网络分区，受影响的服务就需要等待数据一致，因此在等待期间无法对外继续提供服务。
• AP：选择了可用性和分区容错性，放弃了数据（强）一致性。
• CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择。

适用场景

CAP理论仅适用于原子读写的NoSql（redis…）场景，不适用于数据库系统（mysql、oracle…）

经典的BASE理论

基于CAP理论，CAP理论不适用于数据库事务（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的数据库高可用方案都是
徒劳） ，虽然XA事务可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响。

• 基本可用（Basically available）：在分布式系统出现不可预知的故障时，损失系统部分可用性。
  1、响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒。
  2、系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
  3、数据库采用分片模式，把100万用户数据分布在5个实例上，其中一个实例故障了，仍然可以保证80%的可用用户数据。
• 软状态（Soft-state）：什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性（Eventually-consistent）：最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。