分布式

架构的演进过程

• 业务简单、系统功能单一、访问量小的场景下
  • 单节点web应用架构
• 业务和系统功能相对复杂、访问量较大的场景下
  • Nginx负载的多web节点集群架构
• 业务复杂、系统庞大、访问量巨大的场景下
  • 分布式微服务架构

分布式架构特点

• 分布性
• 对等性
• 并发性
• 缺乏全局时钟
• 故障随时发发生

分布式架构存在问题

通信异常

通讯异常其实就是网络异常，网络系统本身是不可靠的，由于分布式系统需要通过网络进行数据传输，网络光纤，路由器等硬件难免出现问题。只要网络出现问题，也就会影响消息的发送与接受过程，因此数据消息的丢失或者延长就会变得非常普遍

网络分区

网络分区，俗称“脑裂现象”，是指集群中本来只有一个领导者，但由于通信异常，导致某一区域自行推举出另外一个领导，两个领导互为冲突

三态

通常情况下，方法执行的结果是一个明确的响应，要么成功，要么失败。而在分布式的场景下，会出现以一种除成功和失败以外的第三种状态—超时态。虽然绝大多数的情况下能够接受到成功或失败的响应，但网络一旦出现异常，就非常有可能超时，这时请求的发起方是无法确定请求是否处理成功的

节点故障

组成分布式集群的节点机器比较多，节点出现宕机或“僵死”的现象会经常发生

分布式协调理论

CAP理论

• 一致性Consistency
  • 在分布式系统中，一致性是数据在多个副本之间是否能够保证一致的特性
• 可用性Availability
  • 系统收到请求后，一定给出响应
• 分区容错性Partition tolerance
  • 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信

一个分布式系统不可能同时满足一致性、可用性、分区容错性这三个基本需求，最多只能够满足其中两项。由于分布式系统中P总是成立，所以架构师的精力往往集中在根据业务场景，寻求A和C的平衡

序号	被放弃	说明
1	P（满足AC）	将数据和服务都放在一个节点上，避免由于网路问题引起的负面影响，充分保证一致性和可用性。放弃P意味着放弃系统的扩展性
2	A（满足CP）	当节点故障或网络故障时，受影响的服务需要等待一段时间才能恢复响应，在此期间系统无法对外提供正常服务
3	C（满足AP）	系统无法保证数据的实时一致性，但是承诺数据最终会保持一致性。因此存在数据不一致的窗口期，窗口期时间的长短取决于系统设计

BASE理论

即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性

• 基本可用Basically Avaliable
  • 当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的“基本可用”；体现在“时间上的损失”和“功能上的损失”；如：部分用户双十一高峰期淘宝页面卡顿或降级处理
• 软状态Soft state
  • 允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性
• 最终一致性Eventually consistent
  • 所有的数据在经过一段时间的数据同步后，最终能够达到一个一致的状态；如：理财产品首页充值总金额短时不一致

分布式协调一致性的算法