分布式

1 基础介绍

CAP 原则又称 CAP 定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这 3 个基本需求，最多只能同时满足其中的 2 个。

为什么上述问题不可兼得？

首先对于分布式系统，分区是必然存在的，所谓分区指的是分布式系统可能出现的字区域网络不通，成为孤立区域的的情况。

那么分区容错性（P）就必须要满足，因为如果要牺牲分区容错性，就得把服务和资源放到一个机器，或者一个“同生共死”的集群，那就违背了分布式的初衷。

1.1 CA without P

理论上放弃 P（分区容错性），则 C（强一致性）和 A（可用性）是可以保证的。实际上分区是不可避免的，严格上 CA 指的是允许分区后各子系统依然保持 CA。

CA 模型的常见应用：

• 集群数据库
• xFS 文件系统

1.2 CP without A

放弃 A（可用），相当于每个请求都需要在 Server 之间强一致，而 P（分区）会导致同步时间无限延长，如此 CP 也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

CP 模型的常见应用：

• 分布式数据库
• 分布式锁

1.3 AP wihtout C

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的 NoSQL 都属于此类。

AP 模型常见应用：

• Web 缓存
• DNS

2 BASE 理论

BASE（Basically Available、Soft state、Eventual consistency）是基于 CAP 理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。

BASE 的主要含义：

• Basically Available（基本可用）

什么是基本可用呢？假设系统出现了不可预知的故障，但还是能用，只是相比较正常的系统而言，可能会有响应时间上的损失，或者功能上的降级。

• Soft State（软状态）

什么是硬状态呢？要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态也称为弱状态，相比较硬状态而言，允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

• Eventually Consistent（最终一致性）

上面说了软状态，但是不应该一直都是软状态。在一定时间后，应该到达一个最终的状态，保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间取决于网络延时、系统负载、数据复制方案设计等等因素。

3 业务答疑

3.1 场景描述

在嵌入式路由器设备上，实现图片分类、人脸识别等能力。由于路由器包含一主多从，因此可以使用分布式的能力，分散单一设备的推理压力。

业务采用的是中心化策略的分布式方案，主路由的能力最为复杂，他能进行推理、负责任务的分配以及状态的维护，从路由则仅仅只通过主路由分配的任务，获取数据进行推理。

当子路由启动时，会主动收集自身资源并上报给主路由，主路由根据子路由的资源（CPU、内存等），进行合理的任务分配。

上述业务使用到了分布式的资源进行任务，但他是一个中心化的策略。这种情况，能称它为分布式系统吗？

可以，这种情况仍然可以被称为分布式系统。分布式系统的核心特征是多个计算节点通过网络连接并协同工作，以完成共同的任务或提供服务。虽然该业务中存在一个中心化的主路由器来协调任务分配，但它仍然利用了多个子路由器的分布式资源来执行任务。

在这种情况下，系统既具有分布式系统的特征（多个节点协同工作），也具有一定程度的中心化控制（主路由器负责任务分配）。这种混合模式在实际应用中很常见，因为它可以在一定程度上平衡系统的灵活性和管理的复杂性。

因此，即使存在中心化策略，只要系统利用了分布式资源来完成任务，就可以被称为分布式系统。

3.2 中心化策略的分布式系统

这种系统虽然利用了分布式资源，但存在一个中心节点负责协调和决策。提供的业务场景就属于这种类型，主路由器负责任务分配，子路由器执行任务。

应用场景示例：

1. 工业自动化：在工业自动化系统中，通常有一个中央控制器负责监控和管理多个分布式设备或机器人。例如，在汽车制造工厂中，中央控制器根据生产线上的任务需求和设备状态，分配不同的任务给各个机器人，以实现高效的生产流程。
2. 智能交通系统：在城市交通管理中，中央控制系统根据交通流量和道路状况，实时调整各个路口的信号灯，以优化交通流量和减少拥堵。
3. 数据中心管理：在大型数据中心，中央管理系统负责监控服务器的负载和资源使用情况，动态分配任务给不同的服务器，以确保系统的高效运行。

3.2.1 Web服务分布式系统

这种系统通常用于构建可扩展的Web应用程序和服务，强调服务的分布和协同工作，以满足高并发和大数据处理的需求。

应用场景示例：

1. 大型电商网站：像亚马逊、淘宝这样的大型电商网站，需要处理成千上万的并发用户请求。通过分布式架构，将前端Web服务器、后端业务逻辑服务器和数据库服务器分别部署在不同的机器上，实现负载均衡和高可用性。
2. 云计算平台：如阿里云、AWS等云计算服务提供商，通过分布式系统为用户提供各种计算资源和服务。用户可以根据需求动态获取和释放资源，实现弹性扩展。
3. 社交媒体平台：像微博、Facebook这样的社交媒体平台，需要处理海量的用户数据和实时的消息推送。通过分布式系统，可以将用户数据分散存储在多个服务器上，并通过分布式缓存和消息队列等技术提高系统的响应速度和可靠性。

3.3 总结

• 中心化策略的分布式系统适用于需要集中控制和资源分配的场景，如工业自动化、智能交通系统等。这种架构在一定程度上简化了系统的管理和协调，但存在单点故障的风险。
• Web服务分布式系统适用于需要高扩展性和高可用性的Web应用程序，如大型电商网站、云计算平台等。这种架构通过分布式的服务器和资源管理，提高了系统的性能和可靠性，但需要处理复杂的分布式事务和数据一致性问题。

在实际应用中，选择哪种架构取决于具体的业务需求、系统规模和技术能力。

3.4 业务分布式特性分解

记录对分布式的疑惑，业务场景中遇到的问题。

3.5 一致性疑问

业务场景中，不涉及数据的共享，所有的任务下发都通过主路由控制，为什么仍然存在一致性问题？

解释：

在分布式系统中，一致性是一个多维度的概念，它包括数据一致性，也涵盖了系统行为和状态一致性。

可详细理解为：

1. 数据一致性

   • 强数据一致性：数据更新后，所有节点的数据立即保持一致，任何读取操作都能获取最新的数据值
   • 弱数据一致性：允许数据在更新一段时间内，数据存在不一致，但经过一段时间后会达到一致
   • 最终数据一致性：在没有新的更新情况下，经过足够长时间，所有节点上数据最终会达到一致状态

2. 行为一致性：系统中的节点，在收到相同的输入或请求时，应该表现出相同的行为，产生相同的结果

3. 状态一致性：每个节点在某个时间点的状态应该是一致的，即程序的状态（内部状态、数据状态）都任务运行的逻辑对应

举例：

1. 数据传播延迟导致的状态不一致

   当网络延迟时，主设备下发的任务没有被从设备及时收到，导致从设备空闲等待或执行旧任务的情况。导致主从设备间的状态不一致。

2. 节点故障导致任务丢失

   倘若主路由故障，下发的任务未被成功记录；或从路由故障，下发任务未能成功执行，导致状态不一致等。

解决方案：

1. 消息队列

   使用了 Mosquitto 轻量级的消息队列，基于 MQTT 协议。该开源软件提供了发布/订阅的消息传递模式，允许客户端通过订阅特定主题来接收消息。

   同时 Mosq 支持三种不同的服务质量（Qos）级别，能保证消息的可靠传递。

   • Qos0：最多发一次消息，接收者不会发送回应，发送者也不会重发消息。消息可能会丢失。

   • Qos1：最少发一次消息，但可能会重复。发送者会收到 PUBACK 确认消息。

   • Qos2：精确发送一次消息，消息不会丢失也不会重复。发送者会收到 PUBREC、PUBREL 和 PUBCOMP 确认消息。

     消息确认机制：在 QoS 1 和 QoS 2 级别下，发送者会等待接收者的确认消息（PUBACK、PUBREC 等），以确保消息被成功接收。如果未收到确认消息，发送者会重发消息。

     消息存储和重发：Mosquitto 会将未确认的消息存储在内存或磁盘中，直到收到确认消息。如果客户端断开连接，Mosquitto 会保留这些消息，并在客户端重新连接时重新发送。

     客户端状态管理：Mosquitto 会维护客户端的连接状态和订阅信息，确保在客户端重新连接时能够继续未完成的消息传输。

2. 心跳机制

   其中 Mosq 内置了心跳机制，能检测客户端是否与服务器断开链接。为了更好的健壮性，我们选择结合使用自定义 Topic 实现状态心跳：包含任务ID、任务进度、CPU使用率、内存使用率等。

   简单的心跳机制能保证客户端的长时间在线，状态心跳保证同步任务状态，同时任务完成后也会发送一次状态信息，方便下次任务的分配。

3.6 可用性（Availability）

任何时刻对于分布式系统节点的访问都返回成功的结果，而不会是超时或者失败。

可用性强调的是一定能读到数据，无论数据读取是新旧不影响，但一定要访问成功。

主要针对用户对系统的访问和使用体验，关注系统整体的对外服务

3.7 分区容错性（P）

在分布式系统中，网络分区通常是不可避免地。分区指将数据或系统资源按照一定的规则划分为多个独立的部分，每个部分称为一个分区。

在分布式系统中，分区通常是指将数据分布在不同的节点上，以实现负载均衡、提高性能和可扩展性等目标。

分区容错性（Partition Tolerance）是指分布式系统在遇到网络分区故障时，仍然能够继续运行并提供服务的能力。

主要针对系统内部的节点间通信和协作，节点和其他节点失去连接后仍然能处理本地的任务，也包含对外的服务

3.8 对业务的解释

CAP 定理是一种理想化的模型，用于描述系统在极端情况下的设计权衡。但不是对实际系统进行绝对分类的工具，我们在CAP的三个特性中寻求平衡和折中，而不是严格的只满足其中两个。

上述的系统中，

1. 数据一致性保障

   主路由对数据集中管理和分配，有助于正常运行时保持数据的一致性。状态和行为一致性从上面的案例中得到保证。

2. 可用性部分满足

   系统存在单点故障的问题

3. 分区容错性有限支持

   有一定容错性，出现故障时，从设备仍然能继续执行已分配的任务。也能利用心跳等机制来同步状态，重新分配任务。

它可能不完全符合CAP定理中对某一特定组合（如CA或AP）的严格定义。

在实际应用中，这样的系统设计是常见且合理的，因为它能够在不同的故障场景下提供一定程度的服务保障。重要的是要认识到，分布式系统的设计往往需要在多个目标之间进行权衡，而不是严格地遵循某一理论模型。