分布式系统知识点总结

一、一致性协议

￥1. CAP理论

CAP理论是分布式系统设计中的一套指导原则，它指出在网络分区的情况下，一个分布式系统最多只能同时满足以下三点中的两点：

• 一致性（Consistency）：所有节点在同一时间看到的数据是一致的
• 可用性（Availability）：每个请求都能得到响应，即使某些节点出现故障。
• 分区容忍性（Partition tolerance）：系统能够处理网络分区的情况，即部分节点之间的通信受阻，而其他节点之间通信正常

2. 单主协议

由一个主节点发出数据，传输给其余从节点，能保证数据传输的有序性

• Paxos协议：如果存在大部分节点共同接收了该更新内容，可以认为本次更新已经达成一致。过于理论化，难以直接工程化

• Raft协议

3. Raft协议

数据传输流程（两阶段提交）：

1. Client向leader发送写请求指令，leader将该请求写入日志（但没提交）
2. leader去通知其他follower
3. follower收到通知后也将该请求写入日志（但没提交），并回复leader
4. 如果 leader收到半数节点的回复，则提交之前没提交的日志，并通知其他follower也提交日志

超过半数同意为什么能保证最终一致性

• 如果原 leader所处的分区节点数超过半数，那么其他分区肯定不能选举出新leader。该leader所处分区的日志都能正常提交，其他分区的日志仅仅被记录而不能提交。
• 这时如果连接恢复正常，其他分区的节点发现正常的节点的term大于它的term，那么它就知道已经选举产生了新的leader，那么它就会将原term中未提交的日志抛弃，而更新至与新term日志一致的状态，从而达到最终一致性。

6. 其他follower收到后提交之前没提交的日志

选举流程：

1. 如果一个follower在一个随机时间内（150-300ms）没有收到来自leader的heart beat,则其成为一个candidate参与到选举中，并将自己的term值加一
2. 然后该candidate投自己一票，然后要求集群中的其他节点给它投票。candidate收到term比自己大的投票请求时将自己的状态修改成follower
3. 如果收到集群内半数的投票，那么它就正式成为一个leader

4. 多主协议

从多个主节点出发传输数据，传输顺序具有随机性，因而数据的有序性无法得到保证，只保证最终数据的一致性

• Gossip算法

原理：初始由几个节点发起消息，这几个节点会将消息的更新内容告诉自己周围的节点，收到消息的节点再将这些信息告诉周围的节点。依照这种方式，获得消息的节点会越来越多，总体消息的传输规模会越来越大，消息的传播速度也越来越快。

特点：不是每个节点都能在相同的时间达成一致，但是最终集群中所有节点的信息必然是一致的。确保的是分布式集群的最终一致性。整体上达到一致性的速度是log(n)

Redis集群采用Gossip算法

• Proof-of-work（Pow）算法

原理：大量的节点参与竞争，通过自身的工作量大小来证明自己的能力，最终能力最大的节点获得优胜，其他节点的信息需要与该节点统一

特点：图谋不轨的一方无法篡改或者必须付出与收获完全不等称的代价才有修改的可能。

使用场景：比特币。所有参与者共同求解数学问题，这些数学问题往往需要经过大量枚举才能求解，因此需要参与者消耗大量的硬件算力。成功求解数学问题的参与者将获得记账权，并获得比特币作为奖励。其余所有参与者需要保持和获得记账权节点的区块一致，由此达到最终的一致性。

二、 分布式锁

1. 数据库分布式锁

原理：通过主键或者唯一索性两者都是唯一的特性，如果多个服务器同时请求到数据库，数据库只会允许同一时间只有一个服务器的请求在对数据库进行操作，其他服务器的请求就需要进行阻塞等待或者进行自旋

性能比较差，一般不建议使用

2. Redis分布式锁

通过setnx方法获取锁，并且设置锁的过期时间，需保证setnx和expire两行代码的原子性，借助Lua脚本

3. 基于Zookeeper的分布式锁

实现原理：

1. 每个要获取锁的线程都创建顺序临时节点，顺序第一的节点获取锁
2. 其他不是第一个节点的节点拿不到锁，需要监听上一个节点
3. 业务执行完成后，释放锁，第一个节点被删除
4. 第二个节点会监听到第一个节点被删除，成为第一个节点，获取锁
5. 后续节点依次类推

4. 分布式锁比较

• 性能：Redis通常比Zookeeper提供更好的性能，因为它是内存中的数据结构，而Zookeeper则是磁盘上的数据结构。因此，对于高并发的场景，Redis可能更适合用作分布式锁
• 功能：Zookeeper提供了更多的功能，如顺序节点、监听机制等，这些功能在某些情况下可能非常有用。但是，如果只需要简单的分布式锁，那么Redis可能是一个更好的选择。
• 复杂性：与Redis相比，Zookeeper的使用更加复杂。你需要处理连接问题、会话超时等问题。而Redis则是一个轻量级的解决方案，易于集成和使用。

Zookeeper分布式锁可以避免羊群效应

三、缓存数据一致性

1. 缓存更新策略

• Cache Aside模式：先更新数据库，再失效缓存。若失败，将需要删除的key发送给消息队列，业务系统接收到消息，根据消息内容重试删除操作。

• 是否可以先更新缓存，再更新数据库？
  一旦出现缓存成功而更新数据库失败的情况，会导致缓存错误值，导致业务上无法接受的一致性问题
• 是否可以先失效缓存，再更新数据库？
  通常数据库的写操作耗时大于读操作，一旦更新数据库期间有读请求并未命中缓存，会导致写回的数据为脏数据
• 为什么是失效缓存，而不是更新缓存？
  如A、B两个线程都执行写操作，A线程早于B执行（B数据是最新的），但A线程晚于B线程更新缓存，这样就会导致缓存中的数据是A线程更新的旧值，而不是B线程更新的最新值
• 先更新数据库，再失效缓存是否存在问题
  可能存在更新数据成功，失效缓存失败，导致缓存脏数据的问题。这种场景最常用的解决方案是为缓存设置失效时间，到期自动失效

• Read/Write Through 模式：数据更新时，若没有命中缓存，则直接更新数据库；如命中缓存，则更新缓存，由缓存服务更新数据库（同步更新）。将更新数据库的操作交由缓存代理，从应用的角度看，缓存是主存储，应用层的读写操作均面向缓存，缓存服务代理对数据库的读写
• Write Behind Caching模式：只更新缓存，缓存会异步批量更新数据库。无法保证数据强一致性，且可能会丢失数据

Cache Aside模式可能会存在一种概率极低的读写时序问题：读操作缓存未命中，同时伴随一个并发写操作；读操作在写操作完成数据库更新前读取了旧数据，且在写操作删除缓存后更新了缓存，从而导致数据库中的为最新数据，而缓存中的仍为旧数据

延时双删方案可以解决这一问题：删除缓存、更新数据库、休眠一段时间、再次删除缓存

绝大多数场景 Cache Aside + 自动过期 + 失败补偿 策略已能够满足要求

四、高并发系统设计

1. 设计原则

读操作原则：

• 对于数据量小、变更频率低、接收弱一致性的业务，一般以本地缓存策略为主，辅以分布式缓存策略
• 对于数据量较大、变更频率低、一致性要求高的业务，一般以分布式缓存策略为主，辅以本地缓存策略
• 对于音视频、流媒体、图片、静态资源等内容的分发加速，一般以CDN为主，辅以分布式缓存策略
• 限流策略作为兜底

写操作原则：

• 对于不可降级、时延敏感业务，一般以资源扩展策略为主，辅以流量削峰策略
• 对于不可降级、时延宽松业务，一般以流量削峰策略为主，辅以资源扩展策略
• 对于非核心且占用资源较多的业务，优先考虑服务降级策略
• 限流策略作为兜底

2. 资源扩展策略

• 垂直扩展：增加服务器CPU核数、采用高性能CPU、提升服务器内存、使用固态硬盘，提升硬盘容量、增加网络带宽
• 水平扩展：
  • 服务层水平扩展：
    • 增加应用服务器数量，采用多个实例对外提供相同的服务。并在客户端和业务服务器集群间增加一个负载均衡层，将来自客户端的请求均匀转发到业务服务器上
    • 由于同一用户的每次请求可能被负载均衡中间件转发到不同的实例上，从而导致上下文无法关联，因此业务服务应设计为无状态服务。
  • 数据层水平扩展：
    • 主从部署、读写分离
    • 分库分表

3. 负载均衡

• 四层负载均衡

原理：四层负载均衡服务器在接收到客户端请求后，会通过负载均衡算法选择一个最佳服务器，并对报文中目标IP地址进行修改（改为后端服务器IP），然后直接转发给该服务器。

客户端从DNS服务器获取到的只是服务器集群的虚拟IP（VIP），TCP连接是由客户端和后端业务服务器直接建立的，负载均衡节点只起转发作用

常用方案：LVS、Ali-LVS

• 七层负载均衡

原理：在OSI模型的应用层（HTTP、DNS等）是通过分析报文内容进行负载均衡

相较于四层负载均衡，七层负载均衡的流量路由方式要复杂的多。负载均衡节点需与客户端和服务端分别建立TCP连接（三次握手），才能接收到应用层报文的内容

优点：可以对客户端的请求和服务器的响应进行任意指定的修改，灵活的处理用户需求；并且可以设定多种策略过滤特定报文（如SQL注入），提升系统安全性

常用方案：Tengine（基于Nginx）

• 混合负载均衡

对于一些大型网站，通常会采用“DNS+四层负载+七层负载”

客户端发起请求时，如果使用的是四层协议（TCP/UDP），则LVS集群直接将流量转发给后端服务器，如果使用七层协议（HTTP/HTTPS），LVS会将服务请求转发给Tengine集群，Tengine集群再根据自身的调度算法选择相应的后端服务器建立连接。若使用了HTTPS协议，Tengine集群还需要与KeyServer交互，进行签名验签

4. 流量削峰策略

原理：削弱瞬时的请求高峰，让系统吞吐量在高峰请求下保持可控

• 消息队列削峰：异步化，消息队列在一端承接瞬时的流量洪峰，在另一端平缓地将消息推送出去
• 客户端削峰：核心思想是尽量避免用户同时请求和重复请求
  • 答题策略：用户需要先答题才能参与。该策略有损用户体验，通常在采用其他策略后仍无法满足高并发需求时使用
  • 限制请求：包括忽略请求（在一定条件下，忽略用户请求），延迟请求（随机算法延迟，分散请求）。该策略存在公平性问题，可能引发舆情，适用场景受限

5. 限流策略

• 单机限流：算法主要有令牌桶、漏桶、计数器算法
  • 令牌桶算法：存储固定容量的桶，按照固定的速率往桶里添加令牌。如果桶满了，多余的令牌会被丢弃。当请求到达时，需要从桶中移除一个令牌才能处理请求。如果桶中没有令牌，请求会被缓存或丢弃。
  • 漏桶算法：请求进来了就把请求先放进桶里，但是不处理，并以限定的速度出水，出水就相当于处理请求。当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务
  • 漏桶算法能够强行限制数据的传输速率，令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。
• 分布式限流：从全局视角实现整体限流

限流手段：

• 客户端限流：如通过浏览器端的JS代码监控点击频率、统计点击次数、或者通过客户端包中的限流逻辑让访问快速失败并返回。缺点是对全局流量无感知，客户端触发限流时，服务端的实际荷载可能还很小，不需要限流
• 接入层限流：Nginx通过漏桶算法实现了限流能力，主要提供两种限流方式：访问频率限制和并发连接数限制。但是接入层限流无法实现接口维度的流量管控
• 应用层限流：在业务代码层面实现精细控制的限流，如Sentinel就可以实现接口级的流量控制。
• Mesh限流：Service Mesh是一个基础设施层，用于处理服务间通信，通常由一系列轻量级的网络代理组成，与应用程序部署在一起，但对应用无感知。Service Mesh可以看做是微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控，所有应用程序间的流量都会通过它。实现如蚂蚁的MSON

6. 降级方案

执行方式：

• 手动降级：通过手动配置（通常是开关变量，通过修改其至来改变执行逻辑）启动降级链路。根据业务场景的需要，降级链路都是提前设计好的，如直接返回错误提示，或使用缓存
• 自动降级：一般有两种策略，所有失败均自动降级走兜底链路，或当频次触发降级阈值时采降级（一般是统计规定时间窗口内服务失败的次数和频率）

降级方案：

• 延迟服务：将非核心服务异步化，如存入消息队列或HBase中，待流量平稳后通过消费消息或定时任务执行
• 关闭/拒绝服务：在流量高峰时关闭低优先级服务
• 有损服务：如为减轻数据库压力而直接读缓存，可能会存在数据不一致问题

五、系统稳定性设计

1. 系统风险识别

• 高并发风险
• 远程调用风险：如网络抖动、依赖的下游系统重启、响应超时。对于未知调用结果，一般只能通过重试解决。同时需要根据具体场景分析重试策略（阶梯延时重试、定时调度重试）、幂等、重试顺序等

2. 系统容量评估

流量模型分析：基于入口核心服务的流量峰值，对全链路进行梳理、分析，推算出传递到下游的应用、中间件、数据库等节点的流量峰值

业务漏斗模型：业务流程的每一个环节可能有用户流失，把每一个环节及其对应的数据串联起来，会形成一个上大下小的漏斗形态
调用链路模型：分析调用链路上各个系统间的流量传递比例，分析得到整个系统链路的容量需求

系统容量验证：在给定QPS或TPS下是否存在性能瓶颈，核心业务链路是否正常运行。通过压力测试进行评估，测试粒度包括接口压测、核心链路压测、全链路压测