分布式系统概念和设计

复制

• 分布式系统中，复制是提高可用性和容错的关键技术。
• 数据复制的技术，在多个计算机中维护数据的副本。
• 复制是一种增强服务的技术。进行复制的动机包括改善服务性能，提高可用性，增强容错能力。
  • 增强性能：客户和服务器常用的增强性能的手段是增加缓存。
  • 提高可用性：用户要求服务是高度可用的，在合理的响应时间内获得服务的比例尽可能接近100%
  • 除了因为悲观并发控制访问造成的延迟外：
    • 服务器故障
    • 网络分区和断接操作，通信断接通常是不可预计的，也可能是用户移动性的副作用。
  • 容错性:高可用性数据并不一定是绝对准确的数据
    • 可能会过时的数据，或者两个网络分区不同地方的用户用户做了冲突操作
• 数据复制最大的需求是数据一致性，一致性强度会有所不同在不同的场景中。
• 对应用正确性的破坏是不可接受的。

分布式系统中，复制是提高可用性和容错的关键技术之一。复制可以将数据和计算任务复制到多个节点上，从而提高系统的可用性和容错性，避免单点故障和数据丢失等问题。

具体来说，复制可以通过以下方式提高分布式系统的可用性和容错性：

1. 数据复制：将数据复制到多个节点上，可以保证即使某个节点发生故障，数据仍然可以在其他节点上访问。数据复制可以使用主从复制、多主复制或者分区复制等技术来实现。
2. 任务复制：将计算任务复制到多个节点上，可以保证即使某个节点发生故障，任务仍然可以在其他节点上执行。任务复制可以使用主从复制、多主复制或者分区复制等技术来实现。
3. 故障转移：当某个节点发生故障时，可以将其上的数据和任务转移到其他节点上，从而保证系统的可用性和容错性。故障转移可以使用主从复制、多主复制或者分区复制等技术来实现。

总之，复制是提高分布式系统可用性和容错性的关键技术之一。通过数据复制、任务复制和故障转移等技术，可以保证系统的高可用性和容错性，避免单点故障和数据丢失等问题。

系统模型和组通信

系统模型

1. 主从复制模型：主从复制模型中，有一个主节点和多个从节点。主节点负责接收客户端请求并处理数据更新，然后将数据更新发送给从节点。从节点只能读取数据，不能修改数据。主从复制模型可以提高系统的可用性和容错性，但是可能会出现数据一致性问题。
2. 多主复制模型：多主复制模型中，有多个主节点和多个从节点。每个主节点都可以接收客户端请求并处理数据更新，然后将数据更新发送给其他主节点和从节点。从节点只能读取数据，不能修改数据。多主复制模型可以提高系统的可用性和容错性，同时也可以提高系统的吞吐量和性能。

在主从复制模型和多主复制模型中，都需要解决数据一致性问题。常见的数据一致性协议包括：

1. 一致性哈希协议：一致性哈希协议可以将数据分散到多个节点上，从而提高系统的可用性和容错性。一致性哈希协议可以解决节点故障和节点加入或退出时的数据迁移问题。
2. Paxos 协议：Paxos 协议可以保证分布式系统中的数据一致性。Paxos 协议通过多个阶段来达成一致性，包括提议阶段、承诺阶段和提交阶段。
3. Raft 协议：Raft 协议是一种分布式一致性协议，可以保证分布式系统中的数据一致性。Raft 协议通过 leader 选举、日志复制和安全性等机制来实现数据一致性。

组通信

• 进程组是组播消息的目标。
• 如果进程通过接收和处理相同的组播信息来合作完成目标，那么组也是非常重要的。
• 当组成员接收一个或多个共同的信息流，特别是消息需要进程做出特别动作的事件信息时，组更加重要

组成员关系服务的作用

• 为组成员变更提供接口

  • 创建和撤销进程组，添加和删除组成员

• 实现故障检测器

  • 检测组中成员的状态是否可用，不可用则删除

• 通告组成员关系变更

  • 当一个进程被加入或者删除，通知组成员变更消息

• 扩展组地址

  • 当一个进程组播消息时，提供的组标识而不是组中进程的列表。为了传送，组成员关系服务将标识扩展为当前组成员标识。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aIpVU3aP-1686204254489)(./assets/1685944543116-image.png)]

视图传送

• 当组成员发生变更，一个成员将新的成员关系告知给应用，我们称这个成员传送了视图。

容错服务

线性化能力和顺序一致性

• 最严格正确的系统是可以线性化的
• 一个复制的共享对象服务被认为是可线性化的，如果对于任何执行，存在某一个全体客户操作的序列。
  • 操作的交叉执行序列符合对象的正确副本所遵循的规约
  • 操作之间的交叉执行序列和实际运行中的序列一致

在分布式系统中，线性化容错能力是指系统能够在发生故障或异常时，仍能够保持线性化的特性。线性化是指系统的操作结果与操作顺序无关，即系统能够保证所有操作按照一定的顺序执行，且所有节点上的操作结果都相同。为了提高分布式系统的线性化容错能力，可以采取以下几种设计：

1. 一致性协议：在分布式系统中，一致性协议是保证线性化容错能力的关键。可以使用 Paxos、Raft 等一致性协议，保证所有节点上的操作按照一定的顺序执行，且所有节点上的操作结果都相同。在发生故障或异常时，可以使用一致性协议进行数据恢复和故障转移，以保证系统的线性化特性。
2. 副本机制：在分布式系统中，副本机制是提高线性化容错能力的常用手段。可以使用多副本机制，将数据备份到多个节点上，以保证数据的可用性和可靠性。在发生故障或异常时，可以使用副本机制进行数据恢复和故障转移，以保证系统的线性化特性。
3. 快速故障检测和恢复：在分布式系统中，快速故障检测和恢复是提高线性化容错能力的关键。可以使用心跳检测机制，定期检测节点的健康状态，当节点发生故障或异常时，可以快速检测到并进行恢复。同时，可以使用自动故障转移机制，将故障节点上的任务转移到其他节点上，以保证系统的线性化特性。
4. 异常处理和日志记录：在分布式系统中，异常处理和日志记录是提高线性化容错能力的重要手段。可以使用异常处理机制，捕获和处理系统中发生的异常，以避免系统崩溃或数据损坏。同时，可以使用日志记录机制，记录系统中发生的操作和事件，以便在发生故障或异常时进行排查和分析。

总之，在分布式系统设计中，为了提高线性化容错能力，可以采取一致性协议、副本机制、快速故障检测和恢复、异常处理和日志记录等设计。需要根据实际需求和技术限制选择合适的设计。

被动（主备份）复制

主备份复制模型，任何时候都有一个主副本管理器和一个或多个备份管理器。

该模型的本质是，前端只和主管理器通信以获得服务。

主副本管理器执行操作并将更新操作的拷贝发送备份副本管理器。

如果某个主备份管理器故障，其他备份管理器则晋身为主备份管理器。

• 请求：前端将请求发送给主管理器，请求中包含唯一标识
• 协调：主管理器接收到请求的次序原子性执行每个请求，检查请求的标识，如果请求的标识已经执行，那么简单的应答
• 执行：主管理执行请求并存储应答
• 协定：如果请求是更新操作，那么主管理向每个备份管理器发送更新后的状态，应答和唯一标识。备份管理器返回一个确认。
• 响应：主管理器将应答发送给前端，前端发送给客户。

在主管理器正确运行，由于主管理器在共享对象上将所有操作顺序化，该系统显然是线性化的。

当主管理器出现故障，如果某个备份变为新的主管理器并且新的系统配置从故障节点正确接管的话，系统仍然是可线性化的。

主动复制

主动复制模型是一种常见的分布式系统设计模型，它通过多个节点同时处理请求和备份数据来提高系统的可用性和可靠性。在主动复制模型中，每个节点都可以接收请求并处理，同时也可以备份数据，从而实现数据的冗余和容错。

主动复制模型的执行过程如下：

1. 系统启动：在系统启动时，所有节点都会启动，并建立连接。每个节点都可以接收请求并处理，同时也可以备份数据。
2. 请求处理：当有请求到达时，所有节点都可以处理请求，并将处理结果返回给请求方。此时，每个节点都可以备份数据，以保证数据的可靠性和可用性。
3. 数据备份：每个节点都可以定期将数据备份到其他节点上，以保证数据的冗余和容错。同时，每个节点也可以接收其他节点的备份数据，以保证数据的一致性和可靠性。
4. 节点故障：当某个节点发生故障或异常时，其他节点可以继续处理请求和备份数据。同时，其他节点也可以检测到故障节点的状态，并将故障节点的任务转移到其他节点上，以保证系统的连续性和可用性。
5. 故障恢复：当故障节点恢复正常工作时，其他节点会将故障节点的数据同步到故障节点上，并重新建立连接。此时，故障节点可以继续处理请求和备份数据，以保证系统的连续性和可靠性。

总之，在主动复制模型中，每个节点都可以接收请求并处理，同时也可以备份数据。当某个节点发生故障或异常时，其他节点可以继续处理请求和备份数据，并将故障节点的任务转移到其他节点上，以保证系统的连续性和可用性。

高可用服务

合理的响应时间内访问服务——即使某些结果没有遵守顺序一致性

gossip系统

提供两种基本操作，查询是只读，更新用来更改状态而不读取状态

• 随着时间推移，每个用户最终获得一致的服务
  • 为了回答查询，副本管理器提供给一个客户的数据只要能反映迄今为止客户已经观测到的更细结果即可
  • 用户可以在不同的时间和不同的副本管理器
• 副本之间的松弛一致性
  • 所有副本管理器最终将收到所有的更新
  • 它们根据排序保证来应用这些更新，由排序规则使副本之间的一致性满足应用的要求。
  • 尽管gossip系统用来保证顺序一致性，但主要是保证较弱的一致性
  • 尽管副本包含同样的更新集，两个用户仍可观察到不同的副本，用户也可以观察到过时的数据

Gossip服务处理查询和更细的大致流程

• 请求：前端请求一个副本管理器，如果管理器不可达或故障可以和另一个管理器建立通信。
  • 前端和客户端可能阻塞在一个查询上。
  • 更新操作一旦传递给前端，前端就可以返回给客户。默认
  • 为了提高可靠性，用户可以被阻塞直到更新已经传给了f+1个副本，如果副本故障也会转发到另外一个副本继续
• 对更新操作的响应：如果请求是一个更新，副本管理器接收到之后就立即响应
• 协定：收到请求的副本管理器并不处理操作，直到它能根据所要求的次序约束处理请求，包括接收其它副本管理器以gossip消息形式发送的更新。各个副本管理器之间不存在其他方式的协调
• 执行：副本管理器执行请求
• 对查询操作的响应：如果请求是一个查询，那么将在此副本管理器执行响应
• 协定：通过交换gossip消息，副本管理包含大量最近收到的更新。
  • 它们之间以惰性的方式更新系统，因为gossip消息的交换是偶尔的
  • 在收集到若干更新后，或者当副本管理器发现它丢失了一个发送到其它副本管理器的更新该管理器正在处理新请求是又需要该更新时，系统才会交换gossip消息

前端的版本时间戳

• 为了控制操作处理的次序，每个前端维护了一个时间戳向量，用来反映前端访问的最新数据值
• 在该时间戳中，每个副本管理器有一个对应的记录。
• 前端将其放入每一个请求中，与更新和查询描述放在一起，发送给副本管理器。
• 当副本管理器返回一个值作为查询操作的结果时，副本管理器提供一个新的时间戳版本，因为处理最后一个操作后，副本可能已经更新了。
• 每一个返回的时间戳和前端先前的时间戳合并，用于记录已经被用户观察到的复制数据的版本。

副本管理器状态

• 不考虑应用时一个副本管理器应该有的状态：

  • 值，这是由副本管理器维护的应用状态的值，每个副本管理器是一个状态机。起始于一个特定的初始值。此后的状态完全由更新操作决定。
  • 值的时间戳：代表更新的时间戳向量，每个副本管理器有一个记录，当在值上发生更新操作，时间戳会更新。
  • 更新日志：所有的更新操作，只要接收到了，就记录在日志中。
    • 一个副本管理器在日志中更新的理由：
      • 操作不稳定，副本管理器不能进行更新操作
      • 一个稳定的更新操作是可以在排序保证情况下一致的执行，不稳定的更新必须阻止。
      • 即使更新是稳定的，并且已经在值上执行更新，副本管理器并没有收到已经被其他副本管理器收到的确认，同时，它以gossip形式广播消息。
  • 复制时间戳：这个时间戳代表哪些已经被其它副本管理器接收确认更新，已经在管理器的日志中。
    • 值和时间戳不同，因为日志更新是不稳定的
  • 已执行操作表：同样的更新可以通过前端或者gossip消息广播形式发送给一个副本管理器，为了防止一个更新被执行了两次，系统维护一个已执行表操作。包含了已经执行更新的唯一标识，唯一标识由前端提供。副本管理器将更新写入日志前检查这个表
  • 时间戳表：这个表为每一个副本管理器包含了一个填充在gossip消息中的时间戳向量。
    • 副本管理器通过该表建立一个何时更新已经应用到所有副本管理器。

  

查询操作

简单的操作是查询，通过前端传递描述和时间戳，副本管理器的任务就是返回一个最近的值。

副本管理将查询放到执行表中，一个保持队列，直到这个条件满足。

能够等待丢失的更新。也能从相关的副本器获取更新。

一旦执行了查询，副本管理器返回信息给前端，前端合并时间戳版本。

按照因果次序处理更新

• 前端提交一个更新操作给一个或多个副本管理器。
• 更新请求参数包含的规约
  • 类型和参数
  • 前端的时间戳
  • 前端生成的唯一标识
  • 如果唯一标识相同的请求发送给副本管理器，则会被当做相同的请求。
• 副本管理器接收请求后，通过在已存在的操作表和日志中查询这个操作标识是否已经被处理过了。
  • 找到则丢弃请求
  • 处理复制时间戳
  • 副本管理器分配给更新请求一个唯一的时间戳向量
  • 并且一个更新记录被放置到副本管理器的日志中

强制的立即的更新操作

需要特殊的处理

更新的强秩序和因果需是一致的

• 保证强制更新次序的方法
  • 将相联系的时间戳后加入一个唯一的序号，并以这个顺序号处理这个。

gossip消息

• 副本管理器可以发送一个或多个更新信息的gossip消息，以便其他的副本管理器更新他们的状态。
• 副本管理器使用它的时间戳表里的记录来估计其他的副本管理器更新是否收到。
• 一个gossip消息包含日志和副本时间戳，收到消息的副本管理器的主要任务
  • 将到达的日志和自己的日志合并（日志可能包含之前没有看到的消息）
  • 执行任何之前没有执行并已经稳定了的更新（gossip中的消息可能将之前未稳定更新的更新一起更新了）
  • 当知道更新已经执行并且已经没有被重复的危险时，删除日志和已经执行操作表的记录
  • 从日志和已更新表中删除冗余条目，不然会无限制的增长。

更新传播

• gossip体系并不指定何时副本管理器相互交换gossip消息。
• 也不指定某个副本管理器如何选择其他的副本管理器来发送gossip消息
• 如果一个副本管理器要在一个可接受的时间范围内收到所有的更新，必须有一个健壮的更新传播策略
• 三个因素
  • 网络分区的频率和持续时间
  • 副本管理器发送gossip消息的频率
  • 选择一个副本管理器并发送gossip策
• 合适的gossip频率由应用决定

复制数据上的事务

Transaction system design is a complex process that involves multiple components and considerations, including data copying. Here are some general guidelines and considerations for designing a transaction system that involves copying data:

1. Identify the source and destination systems: The first step in designing a data copying transaction system is to identify the source and destination systems. This will help determine the type and format of data that needs to be copied, as well as the methods and tools that will be used for copying.
2. Determine the data copying mechanism: There are several data copying mechanisms that can be used, including ETL (extract, transform, load) tools, replication, and custom scripts. The choice of mechanism will depend on factors such as the size and complexity of the data, the frequency of updates, and the level of automation required.
3. Define the transaction boundaries: In a data copying system, it is important to define the transaction boundaries to ensure data consistency and integrity. This may involve using transactional databases, implementing locking mechanisms, or using other techniques to ensure that data is copied accurately and completely.
4. Consider data validation and transformation: When copying data between systems, it is important to validate and transform the data as necessary to ensure that it is compatible with the destination system. This may involve data mapping, data cleansing, or other techniques to ensure that the data is accurate and consistent.
5. Implement error handling and recovery: In any transaction system, errors and failures are inevitable. It is important to implement error handling and recovery mechanisms to ensure that data is not lost or corrupted in the event of a failure. This may involve logging, monitoring, and alerting mechanisms, as well as backup and recovery procedures.
6. Test and validate the system: Before deploying a data copying transaction system, it is important to thoroughly test and validate the system to ensure that it is reliable, accurate, and efficient. This may involve testing the system in a staging environment, using test data, and validating the results against expected outcomes.

Overall, designing a data copying transaction system requires careful planning, consideration of multiple factors, and attention to detail. By following these guidelines and best practices, you can create a system that is reliable, efficient, and meets the needs of your organization.