| created_date | 2023-03-10 |
|---|
[TOC]
-
参考
-
假设多个服务端节点，每个服务端节点都可以进行本地运算；多个客户端，每个客户端都可以请求任意一个服务端节点。
-
消息损坏
- 解决办法：在消息中增加校验码
-
消息丢失
- 解决办法：服务端接收到消息后向客户端发送确认消息；客户端一定时间内诺没有收到确认消息，则重发消息。
-
消息重复发送
- 解决办法：每条消息内添加序列号，防止服务端重复执行指令。
-
消息延迟
- 场景：不同服务端节点接收到不同客户端消息的时间点不一样，导致服务端节点间的数据不一致。
- 解决办法：另所有指令在服务端节点上将被按序执行，简称为状态复制（主从复制）
-
状态复制存在单节点故障
- 解决办法：确保在任何时候只有一个客户端在发送消息。加锁、互斥。通过给所有的服务端节点添加锁。
-
加锁存在一系列问题
- 问题
- 部分节点宕机，不反回锁。
- 多个客户端都锁定了部分服务端节点。
- 客户端释放锁之前就发生了故障。
- 解决办法：通过朴素的基于票的协议
- 问题
-
朴素的基于票的协议 -- 使用一个弱化形式的锁机制，票（Ticket）。
- 服务端节点可以随时发布票，票可以是有先后顺序的。
- 票是可以过期的。
- 客户端向所有服务端节点请求一张票；当有收到过半数的票；则向所有服务器发送获得的票和指令；服务端节点检查票是否有效，有效则存储指令；过半数的服务端节点给客户端正反馈；客户端通知所有服务器执行指令。
-
朴素的基于票的协议存在一个可能的问题。客户端通知所有服务端节点执行指令时，部分服务端节点的指令已经被另一个客户端更改。
- 是分布式数据一致性算法
- 是leader-follower模式
-
Raft 工作流程分为Propose，Append，Broadcast 和 Apply。
- 客户发起交易，叫做 Propose
- 记录交易，这个叫做 Append
- 通知其他网点，这个叫做 Broadcast
- 等最后知道大部分网点都确认了这笔交易记录，就执行交易，也就是 Apply。
对于客户 A，操作是 Propose，Append，Broadcast， Apply，对于客户 B 也是一样的流程，之前我们必须等 A 完成了，才能处理 B。 3. Batch
如果很多客户同时要发起交易，那么我们可以将这些交易记录，用一个消息发送到其它网点，这样我们就不需要一个一个的发送消息了，这就是 Batch。
各个网点之间距离还是有点远的，消息传递的时间开销还是有点大的。使用 Batch 可以减少消息的发送次数，自然就能提高效率了。
-
分布式系统的定义： 一个系统的服务分布在联通的服务器节点上，服务之间通过消息传递进行通信和动作协调的系统。
-
C Consistency 可用性。系统中的部分服务发生故障后，系统也能响应客户端的读写请求。
-
A Availability 数据一致性。系统中的所有服务，当进行数据处理时，持有的数据副本都是相同的。
-
P Partition tolerance 分区容错性。当服务器节点之间网络通信异常导致丢包、延迟、中断等时，不影响系统对外提供的服务。
-
分布式系统不能同时满足3个要求的根本原因：由于不同的服务设置在了不同的服务器节点上，存在网络延迟故障等。
-
假设存在nodeA 和 nodeB 两个服务器节点，节点间相互同步数据保持数据的一致性。 满足CA：发生网络故障时，服务器节点间无法进行数据同步，但不影响，因为所有的服务都被部署在了同一个服务器节点上。 满足AP：发生网络故障时，服务器节点间无法进行数据同步，为了保持数据的一致性，停止对外提供服务。 满足CP：发生网络故障时，服务器节点间无法进行数据同步，为了对外提供服务，旧的数据被返回。
- 分而治之的思想。
- 一种架构风格，软件的开发模式。
- 行为：将集成所有功能的一个进程 按功能模块拆分为 多个进程。
- 优点：可扩展，功能内聚，解耦，敏捷开发。
- 缺点：进程间的通信带来了其它的问题，网络可靠性，通信安全，网络时延。
- 一致性hash算法的目的
相当于提供了一个虚拟的中间层，把虚拟的slot和真实的物理节点关联起来，当动态地添加和减少节点时，能够有效地减少数据的迁移量。