《Kafka 核心技术与实战》笔记

发表于 2025-02-14 更新于 2025-04-01 分类于笔记，分布式，分布式通信本文字数： 15k 阅读时长 ≈ 13 分钟

《Kafka 核心技术与实战》笔记

开篇词为什么要学习 Kafka？

消息引擎系统 ABC

消息引擎系统的作用：

消息引擎传输的对象是消息；
如何传输消息属于消息引擎设计机制的一部分。

设计消息引擎系统的关键点：

序列化 - 决定了在网络中传输数据的形式。
- 代表：CSV、XML、JSON、Protocol Buffer、Thrift。
- kafka 默认使用纯二进制的字节序列。
传输模型：Kafka 同时支持以下两种模型
- 点对点模型
- 发布/订阅模型

消息引擎的作用：

异步处理
削峰填谷
系统解耦
系统间通信
数据缓冲
最终一致性

一篇文章带你快速搞定 Kafka 术语

Kafka 术语：

消息 - Record。Kafka 是消息引擎嘛，这里的消息就是指 Kafka 处理的主要对象。
主题 - Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
分区 - Partition。一个有序不变的消息序列。每个主题下可以有多个分区。
消息位移 - Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
副本 - Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
生产者 - Producer。向主题发布新消息的应用程序。
消费者 - Consumer。从主题订阅新消息的应用程序。
消费者位移 - Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。
消费者组 - Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
分区再均衡 - Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

Kafka 的三层消息架构：

第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本。
第二层是分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。
第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。
最后，客户端程序只能与分区的领导者副本进行交互。

Kafka 只是消息引擎系统吗？

Kafka 在设计之初就旨在提供三个方面的特性：

提供一套 API 实现生产者和消费者；
降低网络传输和磁盘存储开销；
实现高伸缩性架构。

作为流处理平台，Kafka 与其他主流大数据流式计算框架相比，优势在哪里呢？

更容易实现端到端的正确性（Correctness） - 因为所有的数据流转和计算都在 Kafka 内部完成，故 Kafka 可以实现端到端的精确一次处理语义。
Kafka 自己对于流式计算的定位 - 官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。

我应该选择哪种 Kafka？

Apache Kafka，也称社区版 Kafka。优势在于迭代速度快，社区响应度高，使用它可以让你有更高的把控度；缺陷在于仅提供基础核心组件，缺失一些高级的特性。
Confluent Kafka，Confluent 公司提供的 Kafka。优势在于集成了很多高级特性且由 Kafka 原班人马打造，质量上有保证；缺陷在于相关文档资料不全，普及率较低，没有太多可供参考的范例。
CDH/HDP Kafka，大数据云公司提供的 Kafka，内嵌 Apache Kafka。优势在于操作简单，节省运维成本；缺陷在于把控度低，演进速度较慢。

聊聊 Kafka 的版本号

Kafka 有以下重大版本：

0.7 - 只提供了最基础的消息队列功能
0.8
- 正式引入了副本机制
- 至少升级到 0.8.2.2
0.9
- 增加了基础的安全认证 / 权限功能
- 用 Java 重写了新版本消费者 API
- 引入了 Kafka Connect 组件
- 新版本 Producer API 在这个版本中算比较稳定
0.10
- 引入了 Kafka Streams，正式升级成分布式流处理平台
- 至少升级到 0.10.2.2
- 修复了一个可能导致 Producer 性能降低的 Bug
0.11
- 提供幂等性 Producer API 以及事务
- 对 Kafka 消息格式做了重构
- 至少升级到 0.11.0.3
1.0 和 2.0 - Kafka Streams 的改进

Kafka 线上集群部署方案怎么做？

系统

在 Linux 部署 Kafka 能够享受到零拷贝技术所带来的快速数据传输特性。

磁盘

使用机械磁盘完全能够胜任 Kafka 线上环境。

磁盘容量

假设你所在公司有个业务每天需要向 Kafka 集群发送 1 亿条消息，每条消息保存两份以防止数据丢失，另外消息默认保存两周时间。现在假设消息的平均大小是 1KB，那么你能说出你的 Kafka 集群需要为这个业务预留多少磁盘空间吗？

我们来计算一下：每天 1 亿条 1KB 大小的消息，保存两份且留存两周的时间，那么总的空间大小就等于1 亿 * 1KB * 2 / 1000 / 1000 = 200GB。一般情况下 Kafka 集群除了消息数据还有其他类型的数据，比如索引数据等，故我们再为这些数据预留出 10%的磁盘空间，因此总的存储容量就是 220GB。既然要保存两周，那么整体容量即为 220GB * 14，大约 3TB 左右。Kafka 支持数据的压缩，假设压缩比是 0.75，那么最后你需要规划的存储空间就是 0.75 * 3 = 2.25TB。

总之在规划磁盘容量时你需要考虑下面这几个元素：

新增消息数
消息留存时间
平均消息大小
备份数
是否启用压缩

带宽

通常使用的都是普通的以太网络，带宽也主要有两种：1Gbps 的千兆网络和 10Gbps 的万兆网络。

假设你公司的机房环境是千兆网络，即 1Gbps，现在你有个业务，其业务目标或 SLA 是在 1 小时内处理 1TB 的业务数据。那么问题来了，你到底需要多少台 Kafka 服务器来完成这个业务呢？

让我们来计算一下，由于带宽是 1Gbps，即每秒处理 1Gb 的数据，假设每台 Kafka 服务器都是安装在专属的机器上，也就是说每台 Kafka 机器上没有混部其他服务，毕竟真实环境中不建议这么做。通常情况下你只能假设 Kafka 会用到 70%的带宽资源，因为总要为其他应用或进程留一些资源。

根据实际使用经验，超过 70%的阈值就有网络丢包的可能性了，故 70%的设定是一个比较合理的值，也就是说单台 Kafka 服务器最多也就能使用大约 700Mb 的带宽资源。

稍等，这只是它能使用的最大带宽资源，你不能让 Kafka 服务器常规性使用这么多资源，故通常要再额外预留出 2/3 的资源，即单台服务器使用带宽 700Mb / 3 ≈ 240Mbps。需要提示的是，这里的 2/3 其实是相当保守的，你可以结合你自己机器的使用情况酌情减少此值。

好了，有了 240Mbps，我们就可以计算 1 小时内处理 1TB 数据所需的服务器数量了。根据这个目标，我们每秒需要处理 2336Mb 的数据，除以 240，约等于 10 台服务器。如果消息还需要额外复制两份，那么总的服务器台数还要乘以 3，即 30 台。

最最最重要的集群参数配置（上）

与存储信息相关的参数

log.dirs：这是非常重要的参数，指定了 Broker 需要使用的若干个文件目录路径。要知道这个参数是没有默认值的，这说明什么？这说明它必须由你亲自指定。
log.dir：注意这是 dir，结尾没有 s，说明它只能表示单个路径，它是补充上一个参数用的。

只要设置log.dirs，即第一个参数就好了，不要设置log.dir。而且更重要的是，在线上生产环境中一定要为log.dirs配置多个路径，具体格式是一个 CSV 格式，也就是用逗号分隔的多个路径，比如/home/kafka1,/home/kafka2,/home/kafka3这样。如果有条件的话你最好保证这些目录挂载到不同的物理磁盘上。这样做有两个好处：

提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。
能够实现故障转移：即 Failover。这是 Kafka 1.1 版本新引入的强大功能。要知道在以前，只要 Kafka Broker 使用的任何一块磁盘挂掉了，整个 Broker 进程都会关闭。但是自 1.1 开始，这种情况被修正了，坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上，而且 Broker 还能正常工作。还记得上一期我们关于 Kafka 是否需要使用 RAID 的讨论吗？这个改进正是我们舍弃 RAID 方案的基础：没有这种 Failover 的话，我们只能依靠 RAID 来提供保障。

与 ZooKeeper 相关的参数

zookeeper.connect。这也是一个 CSV 格式的参数，比如我可以指定它的值为zk1:2181,zk2:2181,zk3:2181。2181 是 ZooKeeper 的默认端口。

如果我让多个 Kafka 集群使用同一套 ZooKeeper 集群，那么这个参数应该怎么设置呢？这时候 chroot 就派上用场了。这个 chroot 是 ZooKeeper 的概念，类似于别名。

如果你有两套 Kafka 集群，假设分别叫它们 kafka1 和 kafka2，那么两套集群的zookeeper.connect参数可以这样指定：zk1:2181,zk2:2181,zk3:2181/kafka1和zk1:2181,zk2:2181,zk3:2181/kafka2。切记 chroot 只需要写一次，而且是加到最后的。我经常碰到有人这样指定：zk1:2181/kafka1,zk2:2181/kafka2,zk3:2181/kafka3，这样的格式是不对的。

与 Broker 连接相关的参数

listeners：学名叫监听器，其实就是告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务。
advertised.listeners：和 listeners 相比多了个 advertised。Advertised 的含义表示宣称的、公布的，就是说这组监听器是 Broker 用于对外发布的。
host.name/port：列出这两个参数就是想说你把它们忘掉吧，压根不要为它们指定值，毕竟都是过期的参数了。

关于 Topic 管理的参数

auto.create.topics.enable：是否允许自动创建 Topic。
unclean.leader.election.enable：是否允许 Unclean Leader 选举。
auto.leader.rebalance.enable：是否允许定期进行 Leader 选举。

关于数据留存的参数

log.retention.{hours|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hours 最低。
log.retention.bytes：这是指定 Broker 为消息保存的总磁盘容量大小。
message.max.bytes：控制 Broker 能够接收的最大消息大小。

最最最重要的集群参数配置（下）

Topic 级别参数

retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。
retention.bytes：规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的 Kafka 集群中会有用武之地。当前默认值是-1，表示可以无限使用磁盘空间。

JVM 参数

KAFKA_HEAP_OPTS：指定堆大小。
KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。

操作系统参数

文件描述符限制 - 通常情况下将它设置成一个超大的值是合理的做法，比如ulimit -n 1000000。
文件系统类型 - 生产环境最好还是使用 XFS
Swappiness - 建议将 swappniess 配置成一个接近 0 但不为 0 的值，比如 1。
提交时间

生产者消息分区机制原理剖析

Kafka 的消息组织方式实际上是三级结构：主题-分区-消息。主题下的每条消息只会保存在某一个分区中，而不会在多个分区中被保存多份。

分区是实现负载均衡以及高吞吐量的关键。

所谓分区策略，就是决定生产者将消息发送到哪个分区的算法。Kafka 提供了默认的分区策略，同时也支持自定义分区策略。

生产者压缩算法面面观

压缩秉承了用时间去换空间的思想。具体来说，就是用 CPU 时间去换磁盘空间或网络 I/O 传输量，希望以较小的 CPU 开销带来更少的磁盘占用或更少的网络 I/O 传输。

Kafka 压缩、解压流程：Producer 端压缩、Broker 端保持、Consumer 端解压缩。

每个压缩过的消息集合在 Broker 端写入时都要发生解压缩操作，目的就是为了对消息执行各种验证。

让 Broker 重新压缩消息的 2 种例外：Broker 端指定了和 Producer 端不同的压缩算法；Broker 发生了消息格式转换。

在 Kafka 2.1.0 版本之前，Kafka 支持 3 种压缩算法：GZIP、Snappy 和 LZ4。从 2.1.0 开始，Kafka 正式支持 Zstandard 算法（简写为 zstd）。

对于 Kafka 而言，它们的性能测试结果却出奇得一致：

在吞吐量方面：LZ4 > Snappy > zstd 和 GZIP；
在压缩比方面，zstd > LZ4 > GZIP > Snappy。

无消息丢失配置怎么实现？

Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证。

生产阶段使用异步回调方式发送消息，业务侧做好对于发送失败的容错处理。
- 不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。记住，一定要使用带有回调通知的 send 方法。
- 设置 retries 为一个较大的值。这里的 retries 同样是 Producer 的参数，对应前面提到的 Producer 自动重试。当出现网络的瞬时抖动时，消息发送可能会失败，此时配置了 retries > 0 的 Producer 能够自动重试消息发送，避免消息丢失。
存储阶段需要保证写入数据同步副本，以及可靠的故障恢复。
- 设置 acks = all。acks 是 Producer 的一个参数，代表了你对“已提交”消息的定义。如果设置成 all，则表明所有副本 Broker 都要接收到消息，该消息才算是“已提交”。这是最高等级的“已提交”定义。
- 设置 unclean.leader.election.enable = false。这是 Broker 端的参数，它控制的是哪些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多，那么它一旦成为新的 Leader，必然会造成消息的丢失。故一般都要将该参数设置成 false，即不允许这种情况的发生。
- 设置 replication.factor >= 3。这也是 Broker 端的参数。其实这里想表述的是，最好将消息多保存几份，毕竟目前防止消息丢失的主要机制就是冗余。
- 设置 min.insync.replicas > 1。这依然是 Broker 端参数，控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在实际环境中千万不要使用默认值 1。
- 确保 replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在不降低可用性的基础上完成。推荐设置成 replication.factor = min.insync.replicas + 1。
消费阶段确保消息消费完成再提交。Consumer 端有个参数 enable.auto.commit，最好把它设置成 false，并采用手动提交位移的方式。就像前面说的，这对于单 Consumer 多线程处理的场景而言是至关重要的。

客户端都有哪些不常见但是很高级的功能？

拦截器基本思想就是允许应用程序在不修改逻辑的情况下，动态地实现一组可插拔的事件处理逻辑链。它能够在主业务操作的前后多个时间点上插入对应的“拦截”逻辑。

Kafka 拦截器分为生产者拦截器和消费者拦截器。生产者拦截器允许你在发送消息前以及消息提交成功后植入你的拦截器逻辑；而消费者拦截器支持在消费消息前以及提交位移后编写特定逻辑。指定拦截器类时要指定它们的全限定名。

Kafka 拦截器可以应用于包括客户端监控、端到端系统性能检测、消息审计等多种功能在内的场景。

Java 生产者是如何管理 TCP 连接的？

开发客户端时，能够利用 TCP 本身提供的一些高级功能，比如多路复用请求以及同时轮询多个连接的能力。

对最新版本的 Kafka（2.1.0）而言，Java Producer 端管理 TCP 连接的方式是：

KafkaProducer 实例创建时启动 Sender 线程，从而创建与 bootstrap.servers 中所有 Broker 的 TCP 连接。
- 不需要把集群中所有的 Broker 信息都配置到 bootstrap.servers 中，通常你指定 3～4 台就足以了。因为 Producer 一旦连接到集群中的任一台 Broker，就能拿到整个集群的 Broker 信息，故没必要为 bootstrap.servers 指定所有的 Broker。
TCP 连接还可能在两个地方被创建：一个是在更新元数据后，另一个是在消息发送时。
1. KafkaProducer 实例首次更新元数据信息之后，还会再次创建与集群中所有 Broker 的 TCP 连接。
2. 如果 Producer 端发送消息到某台 Broker 时发现没有与该 Broker 的 TCP 连接，那么也会立即创建连接。
Producer 端关闭 TCP 连接的方式有两种：一种是用户主动关闭；一种是 Kafka 自动关闭。如果设置 Producer 端 connections.max.idle.ms 参数大于 0，则步骤 1 中创建的 TCP 连接会被自动关闭；如果设置该参数=-1，那么步骤 1 中创建的 TCP 连接将无法被关闭，从而成为“僵尸”连接。

幂等生产者和事务生产者是一回事吗？

消息可靠性保证有以下几种：

最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。
至少一次（at least once）：消息不会丢失，但有可能被重复发送。
精确一次（exactly once）：消息不会丢失，也不会被重复发送。

大部分 MQ 都支持 at least once，要实现 exactly once，需要消费方保证，通常是通过幂等性设计来实现。

Kafka 也提供了一些相关的功能：

幂等性 Producer 只能保证单分区上的幂等性，同时也只能实现单会话上的幂等性。

事务型 Producer 能够保证将消息原子性地写入到多个分区中，而且不惧进程的重启。

消费者组到底是什么？

Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。

Consumer Group 特性：

Consumer Group 下可以有一个或多个 Consumer 实例。这里的实例可以是一个单独的进程，也可以是同一进程下的线程。在实际场景中，使用进程更为常见一些。
Group ID 是一个字符串，在一个 Kafka 集群中，它标识唯一的一个 Consumer Group。
Consumer Group 下所有实例订阅的主题的单个分区，只能分配给组内的某个 Consumer 实例消费。这个分区当然也可以被其他的 Group 消费。

Kafka 仅仅使用 Consumer Group 这一种机制，却同时实现了传统消息引擎系统的两大模型：如果所有实例都属于同一个 Group，那么它实现的就是消息队列模型；如果所有实例分别属于不同的 Group，那么它实现的就是发布/订阅模型。

理想情况下，Consumer 实例的数量应该等于该 Group 订阅主题的分区总数。

分区再均衡规定了一个 Consumer Group 下的所有 Consumer 如何达成一致，来分配订阅 Topic 的每个分区。

Rebalance 的触发条件：

组成员数发生变更。
订阅主题数发生变更。
订阅主题的分区数发生变更。

Rebalance 的问题：

在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 完成。
Rebalance 的设计是所有 Consumer 实例共同参与，全部重新分配所有分区。其实更高效的做法是尽量减少分配方案的变动。
Rebalance 实在是太慢了。

最好的解决方案就是避免 Rebalance 的发生吧。

揭开神秘的“位移主题”面纱

consumer_offsets 在 Kafka 源码中有个更为正式的名字，叫位移主题，即 Offsets Topic。

老版本 Consumer 的位移管理是依托于 Apache ZooKeeper 的，它会自动或手动地将位移数据提交到 ZooKeeper 中保存。当 Consumer 重启后，它能自动从 ZooKeeper 中读取位移数据，从而在上次消费截止的地方继续消费。这种设计使得 Kafka Broker 不需要保存位移数据，减少了 Broker 端需要持有的状态空间，因而有利于实现高伸缩性。但是，ZooKeeper 其实并不适用于这种高频的写操作。

新版本 Consumer 的位移管理机制其实也很简单，就是将 Consumer 的位移数据作为一条条普通的 Kafka 消息，提交到 consumer_offsets 中。可以这么说，consumer_offsets 的主要作用是保存 Kafka 消费者的位移信息。它要求这个提交过程不仅要实现高持久性，还要支持高频的写操作。显然，Kafka 的主题设计天然就满足这两个条件，因此，使用 Kafka 主题来保存位移这件事情，实际上就是一个水到渠成的想法了。

虽说位移主题是一个普通的 Kafka 主题，但它的消息格式却是 Kafka 自己定义的，不能随意地向这个主题写消息。

当 Kafka 集群中的第一个 Consumer 程序启动时，Kafka 会自动创建位移主题。

Kafka 使用** Compact 策略**来删除位移主题中的过期消息，避免该主题无限期膨胀。

消费者组重平衡能避免吗？

Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。

Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。

第一类非必要 Rebalance 是因为未能及时发送心跳，导致 Consumer 被“踢出”Group 而引发的。

设置 session.timeout.ms = 6s。
设置 heartbeat.interval.ms = 2s。
要保证 Consumer 实例在被判定为“dead”之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。

第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。

max.poll.interval.ms 参数值要大于下游最大处理时间。

Kafka 中位移提交那些事儿

Consumer 需要向 Kafka 汇报自己的位移数据，这个汇报过程被称为提交位移（Committing Offsets）。因为 Consumer 能够同时消费多个分区的数据，所以位移的提交实际上是在分区粒度上进行的，即** Consumer 需要为分配给它的每个分区提交各自的位移数据**。

位移提交分为自动提交和手动提交，而手动提交又分为同步提交和异步提交。

CommitFailedException 异常怎么处理？

CommitFailedException，就是 Consumer 客户端在提交位移时出现了错误或异常，而且还是那种不可恢复的严重异常。

CommitFailedException 最常见的场景：当消息处理的总时间超过预设的 max.poll.interval.ms 参数值时，Kafka Consumer 端会抛出 CommitFailedException 异常。

多线程开发消费者实例

消费者程序启动多个线程，每个线程维护专属的 KafkaConsumer 实例，负责完整的消息获取、消息处理流程。如下图所示：

消费者程序使用单或多线程获取消息，同时创建多个消费线程执行消息处理逻辑。获取消息的线程可以是一个，也可以是多个，每个线程维护专属的 KafkaConsumer 实例，处理消息则交由特定的线程池来做，从而实现消息获取与消息处理的真正解耦。具体架构如下图所示：

方案对比：

Java 消费者是如何管理 TCP 连接的

和生产者不同的是，构建 KafkaConsumer 实例时是不会创建任何 TCP 连接的。

TCP 连接是在调用 KafkaConsumer.poll 方法时被创建的。再细粒度地说，在 poll 方法内部有 3 个时机可以创建 TCP 连接。

发起 FindCoordinator 请求时
连接协调者时
消费数据时

消费者程序会创建 3 类 TCP 连接：

确定协调者和获取集群元数据
连接协调者，令其执行组成员管理操作
执行实际的消息获取

消费者组消费进度监控都怎么实现？

对于 Kafka 消费者来说，最重要的事情就是监控它们的消费进度了，或者说是监控它们消费的滞后程度。所谓滞后程度，就是指消费者当前落后于生产者的程度。

监控消费者组以及独立消费者程序消费进度的 3 种方法：

使用 Kafka 自带的命令行工具 kafka-consumer-groups 脚本
使用 Kafka Java Consumer API 编程
使用 Kafka 自带的 JMX 监控指标

Kafka 副本机制详解

副本

副本机制好处：

提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。
提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。
改善数据局部性。允许将数据放入与用户地理位置相近的地方，从而降低系统延时。

所谓副本（Replica），本质就是一个只能追加写消息的提交日志。

基于领导者的副本机制

在 Kafka 中，副本分成两类：领导者副本（Leader Replica）和追随者副本（Follower Replica）。每个分区在创建时都要选举一个副本，称为领导者副本，其余的副本自动称为追随者副本。

In-sync Replicas（ISR）

追随者副本不提供服务，只是定期地异步拉取领导者副本中的数据而已。

Kafka 引入了 In-sync Replicas（ISR）机制来明确追随者副本到底在什么条件下才算与 Leader 同步。

ISR 不只是追随者副本集合，它必然包括 Leader 副本。甚至在某些情况下，ISR 只有 Leader 这一个副本。

Broker 端参数 replica.lag.time.max.ms 用于配置 Follower 副本能够落后 Leader 副本的最长时间间隔，当前默认值是 10 秒。这就是说，只要一个 Follower 副本落后 Leader 副本的时间不连续超过 10 秒，那么 Kafka 就认为该 Follower 副本与 Leader 是同步的，即使此时 Follower 副本中保存的消息明显少于 Leader 副本中的消息。

Unclean 领导者选举（Unclean Leader Election）

因为 Leader 副本天然就在 ISR 中，如果 ISR 为空了，就说明 Leader 副本也“挂掉”了，Kafka 需要重新选举一个新的 Leader。Broker 端参数 unclean.leader.election.enable 控制是否允许 Unclean 领导者选举。

开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性。反之，禁止 Unclean 领导者选举的好处在于维护了数据的一致性，避免了消息丢失，但牺牲了高可用性。

Kafka 把所有不在 ISR 中的存活副本都称为非同步副本。

请求是怎么被处理的？

Kafka 所有的请求都是通过 TCP 网络以 Socket 的方式进行通讯的。

Reactor 模式是事件驱动架构的一种实现方式，特别适合应用于处理多个客户端并发向服务器端发送请求的场景。

Kafka 采用了类 Reactor 架构

Acceptor 线程采用轮询的方式将入站请求公平地发到所有网络线程中，因此，在实际使用过程中，这些线程通常都有相同的几率被分配到待处理请求。

当网络线程拿到请求后，将请求放入到一个共享请求队列中。Broker 端还有个 IO 线程池，负责从该队列中取出请求，执行真正的处理。如果是 PRODUCE 生产请求，则将消息写入到底层的磁盘日志中；如果是 FETCH 请求，则从磁盘或页缓存中读取消息。

Purgatory 是用来缓存延时请求（Delayed Request）的。所谓延时请求，就是那些一时未满足条件不能立刻处理的请求。比如设置了 acks=all 的 PRODUCE 请求，一旦设置了 acks=all，那么该请求就必须等待 ISR 中所有副本都接收了消息后才能返回，此时处理该请求的 IO 线程就必须等待其他 Broker 的写入结果。当请求不能立刻处理时，它就会暂存在 Purgatory 中。稍后一旦满足了完成条件，IO 线程会继续处理该请求，并将 Response 放入对应网络线程的响应队列中。

消费者组重平衡全流程解析

重平衡的 3 个触发条件：

组成员数量发生变化。
订阅主题数量发生变化。
订阅主题的分区数发生变化。

消费者端重平衡流程：

Rebalance 是通过消费者群组中的称为“群主”消费者客户端进行的**。

（1）选择群主

当消费者要加入群组时，会向群组协调器发送一个 JoinGroup 请求。第一个加入群组的消费者将成为“群主”。群主从协调器那里获取群组的活跃成员列表，并负责给每一个消费者分配分区。

所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。具体来讲，Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。

（2）消费者通过向被指派为群组协调器（Coordinator）的 Broker 定期发送心跳来维持它们和群组的从属关系以及它们对分区的所有权。

（3）群主从群组协调器获取群组成员列表，然后给每一个消费者进行分配分区 Partition。有两种分配策略：Range 和 RoundRobin。

Range 策略，就是把若干个连续的分区分配给消费者，如存在分区 1-5，假设有 3 个消费者，则消费者 1 负责分区 1-2, 消费者 2 负责分区 3-4，消费者 3 负责分区 5。
RoundRoin 策略，就是把所有分区逐个分给消费者，如存在分区 1-5，假设有 3 个消费者，则分区 1->消费 1，分区 2->消费者 2，分区 3>消费者 3，分区 4>消费者 1，分区 5->消费者 2。

（4）群主分配完成之后，把分配情况发送给群组协调器。

（5）群组协调器再把这些信息发送给消费者。每个消费者只能看到自己的分配信息，只有群主知道所有消费者的分配信息。

你一定不能错过的 Kafka 控制器

控制器组件（Controller），是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。每台 Broker 都能充当控制器，第一个成功创建 /controller 节点的 Broker 会被指定为控制器。

ZooKeeper 是一个提供高可靠性的分布式协调服务框架。ZooKeeper 常被用来实现集群成员管理、分布式锁、领导者选举等功能。Kafka 控制器大量使用 Watch 功能实现对集群的协调管理。

下图展示了 Kafka 在 ZooKeeper 中创建的 znode 分布：

控制器的职责：

主题管理（创建、删除、增加分区）
分区重分配
Preferred 领导者选举
集群成员管理（新增 Broker、Broker 主动关闭、Broker 宕机）
数据服务

控制器保存的数据：

控制器故障转移

故障转移指的是，当运行中的控制器突然宕机或意外终止时，Kafka 能够快速地感知到，并立即启用备用控制器来代替之前失败的控制器。这个过程就被称为 Failover，该过程是自动完成的，无需你手动干预。

关于高水位和 Leader Epoch 的讨论

水位一词多用于流式处理领域，比如，Spark Streaming 或 Flink 框架中都有水位的概念。

水位是一个单调增加且表征最早未完成工作（oldest work not yet completed）的时间戳。

高水位的作用

在 Kafka 中，高水位的作用主要有 2 个。

定义消息可见性，即用来标识分区下的哪些消息是可以被消费者消费的。
- 在分区高水位以下的消息被认为是已提交消息，反之就是未提交消息。消费者只能消费已提交消息。
- 同一个副本对象，其高水位值不会大于 LEO 值。
- 分区的高水位就是其 Leader 副本的高水位。
帮助 Kafka 完成副本同步。

高水位更新机制

Broker 0 上保存了某分区的 Leader 副本和所有 Follower 副本的 LEO 值，而 Broker 1 上仅仅保存了该分区的某个 Follower 副本。Kafka 把 Broker 0 上保存的这些 Follower 副本又称为远程副本（Remote Replica）。Kafka 副本机制在运行过程中，会更新 Broker 1 上 Follower 副本的高水位和 LEO 值，同时也会更新 Broker 0 上 Leader 副本的高水位和 LEO 以及所有远程副本的 LEO，但它不会更新远程副本的高水位值，也就是我在图中标记为灰色的部分。

为什么要在 Broker 0 上保存这些远程副本呢？其实，它们的主要作用是，帮助 Leader 副本确定其高水位，也就是分区高水位。

副本同步机制解析

首先是初始状态。下面这张图中的 remote LEO 就是刚才的远程副本的 LEO 值。在初始状态时，所有值都是 0。

当生产者给主题分区发送一条消息后，状态变更为：

此时，Leader 副本成功将消息写入了本地磁盘，故 LEO 值被更新为 1。

Follower 再次尝试从 Leader 拉取消息。和之前不同的是，这次有消息可以拉取了，因此状态进一步变更为：

这时，Follower 副本也成功地更新 LEO 为 1。此时，Leader 和 Follower 副本的 LEO 都是 1，但各自的高水位依然是 0，还没有被更新。它们需要在下一轮的拉取中被更新，如下图所示：

在新一轮的拉取请求中，由于位移值是 0 的消息已经拉取成功，因此 Follower 副本这次请求拉取的是位移值=1 的消息。Leader 副本接收到此请求后，更新远程副本 LEO 为 1，然后更新 Leader 高水位为 1。做完这些之后，它会将当前已更新过的高水位值 1 发送给 Follower 副本。Follower 副本接收到以后，也将自己的高水位值更新成 1。至此，一次完整的消息同步周期就结束了。事实上，Kafka 就是利用这样的机制，实现了 Leader 和 Follower 副本之间的同步。

Leader Epoch

所谓 Leader Epoch，我们大致可以认为是 Leader 版本。它由两部分数据组成。

Epoch。一个单调增加的版本号。每当副本领导权发生变更时，都会增加该版本号。小版本号的 Leader 被认为是过期 Leader，不能再行使 Leader 权力。
起始位移（Start Offset）。Leader 副本在该 Epoch 值上写入的首条消息的位移。

主题管理知多少

Kafka 提供了自带的 kafka-topics 脚本，用于帮助用户创建主题。

特殊主题：

consumer_offsets
transaction_state

Kafka 动态配置了解下？

略

怎么重设消费者组位移？

略

常见工具脚本大汇总

略

KafkaAdminClient：Kafka 的运维利器

略

Kafka 认证机制用哪家？

略

云环境下的授权该怎么做？

略

跨集群备份解决方案 MirrorMaker

略

你应该怎么监控 Kafka？

略

主流的 Kafka 监控框架

略

调优 Kafka，你做到了吗？

略

从 0 搭建基于 Kafka 的企业级实时日志流处理平台

略

Kafka Streams 与其他流处理平台的差异在哪里？

略

Kafka Streams DSL 开发实例

略

Kafka Streams 在金融领域的应用

略

参考资料

极客时间教程 - Kafka 核心技术与实战

Kafka 面试

发表于 2025-02-03 更新于 2025-04-01 分类于分布式，分布式通信， mq ， kafka 本文字数： 20k 阅读时长 ≈ 18 分钟

Kafka 面试

Kafka 简介

【基础】什么是 Kafka?

:::details 要点

Apache Kafka 是一款开源的消息引擎系统，也是一个分布式流计算平台，此外，还可以作为数据存储。

Kafka 的核心功能如下：

消息引擎 - Kafka 可以作为一个消息引擎系统。
流处理 - Kafka 可以作为一个分布式流处理平台。
存储 - Kafka 可以作为一个安全的分布式存储。

Kafka 的设计目标：

高性能
- 分区、分段、索引：基于分区机制提供并发处理能力。分段、索引提升了数据读写的查询效率。
- 顺序读写：使用顺序读写提升磁盘 IO 性能。
- 零拷贝：利用零拷贝技术，提升网络 I/O 效率。
- 页缓存：利用操作系统的 PageCache 来缓存数据（典型的利用空间换时间）
- 批量读写：批量读写可以有效提升网络 I/O 效率。
- 数据压缩：Kafka 支持数据压缩，可以有效提升网络 I/O 效率。
- pull 模式：Kafka 架构基于 pull 模式，可以自主控制消费策略，提升传输效率。
高可用
- 持久化：Kafka 所有的消息都存储在磁盘，天然支持持久化。
- 副本机制：Kafka 的 Broker 集群支持副本机制，可以通过冗余，来保证其整体的可用性。
- 选举 Leader：Kafka 基于 ZooKeeper 支持选举 Leader，实现了故障转移能力。
伸缩性
- 分区：Kafka 的分区机制使得其具有良好的伸缩性。

:::

【基础】Kafka 有哪些核心术语？

:::details 要点

Kafka 的核心术语如下：

消息 - Record。Kafka 是消息引擎嘛，这里的消息就是指 Kafka 处理的主要对象。
主题 - Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
分区 - Partition。一个有序不变的消息序列。每个主题下可以有多个分区。
消息位移 - Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
副本 - Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
生产者 - Producer。向主题发布新消息的应用程序。
消费者 - Consumer。从主题订阅新消息的应用程序。
消费者位移 - Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。
消费者组 - Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
分区再均衡 - Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

Kafka 的三层消息架构：

第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本。
第二层是分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。
第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。
最后，客户端程序只能与分区的领导者副本进行交互。

:::

Kafka 存储

【中级】Kafka 是如何存储数据的？

:::details 要点

Kafka 逻辑存储

Kafka 的数据结构采用三级结构，即：主题（Topic）、分区（Partition）、消息（Record）。

在 Kafka 中，任意一个 Topic 维护了一组 Partition 日志，如下所示：

请注意：这里的主题只是一个逻辑上的抽象概念，实际上，Kafka 的基本存储单元是 Partition。Partition 无法在多个 Broker 间进行再细分，也无法在同一个 Broker 的多个磁盘上进行再细分。所以，分区的大小受到单个挂载点可用空间的限制。

Partiton 命名规则为 Topic 名称 + 有序序号，第一个 Partiton 序号从 0 开始，序号最大值为 Partition 数量减 1。

Kafka 物理存储

Log 是 Kafka 用于表示日志文件的组件。每个 Partiton 对应一个 Log 对象，在物理磁盘上则对应一个目录。如：创建一个双分区的主题 test，那么，Kafka 会在磁盘上创建两个子目录：test-0 和 test-1；而在服务器端，这就对应两个 Log 对象。

因为在一个大文件中查找和删除消息是非常耗时且容易出错的。所以，Kafka 将每个 Partition 切割成若干个片段，即日志段（Log Segment）。默认每个 Segment 大小不超过 1G，且只包含 7 天的数据。如果 Segment 的消息量达到 1G，那么该 Segment 会关闭，同时打开一个新的 Segment 进行写入。

Broker 会为 Partition 里的每个 Segment 打开一个文件句柄（包括不活跃的 Segment），因此打开的文件句柄数通常会比较多，这个需要适度调整系统的进程文件句柄参数。正在写入的分片称为活跃片段（active segment），活跃片段永远不会被删除。

Segment 文件命名规则：Partition 全局的第一个 segment 从 0 开始，后续每个 segment 文件名为上一个 segment 文件最后一条消息的 offset 值。数值最大为 64 位 long 大小，19 位数字字符长度，没有数字用 0 填充。

Segment 文件可以分为两类：

索引文件
- 偏移量索引文件（ .index ）
- 时间戳索引文件（ .timeindex ）
- 已终止事务的索引文件（.txnindex）：如果没有使用 Kafka 事务，则不会创建该文件
日志数据文件（.log）

:::

【高级】Kafka 文件格式是怎样的？

:::details 要点

Kafka 的消息和偏移量保存在文件里。保存在磁盘上的数据格式和从生产者发送过来或消费者读取的数据格式是一样的。因为使用了相同的数据格式，使得 Kafka 可以进行零拷贝技术给消费者发送消息，同时避免了压缩和解压。

除了键、值和偏移量外，消息里还包含了消息大小、校验和（检测数据损坏）、魔数（标识消息格式版本）、压缩算法（Snappy、GZip 或者 LZ4）和时间戳（0.10.0 新增）。时间戳可以是生产者发送消息的时间，也可以是消息到达 Broker 的时间，这个是可配的。

如果生产者发送的是压缩的消息，那么批量发送的消息会压缩在一起，以“包装消息”（wrapper message）来发送，如下所示：

如果生产者使用了压缩功能，发送的批次越大，就意味着能获得更好的网络传输效率，并且节省磁盘存储空间。

Kafka 附带了一个叫 DumpLogSegment 的工具，可以用它查看片段的内容。它可以显示每个消息的偏移量、校验和、魔术数字节、消息大小和压缩算法。

:::

【高级】Kafka 如何检索数据？

:::details 要点

Kafka 允许消费者从任意有效的偏移量位置开始读取消息。Kafka 为每个 Partition 都维护了一个索引（即 .index 文件），该索引将偏移量映射到片段文件以及偏移量在文件里的位置。

索引也被分成片段，所以在删除消息时，也可以删除相应的索引。Kafka 不维护索引的校验和。如果索引出现损坏，Kafka 会通过重读消息并录制偏移量和位置来重新生成索引。如果有必要，管理员可以删除索引，这样做是绝对安全的，Kafka 会自动重新生成这些索引。

索引文件用于将偏移量映射成为消息在日志数据文件中的实际物理位置，每个索引条目由 offset 和 position 组成，每个索引条目可以唯一确定在各个分区数据文件的一条消息。其中，Kafka 采用稀疏索引存储的方式，每隔一定的字节数建立了一条索引，可以通过“index.interval.bytes”设置索引的跨度；

有了偏移量索引文件，通过它，Kafka 就能够根据指定的偏移量快速定位到消息的实际物理位置。具体的做法是，根据指定的偏移量，使用二分法查询定位出该偏移量对应的消息所在的分段索引文件和日志数据文件。然后通过二分查找法，继续查找出小于等于指定偏移量的最大偏移量，同时也得出了对应的 position（实际物理位置），根据该物理位置在分段的日志数据文件中顺序扫描查找偏移量与指定偏移量相等的消息。下面是 Kafka 中分段的日志数据文件和偏移量索引文件的对应映射关系图（其中也说明了如何按照起始偏移量来定位到日志数据文件中的具体消息）。

:::

【高级】Kafka 如何清理数据？

:::details 要点

每个日志片段可以分为以下两个部分：

干净的部分：这部分消息之前已经被清理过，每个键只存在一个值。
污浊的部分：在上一次清理后写入的新消息。

如果在 Kafka 启动时启用了清理功能（通过 log.cleaner.enabled 配置），每个 Broker 会启动一个清理管理器线程和若干个清理线程，每个线程负责一个 Partition。

清理线程会读取污浊的部分，并在内存里创建一个 map。map 的 key 是消息键的哈希值，value 是消息的偏移量。对于相同的键，只保留最新的位移。其中 key 的哈希大小为 16 字节，位移大小为 8 个字节。也就是说，一个映射只有 24 字节，假设消息大小为 1KB，那么 1GB 的段有 1 百万条消息，建立这个段的映射只需要 24MB 的内存，映射的内存效率是非常高效的。

在配置 Kafka 时，管理员需要设置这些清理线程可以使用的总内存。如果设置 1GB 的总内存同时有 5 个清理线程，那么每个线程只有 200MB 的内存可用。在清理线程工作时，它不需要把所有脏的段文件都一起在内存中建立上述映射，但需要保证至少能够建立一个段的映射。如果不能同时处理所有脏的段，Kafka 会一次清理最老的几个脏段，然后在下一次再处理其他的脏段。

一旦建立完脏段的键与位移的映射后，清理线程会从最老的干净的段开始处理。如果发现段中的消息的键没有在映射中出现，那么可以知道这个消息是最新的，然后简单的复制到一个新的干净的段中；否则如果消息的键在映射中出现，这条消息需要抛弃，因为对于这个键，已经有新的消息写入。处理完会将产生的新段替代原始段，并处理下一个段。

对于一个段，清理前后的效果如下：

对于只保留最新消息的清理策略来说，Kafka 还支持删除相应键的消息操作（而不仅仅是保留最新的消息内容）。这是通过生产者发送一条特殊的消息来实现的，该消息包含一个键以及一个 null 的消息内容。当清理线程发现这条消息时，它首先仍然进行一个正常的清理并且保留这个包含 null 的特殊消息一段时间，在这段时间内消费者消费者可以获取到这条消息并且知道消息内容已经被删除。过了这段时间，清理线程会删除这条消息，这个键会从 Partition 中消失。这段时间是必须的，因为它可以使得消费者有一定的时间余地来收到这条消息。

:::

生产者

【中级】Kafka 发送消息的工作流程是怎样的？

:::details 要点

Kafka 生产者用一个 ProducerRecord 对象来抽象一条要发送的消息， ProducerRecord 对象需要包含目标主题和要发送的内容，还可以指定键或分区。其发送消息流程如下：

（1）序列化 - 生产者要先把键和值序列化成字节数组，这样它们才能够在网络中传输。

（2）分区 - 数据被传给分区器。如果在 ProducerRecord 中已经指定了分区，那么分区器什么也不会做；否则，分区器会根据 ProducerRecord 的键来选择一个分区。选定分区后，生产者就知道该把消息发送给哪个主题的哪个分区。

（3）批次传输 - 接着，这条记录会被添加到一个记录批次中。这个批次中的所有消息都会被发送到相同的主题和分区上。有一个独立的线程负责将这些记录批次发送到相应 Broker 上。

批次，就是一组消息，这些消息属于同一个主题和分区。
发送时，会把消息分成批次传输，如果每次只发送一个消息，会占用大量的网路开销。

（4）响应 - 服务器收到消息会返回一个响应。

如果成功，则返回一个 RecordMetaData 对象，它包含了主题、分区、偏移量；
如果失败，则返回一个错误。生产者在收到错误后，可以进行重试，重试次数可以在配置中指定。失败一定次数后，就返回错误消息。

生产者向 Broker 发送消息时是怎么确定向哪一个 Broker 发送消息？

生产者会向任意 broker 发送一个元数据请求（MetadataRequest），获取到每一个分区对应的 Leader 信息，并缓存到本地。
生产者在发送消息时，会指定 Partition 或者通过 key 得到到一个 Partition，然后根据 Partition 从缓存中获取相应的 Leader 信息。

:::

消费者

【基础】Kafka 为什么要支持消费者群组？

:::details 要点

消费者

每个 Consumer 的唯一元数据是该 Consumer 在日志中消费的位置。这个偏移量是由 Consumer 控制的：Consumer 通常会在读取记录时线性的增加其偏移量。但实际上，由于位置由 Consumer 控制，所以 Consumer 可以采用任何顺序来消费记录。

一条消息只有被提交，才会被消费者获取到。如下图，只能消费 Message0、Message1、Message2：

消费者群组

Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。

Kafka 的写入数据量很庞大，如果只有一个消费者，消费消息速度很慢，时间长了，就会造成数据积压。为了减少数据积压，Kafka 支持消费者群组，可以让多个消费者并发消费消息，对数据进行分流。

Kafka 消费者从属于消费者群组，一个群组里的 Consumer 订阅同一个 Topic，一个主题有多个 Partition，每一个 Partition 只能隶属于消费者群组中的一个 Consumer。

如果超过主题的分区数量，那么有一部分消费者就会被闲置，不会接收到任何消息。

同一时刻，一条消息只能被同一消费者组中的一个消费者实例消费。

不同消费者群组之间互不影响。

:::

【中级】如何消费 Kafka 消息？

:::details 要点

Kafka 消费者通过 pull 模式来获取消息，但是获取消息时并不是立刻返回结果，需要考虑两个因素：

消费者通过 customer.poll(time) 中设置等待时间
Broker 会等待累计一定量数据，然后发送给消费者。这样可以减少网络开销。

pull 除了获取消息外，还有其他作用：

发送心跳信息。消费者通过向被指派为群组协调器的 Broker 发送心跳来维护他和群组的从属关系，当机器宕掉后，群组协调器触发再均衡。

:::

分区

【中级】什么是分区？为什么要分区？

:::details 要点

Kafka 的数据结构采用三级结构，即：主题（Topic）、分区（Partition）、消息（Record）。

在 Kafka 中，任意一个 Topic 维护了一组 Partition 日志，如下所示：

每个 Partition 都是一个单调递增的、不可变的日志记录，以不断追加的方式写入数据。Partition 中的每条记录会被分配一个单调递增的 id 号，称为偏移量（Offset），用于唯一标识 Partition 内的每条记录。

为什么 Kafka 的数据结构采用三级结构？

分区的作用就是提供负载均衡的能力，以实现系统的高伸缩性（Scalability）。

不同的分区能够被放置到不同节点的机器上，而数据的读写操作也都是针对分区这个粒度而进行的，这样每个节点的机器都能独立地执行各自分区的读写请求处理。并且，我们还可以通过添加新的机器节点来增加整体系统的吞吐量。

:::

【中级】Kafka 的分区策略是怎样的？

:::details 要点

所谓分区策略是决定生产者将消息发送到哪个分区的算法，也就是负载均衡算法。

Kafka 生产者发送消息使用的对象 ProducerRecord ，可以选填 Partition 和 Key。不过，大多数应用会用到 key。key 有两个作用：作为消息的附加信息；也可以用来决定消息该被写到 Topic 的哪个 Partition，拥有相同 key 的消息将被写入同一个 Partition。

如果 ProducerRecord 指定了 Partition，则分区器什么也不做，否则分区器会根据 key 选择一个 Partition 。

没有 key 时的分发逻辑：每隔 topic.metadata.refresh.interval.ms 的时间，随机选择一个 partition。这个时间窗口内的所有记录发送到这个 partition。发送数据出错后会重新选择一个 partition。
根据 key 分发：Kafka 的选择分区策略是：根据 key 求 hash 值，然后将 hash 值对 partition 数量求模。这里的关键点在于，同一个 key 总是被映射到同一个 Partition 上。所以，在选择分区时，Kafka 会使用 Topic 的所有 Partition ，而不仅仅是可用的 Partition。这意味着，如果写入数据的 Partition 是不可用的，那么就会出错。

:::

【中级】如何自定义分区策略？

:::details 要点

如果 Kafka 的默认分区策略无法满足实际需要，可以自定义分区策略。需要显式地配置生产者端的参数 partitioner.class。这个参数该怎么设定呢？

首先，要实现 org.apache.kafka.clients.producer.Partitioner 接口。这个接口定义了两个方法：partition 和 close，通常只需要实现最重要的 partition 方法。我们来看看这个方法的方法签名：

1	int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);

这里的 topic、key、keyBytes、value和 valueBytes 都属于消息数据，cluster 则是集群信息（比如当前 Kafka 集群共有多少主题、多少 Broker 等）。Kafka 给你这么多信息，就是希望让你能够充分地利用这些信息对消息进行分区，计算出它要被发送到哪个分区中。

接着，设置 partitioner.class 参数为自定义类的全限定名，那么生产者程序就会按照你的代码逻辑对消息进行分区。

负载均衡算法常见的有：

随机算法
轮询算法
最小活跃数算法
源地址哈希算法

可以根据实际需要去实现。

:::

【高级】Kafka 如何实现分区再均衡？

:::details 要点

什么是分区再均衡

分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为分区再均衡（Rebalance）。Rebalance 实现了消费者群组的高可用性和伸缩性。

Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 Consumer 如何达成一致，来分配订阅 Topic 的每个分区。比如某个 Group 下有 20 个 Consumer 实例，它订阅了一个具有 100 个分区的 Topic。正常情况下，Kafka 平均会为每个 Consumer 分配 5 个分区。这个分配的过程就叫 Rebalance。

当在群组里面新增/移除消费者或者新增/移除 kafka 集群 broker 节点时，群组协调器 Broker 会触发再均衡，重新为每一个 Partition 分配消费者。Rebalance 期间，消费者无法读取消息，造成整个消费者群组一小段时间的不可用。

何时生分区再均衡

分区再均衡的触发时机有三种：

消费者群组成员数发生变更。比如有新的 Consumer 加入群组或者离开群组，或者是有 Consumer 实例崩溃被“踢出”群组。
- 新增消费者。consumer 订阅主题之后，第一次执行 poll 方法
- 移除消费者。执行 consumer.close() 操作或者消费客户端宕机，就不再通过 poll 向群组协调器发送心跳了，当群组协调器检测次消费者没有心跳，就会触发再均衡。
订阅主题数发生变更。Consumer Group 可以使用正则表达式的方式订阅主题，比如 consumer.subscribe(Pattern.compile(“t.*c”)) 就表明该 Group 订阅所有以字母 t 开头、字母 c 结尾的主题。在 Consumer Group 的运行过程中，你新创建了一个满足这样条件的主题，那么该 Group 就会发生 Rebalance。
订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。当分区数增加时，就会触发订阅该主题的所有 Group 开启 Rebalance。
- 新增 broker。如重启 broker 节点
- 移除 broker。如 kill 掉 broker 节点。

分区再均衡的过程

Rebalance 是通过消费者群组中的称为“群主”消费者客户端进行的。

（1）选择群主

所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。具体来讲，Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。

（2）消费者通过向被指派为群组协调器（Coordinator）的 Broker 定期发送心跳来维持它们和群组的从属关系以及它们对分区的所有权。

（3）群主从群组协调器获取群组成员列表，然后给每一个消费者进行分配分区 Partition。有两种分配策略：Range 和 RoundRobin。

Range 策略，就是把若干个连续的分区分配给消费者，如存在分区 1-5，假设有 3 个消费者，则消费者 1 负责分区 1-2,消费者 2 负责分区 3-4，消费者 3 负责分区 5。
RoundRoin 策略，就是把所有分区逐个分给消费者，如存在分区 1-5，假设有 3 个消费者，则分区 1->消费 1，分区 2->消费者 2，分区 3>消费者 3，分区 4>消费者 1，分区 5->消费者 2。

（4）群主分配完成之后，把分配情况发送给群组协调器。

（5）群组协调器再把这些信息发送给消费者。每个消费者只能看到自己的分配信息，只有群主知道所有消费者的分配信息。

如何判定消费者已经死亡

消费者通过向被指定为群组协调器的 Broker 发送心跳来维持它们和群组的从属关系以及它们对分区的所有权关系。只要消费者以正常的时间间隔发送心跳，就被认为是活跃的。消费者会在轮询消息或提交偏移量时发送心跳。如果消费者超时未发送心跳，会话就会过期，群组协调器认定它已经死亡，就会触发一次再均衡。

当一个消费者要离开群组时，会通知协调器，协调器会立即触发一次再均衡，尽量降低处理停顿。

查找协调者

所有 Broker 在启动时，都会创建和开启相应的 Coordinator 组件。也就是说，所有 Broker 都有各自的 Coordinator 组件。那么，Consumer Group 如何确定为它服务的 Coordinator 在哪台 Broker 上呢？答案就在我们之前说过的 Kafka 内部位移主题 __consumer_offsets 身上。

目前，Kafka 为某个 Consumer Group 确定 Coordinator 所在的 Broker 的算法有 2 个步骤。

第 1 步：确定由位移主题的哪个分区来保存该 Group 数据：partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。
第 2 步：找出该分区 Leader 副本所在的 Broker，该 Broker 即为对应的 Coordinator。

:::

【高级】分区再均衡存在什么问题？如何避免分区再均衡？

:::details 要点

分区再均衡的问题

首先，Rebalance 过程对 Consumer Group 消费过程有极大的影响。在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 完成。
其次，目前 Rebalance 的设计是所有 Consumer 实例共同参与，全部重新分配所有分区。其实更高效的做法是尽量减少分配方案的变动。
最后，Rebalance 实在是太慢了。

避免分区再均衡

通过前文，我们已经知道了：分区再均衡的代价很高，应该尽量避免不必要的分区再均衡，以整体提高 Consumer 的吞吐量。

分区再均衡发生的时机有三个：

消费群组成员数量发生变化
订阅主题数量发生变化
订阅主题的分区数发生变化

后面两个通常都是运维的主动操作，所以它们引发的 Rebalance 大都是不可避免的。实际上，大部分情况下，导致分区再均衡的原因是：消费群组成员数量发生变化。

有两种情况，消费者并没有宕机，但也被视为消亡：

未及时发送心跳
Consumer 消费时间过长

未及时发送心跳

第一类非必要 Rebalance 是因为未能及时发送心跳，导致 Consumer 被“踢出”Group 而引发的。因此，需要合理设置会话超时时间。这里给出一些推荐数值，你可以“无脑”地应用在你的生产环境中。

设置 session.timeout.ms = 6s。
设置 session.timeout.ms = 6s。
设置 heartbeat.interval.ms = 2s。
要保证 Consumer 实例在被判定为“dead”之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。

将 session.timeout.ms 设置成 6s 主要是为了让 Coordinator 能够更快地定位已经挂掉的 Consumer。毕竟，我们还是希望能尽快揪出那些“尸位素餐”的 Consumer，早日把它们踢出 Group。希望这份配置能够较好地帮助你规避第一类“不必要”的 Rebalance。

Consumer 消费时间过长

第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。此时，**max.poll.interval.ms** 参数值的设置显得尤为关键。如果要避免非预期的 Rebalance，你最好将该参数值设置得大一点，比你的下游最大处理时间稍长一点。

GC 参数

如果你按照上面的推荐数值恰当地设置了这几个参数，却发现还是出现了 Rebalance，那么我建议你去排查一下 Consumer 端的 GC 表现，比如是否出现了频繁的 Full GC 导致的长时间停顿，从而引发了 Rebalance。为什么特意说 GC？那是因为在实际场景中，我见过太多因为 GC 设置不合理导致程序频发 Full GC 而引发的非预期 Rebalance 了。

:::

复制

【中级】Kafka 如何管理副本？

:::details 要点

副本机制是分布式系统实现高可用的不二法门，Kafka 也不例外。

副本机制有哪些好处？

提供可用性：有句俗语叫：鸡蛋不要放在一个篮子里。副本机制也是一个道理——当部分节点宕机时，系统仍然可以依靠其他正常运转的节点，从整体上对外继续提供服务。
提供伸缩性：通过增加、减少机器可以控制系统整体的吞吐量。
改善数据局部性：允许将数据放入与用户地理位置相近的地方，从而降低系统延时。

但是，Kafka 只实现了第一个好处，原因后面会阐述。

每个 Partition 都有一个 Leader，零个或多个 Follower。
Leader 处理一切对 Partition （分区）的读写请求；而 Follower 只需被动的同步 Leader 上的数据。
同一个 Topic 的不同 Partition 会分布在多个 Broker 上，而且一个 Partition 还会在其他的 Broker 上面进行备份。

Kafka 副本角色

Kafka 使用 Topic 来组织数据，每个 Topic 被分为若干个 Partition，每个 Partition 有多个副本。每个 Broker 可以保存成百上千个属于不同 Topic 和 Partition 的副本。Kafka 副本的本质是一个只能追加写入的提交日志。

Kafka 副本有两种角色：

Leader 副本（主）：每个 Partition 都有且仅有一个 Leader 副本。为了保证数据一致性，Leader 处理一切对 Partition （分区）的读写请求；
Follower 副本（从）：Leader 副本以外的副本都是 Follower 副本。Follower 唯一的任务就是从 Leader 那里复制消息，保持与 Leader 一致的状态。
如果 Leader 宕机，其中一个 Follower 会被选举为新的 Leader。

为了与 Leader 保持同步，Follower 向 Leader 发起获取数据的请求，这种请求与消费者为了读取消息而发送的请求是一样的。请求消息里包含了 Follower 想要获取消息的偏移量，而这些偏移量总是有序的。

Leader 另一个任务是搞清楚哪个 Follower 的状态与自己是一致的。通过查看每个 Follower 请求的最新偏移量，Leader 就会知道每个 Follower 复制的进度。如果跟随者在 10s 内没有请求任何消息，或者虽然在请求消息，但是在 10s 内没有请求最新的数据，那么它就会被认为是不同步的。如果一个副本是不同步的，在 Leader 失效时，就不可能成为新的 Leader——毕竟它没有包含全部的消息。

除了当前首领之外，每个分区都有一个首选首领——创建 Topic 时选定的首领就是分区的首选首领。之所以叫首选 Leader，是因为在创建分区时，需要在 Broker 之间均衡 Leader。

ISR

ISR 即 In-sync Replicas，表示同步副本。Follower 副本不提供服务，只是定期地异步拉取领导者副本中的数据而已。既然是异步的，说明和 Leader 并非数据强一致性的。

判断 Follower 是否与 Leader 同步的标准：

Kafka Broker 端参数 replica.lag.time.max.ms 参数，指定了 Follower 副本能够落后 Leader 副本的最长时间间隔，默认为 10s。这意味着：只要一个 Follower 副本落后 Leader 副本的时间不连续超过 10 秒，那么 Kafka 就认为该 Follower 副本与 Leader 是同步的，即使此时 Follower 副本中保存的消息明显少于 Leader 副本中的消息。

ISR 是一个动态调整的集合，会不断将同步副本加入集合，将不同步副本移除集合。Leader 副本天然就在 ISR 中。

Unclean 领导者选举

因为 Leader 副本天然就在 ISR 中，如果 ISR 为空了，就说明 Leader 副本也“挂掉”了，Kafka 需要重新选举一个新的 Leader。

Kafka 把所有不在 ISR 中的存活副本都称为非同步副本。通常来说，非同步副本落后 Leader 太多，因此，如果选择这些副本作为新 Leader，就可能出现数据的丢失。毕竟，这些副本中保存的消息远远落后于老 Leader 中的消息。在 Kafka 中，选举这种副本的过程称为 Unclean 领导者选举。Broker 端参数 unclean.leader.election.enable 控制是否允许 Unclean 领导者选举。

开启 Unclean 领导者选举可能会造成数据丢失，但好处是：它使得 Partition Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性。反之，禁止 Unclean 领导者选举的好处在于维护了数据的一致性，避免了消息丢失，但牺牲了高可用性。

:::

可靠传输

【高级】如何保证 Kafka 消息不丢失？

:::details 要点

如何保证消息的可靠性传输，或者说，如何保证消息不丢失？这对于任何 MQ 都是核心问题。

一条消息从生产到消费，可以划分三个阶段：

生产阶段：Producer 创建消息，并通过网络发送给 Broker。
存储阶段：Broker 收到消息并存储，如果是集群，还要同步副本给其他 Broker。
消费阶段：Consumer 向 Broker 请求消息，Broker 通过网络传输给 Consumer。

这三个阶段都可能丢失数据，所以要保证消息丢失，就需要任意一环都保证可靠。

存储阶段不丢消息

存储阶段指的是 Kafka Server，也就是 Broker 如何保证消息不丢失。

一句话概括，Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证。

上面的话可以解读为：

已提交：只有当消息被写入分区的若干同步副本时，才被认为是已提交的。为什么是若干个 Broker 呢？这取决于你对“已提交”的定义。你可以选择只要 Leader 成功保存该消息就算是已提交，也可以是令所有 Broker 都成功保存该消息才算是已提交。
持久化：Kafka 的数据存储在磁盘上，所以只要写入成功，天然就是持久化的。
只要还有一个副本是存活的，那么已提交的消息就不会丢失。
消费者只能读取已提交的消息。

Kafka 的副本机制是 kafka 可靠性保证的核心。

Kafka 的主题被分为多个分区，分区是基本的数据块。每个分区可以有多个副本，有一个是 Leader（主副本），其他是 Follower（从副本）。所有数据都直接发送给 Leader，或者直接从 Leader 读取事件。Follower 只需要与 Leader 保持同步，并及时复制最新的数据。当 Leader 宕机时，从 Follower 中选举一个成为新的 Leader。

Broker 有 3 个配置参数会影响 Kafka 消息存储的可靠性。

副本数 - replication.factor 的作用是设置每个分区的副本数。replication.factor 是主题级别配置； default.replication.factor 是 broker 级别配置。副本数越多，数据可靠性越高；但由于副本数增多，也会增加同步副本的开销，可能会降低集群的可用性。一般，建议设为 3，这也是 Kafka 的默认值。
不完全的选主 - unclean.leader.election.enable 用于控制是否支持不同步的副本参与选举 Leader。unclean.leader.election.enable 是 broker 级别（实际上是集群范围内）配置，默认值为 true。
- 如果设为 true，代表着允许不同步的副本成为主副本（即不完全的选举），那么将面临丢失消息的风险；
- 如果设为 false，就要等待原先的主副本重新上线，从而降低了可用性。
最少同步副本 - min.insync.replicas 控制的是消息至少要被写入到多少个副本才算是“已提交”。min.insync.replicas 是主题级别和 broker 级别配置。尽管可以为一个主题配置 3 个副本，但还是可能会出现只有一个同步副本的情况。如果这个同步副本变为不可用，则必须在可用性和数据一致性之间做出选择。Kafka 中，消息只有被写入到所有的同步副本之后才被认为是已提交的。但如果只有一个同步副本，那么在这个副本不可用时，则数据就会丢失。
- 如果要确保已经提交的数据被已写入不止一个副本，就需要把最小同步副本的设置为大一点的值。
- 注意：要确保 replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在不降低可用性的基础上完成。推荐设置成 replication.factor = min.insync.replicas + 1。

生产阶段不丢消息

在生产消息阶段，消息队列一般通过请求确认机制，来保证消息的可靠传递，Kafka 也不例外。

Kafka 有三种发送方式：同步、异步、异步回调。同步方式能保证消息不丢失，但性能太差；异步方式发送消息，通常会立即返回，但消息可能丢失。

解决生产者丢失消息的方案：

生产者使用异步回调方式 producer.send(msg, callback) 发送消息。callback（回调）能准确地告诉你消息是否真的提交成功了。一旦出现消息提交失败的情况，你就可以有针对性地进行处理。

如果是因为那些瞬时错误，那么仅仅让 Producer 重试就可以了；
如果是消息不合格造成的，那么可以调整消息格式后再次发送。

然后，需要基于以下几点来保证 Kafka 生产者的可靠性：

ACK - 生产者可选的确认模式有三种：acks=0、acks=1、acks=all。
- acks=0、acks=1 都有丢失数据的风险。
- acks=all 意味着会等待所有同步副本都收到消息。再结合 min.insync.replicas ，就可以决定在得到确认响应前，至少有多少副本能够收到消息。这是最保险的做法，但也会降低吞吐量。
重试 - 如果 broker 返回的错误可以通过重试来解决，生产者会自动处理这些错误。需要注意的是：有时可能因为网络问题导致没有收到确认，但实际上消息已经写入成功。生产者会认为出现临时故障，重试发送消息，这样就会出现重复记录。所以，尽可能在业务上保证幂等性。设置 retries 为一个较大的值。这里的 retries 同样是 Producer 的参数，对应前面提到的 Producer 自动重试。当出现网络的瞬时抖动时，消息发送可能会失败，此时配置了 retries > 0 的 Producer 能够自动重试消息发送，避免消息丢失。
- 可重试错误，如：LEADER_NOT_AVAILABLE，主副本不可用，可能过一段时间，集群就会选举出新的主副本，重试可以解决问题。
- 不可重试错误，如：INVALID_CONFIG，即使重试，也无法改变配置选项，重试没有意义。
错误处理 - 开发者需要自行处理的错误：
- 不可重试的 broker 错误，如消息大小错误、认证错误等；
- 消息发送前发生的错误，如序列化错误；
- 生产者达到重试次数上限或消息占用的内存达到上限时发生的错误。

消费阶段不丢消息

前文已经提到，消费者只能读取已提交的消息。这就保证了消费者接收到消息时已经具备了数据一致性。

消费者唯一要做的是确保哪些消息是已经读取过的，哪些是没有读取过的（通过提交偏移量给 Broker 来确认）。如果消费者提交了偏移量却未能处理完消息，那么就有可能造成消息丢失，这也是消费者丢失消息的主要原因。

消费者的可靠性配置：

group.id - 如果希望消费者可以看到主题的所有消息，那么需要为它们设置唯一的 group.id。
auto.offset.reset - 有两个选项：
- earliest - 消费者会从分区的开始位置读取数据
- latest - 消费者会从分区末尾位置读取数据
enable.auto.commit - 消费者自动提交偏移量。如果设为 true，处理流程更简单，但无法保证重复处理消息。
auto.commit.interval.ms - 自动提交的频率，默认为每 5 秒提交一次。

如果 enable.auto.commit 设为 true，即自动提交，就无需考虑提交偏移量的问题。

如果选择显示提交偏移量，需要考虑以下问题：

必须在处理完消息后再发送确认（提交偏移量），不要收到消息立即确认。
提交频率是性能和重复消息数之间的权衡
分区再均衡
消费可能需要重试机制
超时处理
消费者可能需要维护消费状态，如：处理完消息后，记录在数据库中。
幂等性设计
- 写数据库：根据主键判断记录是否存在
- 写 Redis：set 操作天然具有幂等性
- 复杂的逻辑处理，则可以在消息中加入全局 ID

:::

【高级】如何保证 Kafka 消息不重复？

:::details 要点

在 MQTT 协议中，给出了三种传递消息时能够提供的服务质量标准，这三种服务质量从低到高依次是：

At most once：至多一次。消息在传递时，最多会被送达一次。换一个说法就是，没什么消息可靠性保证，允许丢消息。一般都是一些对消息可靠性要求不太高的监控场景使用，比如每分钟上报一次机房温度数据，可以接受数据少量丢失。
At least once: 至少一次。消息在传递时，至少会被送达一次。也就是说，不允许丢消息，但是允许有少量重复消息出现。
Exactly once：恰好一次。消息在传递时，只会被送达一次，不允许丢失也不允许重复，这个是最高的等级。

绝大部分消息队列提供的服务质量都是 At least once，包括 RocketMQ、RabbitMQ 和 Kafka 都是这样。也就是说，消息队列很难保证消息不重复。

一般解决重复消息的办法是，在消费端，保证消费消息的操作具备幂等性。

幂等（idempotent、idempotence）是一个数学与计算机学概念，指的是：一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。

常用的实现幂等操作的方法：

利用数据库的唯一约束实现幂等 - 关系型数据库可以使用 INSERT IF NOT EXIST 语句防止重复；Redis 可以使用 SETNX 命令来防止重复；其他数据库只要支持类似语义，也是一个道理。
为更新的数据设置前置条件 - 如果满足条件就更新数据，否则拒绝更新数据，在更新数据的时候，同时变更前置条件中需要判断的数据。这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作。但是，如果我们要更新的数据不是数值，或者我们要做一个比较复杂的更新操作怎么办？用什么作为前置判断条件呢？更加通用的方法是，给数据增加一个版本号属性，每次更数据前，比较当前数据的版本号是否和消息中的版本号一致，如果不一致就拒绝更新数据，更新数据的同时将版本号 +1，一样可以实现幂等更新。
记录并检查操作- 也称为“Token 机制或者 GUID（全局唯一 ID）机制”，通用性最强，适用范围最广。实现的思路特别简单，在执行数据更新操作之前，先检查一下是否执行过这个更新操作。
- 具体的实现方法是，在发送消息时，给每条消息指定一个全局唯一的 ID，消费时，先根据这个 ID 检查这条消息是否有被消费过，如果没有消费过，才更新数据，然后将消费状态置为已消费。
- 需要注意的是，“检查消费状态，然后更新数据并且设置消费状态”中，三个操作必须作为一组操作保证原子性，才能真正实现幂等，否则就会出现 Bug。这一组操作可以通过分布式事务或分布式锁来保证其原子性。

:::

【高级】如何保证 Kafka 消息有序？

:::details 要点

某些场景下，可能会要求按序发送消息。

方案一、单 Partition

Kafka 每一个 Partition 只能隶属于消费者群组中的一个 Consumer，换句话说，每个 Partition 只能被一个 Consumer 消费。所以，如果 Topic 是单 Partition，自然是有序的。

方案分析

优点：简单粗暴。开发者什么也不用做。

缺点：Kafka 基于 Partition 实现其高并发能力，如果使用单 Partition，会严重限制 Kafka 的吞吐量。

结论：作为分布式消息引擎，限制并发能力，显然等同于自废武功，所以，这个方案几乎是不可接受的。

方案二、同一个 key 的消息发送给指定 Partition

（1）生产者端显示指定 key 发往一个指定的 Partition，就可以保证同一个 key 在这个 Partition 中是有序的。

（2）接下来，消费者端为每个 key 设定一个缓存队列，然后让一个独立线程负责消费指定 key 的队列，这就保证了消费消息也是有序的。

:::

【高级】如何应对 Kafka 消息积压？

:::details 要点

先修复消费者，然后停掉当前所有消费者。

新建 Topic，扩大分区，以提高并发处理能力。

创建临时消费者程序，并部署在多节点上，扩大消费处理能力。

最后处理完积压消息后，恢复原先部署架构。

:::

事务

【中级】Kafka 是否支持事务？如何支持事务？

:::details 要点

Kafka 的事务概念是指一系列的生产者生产消息和消费者提交偏移量的操作在一个事务，或者说是是一个原子操作），同时成功或者失败。

消息可靠性保障，由低到高为：

最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。
至少一次（at least once）：消息不会丢失，但有可能被重复发送。
精确一次（exactly once）：消息不会丢失，也不会被重复发送。

Kafka 支持事务功能主要是为了实现精确一次处理语义的，而精确一次处理是实现流处理的基石。

Kafka 自 0.11 版本开始提供了对事务的支持，目前主要是在 read committed 隔离级别上做事情。它能保证多条消息原子性地写入到目标分区，同时也能保证 Consumer 只能看到事务成功提交的消息。

事务型 Producer

事务型 Producer 能够保证将消息原子性地写入到多个分区中。这批消息要么全部写入成功，要么全部失败。另外，事务型 Producer 也不惧进程的重启。Producer 重启回来后，Kafka 依然保证它们发送消息的精确一次处理。

事务属性实现前提是幂等性，即在配置事务属性 transaction.id 时，必须还得配置幂等性；但是幂等性是可以独立使用的，不需要依赖事务属性。

在事务属性之前先引入了生产者幂等性，它的作用为：

生产者多次发送消息可以封装成一个原子操作，要么都成功，要么失败。
consumer-transform-producer 模式下，因为消费者提交偏移量出现问题，导致重复消费。需要将这个模式下消费者提交偏移量操作和生产者一系列生成消息的操作封装成一个原子操作。

消费者提交偏移量导致重复消费消息的场景：消费者在消费消息完成提交便宜量 o2 之前挂掉了（假设它最近提交的偏移量是 o1），此时执行再均衡时，其它消费者会重复消费消息(o1 到 o2 之间的消息）。

Kafka 事务相关配置

使用 kafka 的事务 api 时的一些注意事项：

需要消费者的自动模式设置为 false，并且不能子再手动的进行执行 consumer#commitSync 或者 consumer#commitAsyc
设置 Producer 端参数 transctional.id。最好为其设置一个有意义的名字。
和幂等性 Producer 一样，开启 enable.idempotence = true。如果配置了 transaction.id，则此时 enable.idempotence 会被设置为 true
消费者需要配置事务隔离级别 isolation.level。在 consume-trnasform-produce 模式下使用事务时，必须设置为 READ_COMMITTED。
- read_uncommitted：这是默认值，表明 Consumer 能够读取到 Kafka 写入的任何消息，不论事务型 Producer 提交事务还是终止事务，其写入的消息都可以读取。很显然，如果你用了事务型 Producer，那么对应的 Consumer 就不要使用这个值。
- read_committed：表明 Consumer 只会读取事务型 Producer 成功提交事务写入的消息。当然了，它也能看到非事务型 Producer 写入的所有消息。

:::

架构

【高级】Kafka 的数据存储在磁盘上，为什么还能这么快？

:::details 要点

说 Kafka 很快时，他们通常指的是 Kafka 高效移动大量数据的能力。

Kafka 为了提高传输效率，做了很多精妙的设计。

核心设计：

顺序 I/O - 磁盘读写有两种方式：顺序读写或者随机读写。在顺序读写的情况下，磁盘的顺序读写速度和内存接近。因为磁盘是机械结构，每次读写都会寻址写入，其中寻址是一个“机械动作”。Kafka 利用了一种分段式的、只追加 (Append-Only) 的日志，基本上把自身的读写操作限制为顺序 I/O，也就使得它在各种存储介质上能有很快的速度。
零拷贝 - Kafka 数据传输是一个从网络到磁盘，再由磁盘到网络的过程。在网络和磁盘之间传输数据时，消除多余的复制是提高效率的关键。Kafka 利用零拷贝技术来消除传输过程中的多余复制。
- 如果不采用零拷贝，Kafka 将数据同步给消费者的大致流程是：
  1. 从磁盘加载数据到 os buffer
  2. 拷贝数据到 app buffer
  3. 再拷贝数据到 socket buffer
  4. 接下来，将数据拷贝到网卡 buffer
  5. 最后，通过网络传输，将数据发送到消费者
- 采用零拷贝技术，Kafka 使用 sendfile() 系统方法，将数据从 os buffer 直接复制到网卡 buffer。这个过程中，唯一一次复制数据是从 os buffer 到网卡 buffer。这个复制过程是通过 DMA（Direct Memory Access，直接内存访问）完成的。使用 DMA 时，CPU 不参与，这使得它非常高效。

其他设计：

页缓存 - Kafka 的数据并不是实时的写入磁盘，它充分利用了现代操作系统分页存储来利用内存提高 I/O 效率。具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问。Kafka 接收来自 socket buffer 的网络数据，应用进程不需要中间处理、直接进行持久化时。可以使用 mmap 内存文件映射。
压缩 - Kafka 内置了几种压缩算法，并允许定制化压缩算法。通过压缩算法，可以有效减少传输数据的大小，从而提升传输效率。
批处理 - Kafka 的 Clients 和 Brokers 会把多条读写的日志记录合并成一个批次，然后才通过网络发送出去。日志记录的批处理通过使用更大的包以及提高带宽效率来摊薄网络往返的开销。
分区 - Kafka 将 Topic 分区，每个分区对应一个名为的 Log 的磁盘目录，而 Log 又根据大小，可以分为多个 Log Segment 文件。这种分而治之的策略，使得 Kafka 可以并发读，以支撑非常高的吞吐量。此外，Kafka 支持负载均衡机制，将数据分区近似均匀地分配给消费者群组的各个消费者。

:::

参考资料

聊聊 Kafka： Kafka 为啥这么快？

RPC 面试

发表于 2025-01-22 更新于 2025-04-01 分类于分布式，分布式通信， RPC 本文字数： 15k 阅读时长 ≈ 13 分钟

RPC 面试

RPC 简介

【基础】什么是 RPC？RPC 有什么用？

:::details 要点

RPC 的全称是 Remote Procedure Call，即远程过程调用。

RPC 的主要作用是：

屏蔽远程调用跟本地调用的差异，让用户像调用本地一样去调用远程方法。
隐藏底层网络通信的复杂性，让用户更聚焦于业务逻辑。

RPC 是微服务架构的基石，它提供了一种应用间通信的方式。

:::

【中级】RPC 是怎样工作的？

:::details 要点

RPC 是一种应用间通信的方式，它的通信流程中需要注意以下环节：

传输方式：RPC 是一个远程调用，因此必然需要通过网络传输数据，且 RPC 常用于业务系统之间的数据交互，需要保证其可靠性，所以 RPC 一般默认采用 TCP 来传输。
序列化：在网络中传输的数据只能是二进制数据，而 RPC 请求时，发送的都是对象。因此，请求方需要将请求参数转为二进制数据，即序列化。
反序列化：RPC 响应方接受到请求，要将二进制数据转换为请求参数，需要反序列化。
协议：请求方和响应方要互相识别彼此的信息，需要约定好彼此数据的格式，即协议。大多数的协议至少分成两部分，分别是数据头和消息体。数据头一般用于身份识别，包括协议标识、数据大小、请求类型、序列化类型等信息；消息体主要是请求的业务参数信息和扩展属性等。
动态代理：为了屏蔽底层通信细节，使用户聚焦自身业务，因此 RPC 框架一般引入了动态代理，通过依赖注入等技术，拦截方法调用，完成远程调用的通信逻辑。

服务消费方（client）调用以本地调用方式调用服务；
client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
client stub 找到服务地址，并将消息发送到服务端；
server stub 收到消息后进行解码；
server stub 根据解码结果调用本地的服务；
本地服务执行并将结果返回给 server stub；
server stub 将返回结果打包成消息并发送至消费方；
client stub 接收到消息，并进行解码；
服务消费方得到最终结果。

:::

协议

【中级】为何需要 RPC 协议？

:::details 要点

只有二进制才能在网络中传输，所以 RPC 请求需要把方法调用的请求参数先转成二进制，然后再通过网络传输。

传输的数据可能很大，RPC 请求需要将数据分解为多个数据包；传输的数据也可能较小，需要和其他请求的数据包进行合并。当接收方收到请求时，需要从二进制数据中识别出不同的请求。问题是，如何从二进制数据中识别出其所属的请求呢？

这就需要发送方、接收方在通信过程中达成共识，严格按照协议处理二进制数据。这就好比让你读一篇没有标点符号的文章，你要怎么识别出每一句话到哪里结束呢？很简单啊，我们加上标点，完成断句就好了。这里有个潜在的含义，写文章和读文章的人，都遵循标点符号的用法。

再进一步探讨，既然已经有很多成熟的网络协议，为何还要设计 RPC 协议？

有必要。因为 HTTP 这些通信标准协议，数据包中的实际请求数据相对于数据包本身要小很多，有很多无用的内容；并且 HTTP 属于无状态协议，无法将请求和响应关联，每次请求要重新建立连接。这对于高性能的 RPC 来说，HTTP 协议难以满足需求，所以有必要设计一个紧凑的私有协议。

:::

【中级】设计一个 RPC 协议的要点？

:::details 要点

首先，必须先明确消息的边界，即确定消息的长度。因此，至少要分为：消息长度+消息内容两部分。

接下来，我们会发现，在使用过程中，仅消息长度，不足以明确通信中的很多细节：如序列化方式是怎样的？是否消息压缩？压缩格式是怎样的？如果协议发生变化，需要明确协议版本等等。

大多数的协议会分成两部分，分别是数据头和消息体。数据头一般用于身份识别，包括协议标识、数据大小、请求类型、序列化类型等信息；消息体主要是请求的业务参数信息和扩展属性等。

综上，一个 RPC 协议大概会由下图中的这些参数组成：

前面所述的协议属于定长协议头，那也就是说往后就不能再往协议头里加新参数了，如果加参数就会导致线上兼容问题。

为了保证能平滑地升级改造前后的协议，我们有必要设计一种支持可扩展的协议。其关键在于让协议头支持可扩展，扩展后协议头的长度就不能定长了。那要实现读取不定长的协议头里面的内容，在这之前肯定需要一个固定的地方读取长度，所以我们需要一个固定的写入协议头的长度。整体协议就变成了三部分内容：固定部分、协议头内容、协议体内容。

:::

序列化

【基础】什么是序列化？有哪些常见的序列化方式？

:::details 要点

由于，网络传输的数据必须是二进制数据，而调用方请求的出参、入参都是对象。因此，必须将对象转换可传输的二进制，并且要求转换算法是可逆的。

序列化（serialize）：序列化是将对象转换为二进制数据。
反序列化（deserialize）：反序列化是将二进制数据转换为对象。

Java 领域，常见的序列化技术如下

JDK 序列化：JDK 内置的二进制序列化方式
其他二进制序列化
- Thrift
- Protobuf
- Hessian
JSON 序列化
- Jackson
- Gson
- Fastjson

市面上有如此多的序列化技术，那么我们在应用时如何选择呢?

一般而言，序列化技术选型需要考量的维度，根据重要性从高到低，依次有：

安全性：是否存在漏洞。如果存在漏洞，就有被攻击的可能性。
兼容性：版本升级后的兼容性是否很好，是否支持更多的对象类型，是否是跨平台、跨语言的。服务调用的稳定性与可靠性，要比服务的性能更加重要。
性能
- 时间开销：序列化、反序列化的耗时性能自然越小越好。
- 空间开销：序列化后的数据越小越好，这样网络传输效率就高。
易用性：类库是否轻量化，API 是否简单易懂。

鉴于以上的考量，序列化技术的选型建议如下：

JDK 序列化：性能较差，且有很多使用限制，不建议使用。
Thrift、Protobuf：适用于对性能敏感，对开发体验要求不高。
Hessian：适用于对开发体验敏感，性能有要求。
Jackson、Gson、Fastjson：适用于对序列化后的数据要求有良好的可读性（转为 json 、xml 形式）。

扩展阅读：深入理解 Java 序列化

:::

【基础】序列化的使用中需要注意哪些问题？

:::details 要点

由于 RPC 每次通信，都要经过序列化、反序列化的过程，所以序列化方式，会直接影响 RPC 通信的性能。除了选择合适的序列化技术，如何合理使用序列化也非常重要。

RPC 序列化常见的使用不当的情况如下：

对象过于复杂、庞大 - 对象过于复杂、庞大，会降低序列化、反序列化的效率，并增加传输开销，从而导致响应时延增大。
- 过于复杂：存在多层的嵌套，比如 A 对象关联 B 对象，B 对象又聚合 C 对象，C 对象又关联聚合很多其他对象
- 过于庞大：比如一个大 List 或者大 Map
对象有复杂的继承关系 - 对象关系越复杂，就越浪费性能，同时又很容易出现序列化上的问题。大多数序列化框架在进行序列化时，如果发现类有继承关系，会不停地寻找父类，遍历属性。
使用序列化框架不支持的类作为入参类 - 比如 Hessian 框架，他天然是不支持 LinkHashMap、LinkedHashSet 等，而且大多数情况下最好不要使用第三方集合类，如 Guava 中的集合类，很多开源的序列化框架都是优先支持编程语言原生的对象。因此如果入参是集合类，应尽量选用原生的、最为常用的集合类，如 HashMap、ArrayList。

前面已经列举了常见的序列化问题，既然明确了问题，就要针对性预防。RPC 序列化时要注意以下几点：

对象要尽量简单，没有太多的依赖关系，属性不要太多，尽量高内聚；
入参对象与返回值对象体积不要太大，更不要传太大的集合；
尽量使用简单的、常用的、开发语言原生的对象，尤其是集合类；
对象不要有复杂的继承关系，最好不要有父子类的情况。

:::

通信

【中级】RPC 在网络通信上倾向选择哪种网络 IO 模型？

:::details 要点

一次 RPC 调用，本质就是服务消费者与服务提供者间的一次网络信息交换的过程。可见，通信是 RPC 实现的核心。

常见的网络 IO 模型分为四种：同步阻塞 IO（BIO）、同步非阻塞 IO（NIO）、IO 多路复用和异步非阻塞 IO（AIO）。在这四种 IO 模型中，只有 AIO 为异步 IO，其他都是同步 IO。

什么是 IO 多路复用？字面上的理解，多路就是指多个通道，也就是多个网络连接的 IO，而复用就是指多个通道复用在一个复用器上。IO 多路复用（Reactor 模式）在高并发场景下使用最为广泛，很多知名软件都应用了这一技术，如：Netty、Redis、Nginx 等。

RPC 调用在大多数的情况下，是一个高并发调用的场景，考虑到系统内核的支持、编程语言的支持以及 IO 模型本身的特点，在 RPC 框架的实现中，在网络通信的处理上，通常会选择 IO 多路复用的方式。开发语言的网络通信框架的选型上，最优的选择是基于 Reactor 模式实现的框架，如 Java 语言，首选的框架便是 Netty 框架（Java 还有很多其他 NIO 框架，但目前 Netty 应用得最为广泛），并且在 Linux 环境下，也要开启 epoll 来提升系统性能（Windows 环境下是无法开启 epoll 的，因为系统内核不支持）。

:::

【高级】什么是零拷贝？

:::details 要点

系统内核处理 IO 操作分为两个阶段——等待数据和拷贝数据。等待数据，就是系统内核在等待网卡接收到数据后，把数据写到内核中；而拷贝数据，就是系统内核在获取到数据后，将数据拷贝到用户进程的空间中。

应用进程的每一次写操作，都会把数据写到用户空间的缓冲区中，再由 CPU 将数据拷贝到系统内核的缓冲区中，之后再由 DMA 将这份数据拷贝到网卡中，最后由网卡发送出去。这里我们可以看到，一次写操作数据要拷贝两次才能通过网卡发送出去，而用户进程的读操作则是将整个流程反过来，数据同样会拷贝两次才能让应用程序读取到数据。

应用进程的一次完整的读写操作，都需要在用户空间与内核空间中来回拷贝，并且每一次拷贝，都需要 CPU 进行一次上下文切换（由用户进程切换到系统内核，或由系统内核切换到用户进程），这样很浪费 CPU 和性能。

所谓的零拷贝，就是取消用户空间与内核空间之间的数据拷贝操作，应用进程每一次的读写操作，可以通过一种方式，直接将数据写入内核或从内核中读取数据，再通过 DMA 将内核中的数据拷贝到网卡，或将网卡中的数据 copy 到内核。

Netty 的零拷贝偏向于用户空间中对数据操作的优化，这对处理 TCP 传输中的拆包粘包问题有着重要的意义，对应用程序处理请求数据与返回数据也有重要的意义。

Netty 框架中很多内部的 ChannelHandler 实现类，都是通过 CompositeByteBuf、slice、wrap 操作来处理 TCP 传输中的拆包与粘包问题的。

Netty 的 ByteBuffer 可以采用 Direct Buffers，使用堆外直接内存进行 Socketd 的读写操作，最终的效果与我刚才讲解的虚拟内存所实现的效果是一样的。

Netty 还提供 FileRegion 中包装 NIO 的 FileChannel.transferTo() 方法实现了零拷贝，这与 Linux 中的 sendfile 方式在原理上也是一样的。

扩展阅读：深入剖析Linux IO原理和几种零拷贝机制的实现

:::

动态代理

【中级】RPC 如何将远程调用转为本地调用的？

:::details 要点

RPC 的远程过程调用是通过动态代理实现的。

RPC 框架会自动为要调用的接口生成一个代理类。当在项目中注入接口的时候，运行过程中实际绑定的就是这个接口生成的代理类。在接口方法被调用时，会被代理类拦截，这样，就可以在生成的代理类中，加入远程调用逻辑。

除了 JDK 默认的 InvocationHandler 能完成代理功能，还有很多其他的第三方框架也可以，比如像 Javassist、Byte Buddy 这样的框架。

单纯从代理功能上来看，JDK 默认的代理功能是有一定的局限性的，它要求被代理的类只能是接口。原因是因为生成的代理类会继承 Proxy 类，但 Java 是不支持多重继承的。此外，由于它生成后的代理类是使用反射来完成方法调用的，而这种方式相对直接用编码调用来说，性能会降低。

反射+动态代理更多详情可以参考：深入理解 Java 反射和动态代理

:::

服务发现

【中级】如何实现服务发现？

:::details 要点

RPC 框架必须要有服务注册和发现机制，这样，集群中的节点才能知道通信方的请求地址。

服务注册：在服务提供方启动的时候，将对外暴露的接口注册到注册中心之中，注册中心将这个服务节点的 IP 和接口保存下来。
服务订阅：在服务调用方启动的时候，去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，并用于后续的远程调用。

基于 ZooKeeper 的服务发现

使用 ZooKeeper 作为服务注册中心，是 Java 分布式系统的经典方案。

搭建一个 ZooKeeper 集群作为注册中心集群，服务注册的时候只需要服务节点向 ZooKeeper 节点写入注册信息即可，利用 ZooKeeper 的 Watcher 机制完成服务订阅与服务下发功能。

通常我们可以使用 ZooKeeper、etcd 或者分布式缓存（如 Hazelcast）来解决事件通知问题，但当集群达到一定规模之后，依赖的 ZooKeeper 集群、etcd 集群可能就不稳定了，无法满足我们的需求。

在超大规模的服务集群下，注册中心所面临的挑战就是超大批量服务节点同时上下线，注册中心集群接受到大量服务变更请求，集群间各节点间需要同步大量服务节点数据，最终导致如下问题：

注册中心负载过高；
各节点数据不一致；
服务下发不及时或下发错误的服务节点列表。

RPC 框架依赖的注册中心的服务数据的一致性其实并不需要满足 CP，只要满足 AP 即可。

:::

负载均衡

【中级】负载均衡有哪些策略？

负载均衡详情可以参考：负载均衡基本原理

【中级】如何设计自适应的负载均衡？

:::details 要点

可以采用一种打分的策略，服务调用者收集与之建立长连接的每个服务节点的指标数据，如服务节点的负载指标、CPU 核数、内存大小、请求处理的耗时指标（如请求平均耗时、TP99、TP999）、服务节点的状态指标（如正常、亚健康）。通过这些指标，计算出一个分数，比如总分 10 分，如果 CPU 负载达到 70%，就减它 3 分，当然了，减 3 分只是个类比，需要减多少分是需要一个计算策略的。可以为每个指标都设置一个指标权重占比，然后再根据这些指标数据，计算分数。

可以配合随机权重的负载均衡策略去控制，通过最终的指标分数修改服务节点最终的权重。例如给一个服务节点综合打分是 8 分（满分 10 分），服务节点的权重是 100，那么计算后最终权重就是 80（100*80%）。服务调用者发送请求时，会通过随机权重的策略来选择服务节点，那么这个节点接收到的流量就是其他正常节点的 80%（这里假设其他节点默认权重都是 100，且指标正常，打分为 10 分的情况）。

到这儿，一个自适应的负载均衡我们就完成了，整体的设计方案如下图所示：

关键步骤我来解释下：

添加服务指标收集器，并将其作为插件，默认有运行时状态指标收集器、请求耗时指标收集器。
运行时状态指标收集器收集服务节点 CPU 核数、CPU 负载以及内存等指标，在服务调用者与服务提供者的心跳数据中获取。
请求耗时指标收集器收集请求耗时数据，如平均耗时、TP99、TP999 等。
可以配置开启哪些指标收集器，并设置这些参考指标的指标权重，再根据指标数据和指标权重来综合打分。
通过服务节点的综合打分与节点的权重，最终计算出节点的最终权重，之后服务调用者会根据随机权重的策略，来选择服务节点。

:::

路由

【中级】什么是服务路由？有哪些常见的路由规则？

:::details 要点

服务路由是指通过一定的规则从集群中选择合适的节点。

负载均衡的作用和服务路由的功能看上去很近似，二者有什么区别呢？

负载均衡的目标是提供服务分发而不是解决路由问题，常见的静态、动态负载均衡算法也无法实现精细化的路由管理，但是负载均衡也可以简单看做是路由方案的一种。

服务路由通常用于以下场景，目的在于实现流量隔离：

分组调用：一般来讲，为了保证服务的高可用性，实现异地多活的需求，一个服务往往不止部署在一个数据中心，而且出于节省成本等考虑，有些业务可能不仅在私有机房部署，还会采用公有云部署，甚至采用多家公有云部署。服务节点也会按照不同的数据中心分成不同的分组，这时对于服务消费者来说，选择哪一个分组调用，就必须有相应的路由规则。
蓝绿发布：蓝绿发布场景中，一共有两套服务群组：一套是提供旧版功能的服务群组，标记为绿色；另一套是提供新版功能的服务群组，标记为蓝色。两套服务群组都是功能完善的，并且正在运行的系统，只是服务版本和访问流量不同。新版群组（蓝色）通常是为了做内部测试、验收，不对外部用户暴露。
- 如果新版群组（蓝色）运行稳定，并测试、验收通过后，则通过服务路由、负载均衡等手段逐步将外部用户流量导向新版群组（蓝色）。
- 如果新版群组（蓝色）运行不稳定，或测试、验收不通过，则排查、解决问题后，再继续测试、验收。
灰度发布：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行 A/B 测试，即让一部分用户使用特性 A，一部分用户使用特性 B：如果用户对 B 没有什么反对意见，那么逐步扩大发布范围，直到把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。要支持灰度发布，就要求服务能够根据一定的规则，将流量隔离。
流量切换：在业务线上运行过程中，经常会遇到一些不可抗力因素导致业务故障，比如某个机房的光缆被挖断，或者发生着火等事故导致整个机房的服务都不可用。这个时候就需要按照某个指令，能够把原来调用这个机房服务的流量切换到其他正常的机房。
线下测试联调：线下测试时，可能会缺少相应环境。可以将测试应用注册到线上，然后开启路由规则，在本地进行测试。
读写分离。对于大多数互联网业务来说都是读多写少，所以在进行服务部署的时候，可以把读写分开部署，所有写接口可以部署在一起，而读接口部署在另外的节点上。

常见的路由规则有：

条件路由规则 - 条件路由是基于条件表达式的路由规则。各个 RPC 框架的条件路由表达式各不相同。
标签路由规则 - 标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。标签主要是指对服务提供者的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标。一般，动态规则优先级比静态规则更高，当两种规则同时存在且出现冲突时，将以动态规则为准。
脚本路由规则 - 脚本路由是基于脚本语言的路由规则，具有最高的灵活性，常用的脚本语言比如 JavaScript、Groovy、JRuby 等。

:::

监控

【中级】如何实现 RPC 的健康检查？

:::details 要点

使用频率适中的心跳去检测目标机器的健康状态。

健康状态：建立连接成功，并且心跳探活也一直成功；
亚健康状态：建立连接成功，但是心跳请求连续失败；
死亡状态：建立连接失败。

可以使用可用率来作为健康状态的量化标准：

1	可用率 = 一个时间窗口内接口调用成功次数 / 总调用次数

当可用率低于某个比例，就认为这个节点存在问题，把它挪到亚健康列表，这样既考虑了高低频的调用接口，也兼顾了接口响应时间不同的问题。

:::

链路跟踪

分布式链路跟踪就是将一次分布式请求还原为一个完整的调用链路，我们可以在整个调用链路中跟踪到这一次分布式请求的每一个环节的调用情况，比如调用是否成功，返回什么异常，调用的哪个服务节点以及请求耗时等等。

Trace 就是代表整个链路，每次分布式都会产生一个 Trace，每个 Trace 都有它的唯一标识即 TraceId，在分布式链路跟踪系统中，就是通过 TraceId 来区分每个 Trace 的。
Span 就是代表了整个链路中的一段链路，也就是说 Trace 是由多个 Span 组成的。在一个 Trace 下，每个 Span 也都有它的唯一标识 SpanId，而 Span 是存在父子关系的。还是以讲过的例子为例子，在 A->B->C->D 的情况下，在整个调用链中，正常情况下会产生 3 个 Span，分别是 Span1（A->B）、Span2（B->C）、Span3（C->D），这时 Span3 的父 Span 就是 Span2，而 Span2 的父 Span 就是 Span1。

RPC 在整合分布式链路跟踪需要做的最核心的两件事就是“埋点”和“传递”。

我们前面说是因为各子应用、子服务间复杂的依赖关系，所以通过日志难定位问题。那我们就想办法通过日志定位到是哪个子应用的子服务出现问题就行了。

其实，在 RPC 框架打印的异常信息中，是包括定位异常所需要的异常信息的，比如是哪类异常引起的问题（如序列化问题或网络超时问题），是调用端还是服务端出现的异常，调用端与服务端的 IP 是什么，以及服务接口与服务分组都是什么等等。具体如下图所示：

优雅启停

【中级】如何实现 RPC 优雅关闭？

:::details 要点

当服务提供方要上线的时候，一般是通过部署系统完成实例重启。在这个过程中，服务提供方的团队并不会事先告诉调用方他们需要操作哪些机器，从而让调用方去事先切走流量。而对调用方来说，它也无法预测到服务提供方要对哪些机器重启上线，因此负载均衡就有可能把要正在重启的机器选出来，这样就会导致把请求发送到正在重启中的机器里面，从而导致调用方不能拿到正确的响应结果。

在服务重启的时候，对于调用方来说，这时候可能会存在以下几种情况：

调用方发请求前，目标服务已经下线。对于调用方来说，跟目标节点的连接会断开，这时候调用方可以立马感知到，并且在其健康列表里面会把这个节点挪掉，自然也就不会被负载均衡选中。
调用方发请求的时候，目标服务正在关闭，但调用方并不知道它正在关闭，而且两者之间的连接也没断开，所以这个节点还会存在健康列表里面，因此该节点就有一定概率会被负载均衡选中。

当出现第二种情况的时候，调用方业务会受损，如何避免这种问题呢。当服务提供方关闭前，是不是可以先通知注册中心进行下线，然后通过注册中心告诉调用方进行节点摘除？

如上图所示，整个关闭过程中依赖了两次 RPC 调用，一次是服务提供方通知注册中心下线操作，一次是注册中心通知服务调用方下线节点操作。注册中心通知服务调用方都是异步的。服务发现只保证最终一致性，并不保证实时性，所以注册中心在收到服务提供方下线的时候，并不能成功保证把这次要下线的节点推送到所有的调用方。所以这么来看，通过服务发现并不能做到应用无损关闭。

可以这么处理：当服务提供方正在关闭，如果这之后还收到了新的业务请求，服务提供方直接返回一个特定的异常给调用方（比如 ShutdownException）。这个异常就是告诉调用方“我已经收到这个请求了，但是我正在关闭，并没有处理这个请求”，然后调用方收到这个异常响应后，RPC 框架把这个节点从健康列表挪出，并把请求自动重试到其他节点，因为这个请求是没有被服务提供方处理过，所以可以安全地重试到其他节点，这样就可以实现对业务无损。

如何捕获到关闭事件呢？可以通过捕获操作系统的进程信号来获取，在 Java 语言里面，对应的是 Runtime.addShutdownHook 方法，可以注册关闭的钩子。在 RPC 启动的时候，我们提前注册关闭钩子，并在里面添加了两个处理程序，一个负责开启关闭标识，一个负责安全关闭服务对象，服务对象在关闭的时候会通知调用方下线节点。同时需要在我们调用链里面加上挡板处理器，当新的请求来的时候，会判断关闭标识，如果正在关闭，则抛出特定异常。

关闭过程中已经在处理的请求会不会受到影响呢？如果进程结束过快会造成这些请求还没有来得及应答，同时调用方会也会抛出异常。为了尽可能地完成正在处理的请求，首先我们要把这些请求识别出来。可以在服务对象加上引用计数器，每开始处理请求之前加一，完成请求处理减一，通过该计数器我们就可以快速判断是否有正在处理的请求。服务对象在关闭过程中，会拒绝新的请求，同时根据引用计数器等待正在处理的请求全部结束之后才会真正关闭。但考虑到有些业务请求可能处理时间长，或者存在被挂住的情况，为了避免一直等待造成应用无法正常退出，我们可以在整个 ShutdownHook 里面，加上超时时间控制，当超过了指定时间没有结束，则强制退出应用。超时时间我建议可以设定成 10s，基本可以确保请求都处理完了。

:::

【中级】如何实现 RPC 优雅启动？

运行了一段时间后的应用，执行速度会比刚启动的应用更快。这是因为在Java里面，在运行过程中，JVM虚拟机会把高频的代码编译成机器码，被加载过的类也会被缓存到JVM缓存中，再次使用的时候不会触发临时加载，这样就使得“热点”代码的执行不用每次都通过解释，从而提升执行速度。

但是这些“临时数据”，都在应用重启后就消失了。重启后的这些“红利”没有了之后，如果让刚启动的应用就承担像停机前一样的流量，这会使应用在启动之初就处于高负载状态，从而导致调用方过来的请求可能出现大面积超时，进而对线上业务产生损害行为。

启动预热

启动预热，就是让刚启动的服务提供方应用不承担全部的流量，而是让它被调用的次数随着时间的移动慢慢增加，最终让流量缓和地增加到跟已经运行一段时间后的水平一样。如何做到这点呢？

首先，对于调用方来说，我们要知道服务提供方启动的时间。一种是服务提供方在启动的时候，把自己启动的时间告诉注册中心；另外一种就是注册中心收到的服务提供方的请求注册时间。因为整个预热过程的时间是一个粗略值，即使机器之间的日期时间存在1分钟的误差也不影响，并且在真实环境中机器都会默认开启NTP时间同步功能，来保证所有机器时间的一致性。

不管你是选择哪个时间，最终的结果就是，调用方通过服务发现，除了可以拿到IP列表，还可以拿到对应的启动时间。接着，可以利用加权负载均衡算法来分发流量。现在，需要让这个权重变为动态的，并且是随着时间的推移慢慢增加到服务提供方设定的固定值。

通过这个小逻辑的改动，我们就可以保证当服务提供方运行时长小于预热时间时，对服务提供方进行降权，减少被负载均衡选择的概率，避免让应用在启动之初就处于高负载状态，从而实现服务提供方在启动后有一个预热的过程。

延迟暴露

服务提供方应用在没有启动完成的时候，调用方的请求就过来了，而调用方请求过来的原因是，服务提供方应用在启动过程中把解析到的 RPC 服务注册到了注册中心，这就导致在后续加载没有完成的情况下服务提供方的地址就被服务调用方感知到了。

为了解决这个问题，需要在应用启动加载、解析 Bean 的时候，如果遇到了 RPC 服务的 Bean，只先把这个 Bean 注册到 Spring-BeanFactory 里面去，而并不把这个 Bean 对应的接口注册到注册中心，只有等应用启动完成后，才把接口注册到注册中心用于服务发现，从而实现让服务调用方延迟获取到服务提供方地址。

具体如何实现呢？

我们可以在服务提供方应用启动后，接口注册到注册中心前，预留一个 Hook 过程，让用户可以实现可扩展的 Hook 逻辑。用户可以在 Hook 里面模拟调用逻辑，从而使 JVM 指令能够预热起来，并且用户也可以在 Hook 里面事先预加载一些资源，只有等所有的资源都加载完成后，最后才把接口注册到注册中心。

:::

流量回放

架构

【高级】如何设计一个 RPC 框架？

:::details 要点

设计一个 RPC 框架，可以自下而上梳理一下所需要的能力：

通信传输模块：RPC 本质上就是一个远程调用，那肯定就需要通过网络来传输数据。
协议模块：传输的数据如何定义，就需要通过协议和序列化方式来确定。此外，为了减少传输数据的大小，可以加入压缩功能。
代理模块：为了屏蔽用户的感知，让用户更聚焦于自身业务，需要引入动态代理来托管远程调用。

以上，是一个 RPC 框架的基础能力，使用于 P2P 场景。

但是，如果面对集群模式，以上能力就不够了。同一个服务可能有多个提供者。消费者选择调用哪个提供者？消费者怎么找到提供者的访问地址？请求提供者失败了如何处理？这些都依赖于服务治理的能力。

服务治理，需要很多个模块的能力：服务发现、负载均衡、路由、容错、配置挂历等。

具备了这些能力就万事大吉了吗？RPC 框架很难一开始就面面俱到，但作为基础能力，在实际应用中，难免会有定制化的要求。这就要求 RPC 框架具备良好的扩展性。

通常来说，框架软件可以通过 SPI 技术来实现微内核+插件架构。根据依赖倒置原则，框架应该先将每个功能点都抽象成接口，并提供默认实现。然后，利用 SPI 机制，可以动态地为某个接口寻找服务实现。

加上了插件功能之后，我们的RPC框架就包含了两大核心体系——核心功能体系与插件体系，如下图所示：

:::

【高级】如何实现 RPC 异步调用？

:::details 要点

一次 RPC 调用的本质就是调用端向服务端发送一条请求消息，服务端收到消息后进行处理，处理之后响应给调用端一条响应消息，调用端收到响应消息之后再进行处理，最后将最终的返回值返回给动态代理。

对于 RPC 框架，无论是同步调用还是异步调用，调用端的内部实现都是异步的。

调用端发送的每条消息都一个唯一的消息标识，实际上调用端向服务端发送请求消息之前会先创建一个 Future，并会存储这个消息标识与这个 Future 的映射，动态代理所获得的返回值最终就是从这个 Future 中获取的；当收到服务端响应的消息时，调用端会根据响应消息的唯一标识，通过之前存储的映射找到对应的 Future，将结果注入给那个 Future，再进行一系列的处理逻辑，最后动态代理从 Future 中获得到正确的返回值。

所谓的同步调用，不过是 RPC 框架在调用端的处理逻辑中主动执行了这个 Future 的 get 方法，让动态代理等待返回值；而异步调用则是 RPC 框架没有主动执行这个 Future 的 get 方法，用户可以从请求上下文中得到这个 Future，自己决定什么时候执行这个 Future 的 get 方法。

如何做到 RPC 调用全异步？

实现 RPC 调用全异步的方法是让 RPC 框架支持 CompletableFuture。CompletableFuture 是 Java8 原生支持的。如果 RPC 框架能够支持 CompletableFuture，现在发布一个 RPC 服务，服务接口定义的返回值是 CompletableFuture 对象，整个调用过程会分为这样几步：

服务调用方发起 RPC 调用，直接拿到返回值 CompletableFuture 对象，之后就不需要任何额外的与 RPC 框架相关的操作了，直接就可以进行异步处理；
在服务端的业务逻辑中创建一个返回值 CompletableFuture 对象，之后服务端真正的业务逻辑完全可以在一个线程池中异步处理，业务逻辑完成之后再调用这个 CompletableFuture 对象的 complete 方法，完成异步通知；
调用端在收到服务端发送过来的响应之后，RPC 框架再自动地调用调用端拿到的那个返回值 CompletableFuture 对象的 complete 方法，这样一次异步调用就完成了。

通过对 CompletableFuture 的支持，RPC 框架可以真正地做到在调用端与服务端之间完全异步，同时提升了调用端与服务端的两端的单机吞吐量，并且 CompletableFuture 是 Java8 原生支持，业务逻辑中没有任何代码入侵性。

:::

【高级】Dubbo 中的时间轮机制是如何设计的？

:::details 要点

JDK 中定时任务的实现

在很多开源框架中，都需要定时任务的管理功能，例如 ZooKeeper、Netty、Quartz、Kafka 以及 Linux 操作系统。

定时器的本质是设计一种数据结构，能够存储和调度任务集合，而且 deadline 越近的任务拥有更高的优先级。那么定时器如何知道一个任务是否到期了呢？定时器需要通过轮询的方式来实现，每隔一个时间片去检查任务是否到期。

所以定时器的内部结构一般需要一个任务队列和一个异步轮询线程，并且能够提供三种基本操作：

Schedule 新增任务至任务集合；
Cancel 取消某个任务；
Run 执行到期的任务。

JDK 原生提供了三种常用的定时器实现方式，分别为 Timer、DelayedQueue 和 ScheduledThreadPoolExecutor。

JDK 内置的三种实现定时器的方式，实现思路都非常相似，都离不开任务、任务管理、任务调度三个角色。三种定时器新增和取消任务的时间复杂度都是 O(logn)，面对海量任务插入和删除的场景，这三种定时器都会遇到比较严重的性能瓶颈。

对于性能要求较高的场景，一般都会采用时间轮算法来实现定时器。时间轮（Timing Wheel）是 George Varghese 和 Tony Lauck 在 1996 年的论文 Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility 实现的，它在 Linux 内核中使用广泛，是 Linux 内核定时器的实现方法和基础之一。

时间轮的基本原理

时间轮是一种高效的、批量管理定时任务的调度模型。时间轮可以理解为一种环形结构，像钟表一样被分为多个 slot 槽位。每个 slot 代表一个时间段，每个 slot 中可以存放多个任务，使用的是链表结构保存该时间段到期的所有任务。时间轮通过一个时针随着时间一个个 slot 转动，并执行 slot 中的所有到期任务。

图片 22.png

任务是如何添加到时间轮当中的呢？可以根据任务的到期时间进行取模，然后将任务分布到不同的 slot 中。如上图所示，时间轮被划分为 8 个 slot，每个 slot 代表 1s，当前时针指向 2。假如现在需要调度一个 3s 后执行的任务，应该加入 2+3=5 的 slot 中；如果需要调度一个 12s 以后的任务，需要等待时针完整走完一圈 round 零 4 个 slot，需要放入第 (2+12)%8=6 个 slot。

那么当时针走到第 6 个 slot 时，怎么区分每个任务是否需要立即执行，还是需要等待下一圈，甚至更久时间之后执行呢？所以我们需要把 round 信息保存在任务中。例如图中第 6 个 slot 的链表中包含 3 个任务，第一个任务 round=0，需要立即执行；第二个任务 round=1，需要等待 1*8=8s 后执行；第三个任务 round=2，需要等待 2*8=8s 后执行。所以当时针转动到对应 slot 时，只执行 round=0 的任务，slot 中其余任务的 round 应当减 1，等待下一个 round 之后执行。

上面介绍了时间轮算法的基本理论，可以看出时间轮有点类似 HashMap，如果多个任务如果对应同一个 slot，处理冲突的方法采用的是拉链法。在任务数量比较多的场景下，适当增加时间轮的 slot 数量，可以减少时针转动时遍历的任务个数。

时间轮定时器最大的优势就是，任务的新增和取消都是 O(1) 时间复杂度，而且只需要一个线程就可以驱动时间轮进行工作。

:::

【中级】RPC 如何实现那泛化调用？

:::details 要点

在一些特定场景下，需要在没有接口的情况下进行 RPC 调用。例如：

场景一：搭建一个统一的测试平台，可以让各个业务方在测试平台中通过输入接口、分组名、方法名以及参数值，在线测试自己发布的 RPC 服务。

场景二：搭建一个轻量级的服务网关，可以让各个业务方用 HTTP 的方式，通过服务网关调用其它服务。

为了解决这些场景的问题，可以使用泛化调用。

就是 RPC 框架提供统一的泛化调用接口（GenericService），调用端在创建 GenericService 代理时指定真正需要调用的接口的接口名以及分组名，通过调用 GenericService 代理的 $invoke 方法将服务端所需要的所有信息，包括接口名、业务分组名、方法名以及参数信息等封装成请求消息，发送给服务端，实现在没有接口的情况下进行 RPC 调用的功能。

class GenericService {
Object $invoke(String methodName, String[] paramTypes, Object[] params);
CompletableFuture<Object> $asyncInvoke(String methodName, String[] paramTypes
}

而通过泛化调用的方式发起调用，由于调用端没有服务端提供方提供的接口 API，不能正常地进行序列化与反序列化，我们可以为泛化调用提供专属的序列化插件，来解决实际问题。

:::

参考资料

RPC 实战与核心原理

分布式存储面试

发表于 2025-01-07 更新于 2025-04-01 分类于分布式，分布式存储本文字数： 4.4k 阅读时长 ≈ 4 分钟

分布式存储面试

缓存

扩展：

《大型网站技术架构：核心原理与案例分析》

你应该知道的缓存进化史

如何优雅的设计和使用缓存？

理解分布式系统中的缓存架构（上）

缓存那些事

分布式之数据库和缓存双写一致性方案解析

Cache 的基本原理

5 分钟看懂系列：HTTP 缓存机制详解

浏览器缓存看这一篇就够了

【基础】什么是缓存？为什么需要缓存？

:::details 要点

缓存就是数据交换的缓冲区，用于将频繁访问的数据暂存在访问速度快的存储介质。

缓存的本质是一种利用空间换时间的设计：牺牲一定的数据实时性，使得访问更快、更近：

将数据存储到读取速度更快的存储（设备）；
将数据存储到离应用最近的位置；
将数据存储到离用户最近的位置。

缓存是用于存储数据的硬件或软件的组成部分，以使得后续更快访问相应的数据。缓存中的数据可能是提前计算好的结果、数据的副本等。典型的应用场景：有 cpu cache, 磁盘 cache 等。本文中提及到缓存主要是指互联网应用中所使用的缓存组件。

缓存命中率是缓存的重要度量指标，命中率越高越好。

1	缓存命中率 = 从缓存中读取次数 / 总读取次数

:::

【基础】何时需要缓存？

:::details 要点

引入缓存，会增加系统的复杂度，并牺牲一定的数据实时性。所以，引入缓存前，需要先权衡是否值得，考量点如下：

CPU 开销 - 如果应用某个计算需要消耗大量 CPU，可以考虑缓存其计算结果。典型场景：复杂的、频繁调用的正则计算；分布式计算中间状态等。
IO 开销 - 如果数据库连接池比较繁忙，可以考虑缓存其查询结果。

在数据层引入缓存，有以下几个好处：

提升数据读取速度。
提升系统扩展能力，通过扩展缓存，提升系统承载能力。
降低存储成本，Cache+DB 的方式可以承担原有需要多台 DB 才能承担的请求量，节省机器成本。

:::

【中级】缓存有哪些分类？

:::details 要点

缓存从部署角度，可以分为客户端缓存和服务端缓存。

客户端缓存

Http 缓存：HTTP/1.1 中的 Cache-Control、HTTP/1 中的 Expires
浏览器缓存：HTML5 提供的 SessionStorage 和 LocalStorage、Cookie
APP 缓存
- Android
- IOS

服务端缓存

CDN 缓存 - CDN 将数据缓存到离用户物理距离最近的服务器，使得用户可以就近获取请求内容。CDN 一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。
反向代理缓存 - 反向代理（Reverse Proxy）方式是指以代理服务器来接受网络连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给客户端，此时代理服务器对外就表现为一个反向代理服务器。反向代理缓存一般针对的是静态资源，而将动态资源请求转发到应用服务器处理。
数据库缓存 - 数据库（如 Mysql）自身一般也有缓存，但因为命中率和更新频率问题，不推荐使用。
进程内缓存 - 缓存应用字典等常用数据。
分布式缓存 - 缓存数据库中的热点数据。

其中，CDN 缓存、反向代理缓存、数据库缓存一般由专职人员维护（运维、DBA）。

后端开发一般聚焦于进程内缓存、分布式缓存。

:::

【中级】CDN 缓存是如何工作的？

:::details 要点

CDN 将数据缓存到离用户物理距离最近的服务器，使得用户可以就近获取请求内容。CDN 一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。

国内网络异常复杂，跨运营商的网络访问会很慢。为了解决跨运营商或各地用户访问问题，可以在重要的城市，部署 CDN 应用。使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

CDN 缓存原理

CDN 的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

（1）未部署 CDN 应用前的网络路径：

请求：本机网络（局域网）=> 运营商网络 => 应用服务器机房
响应：应用服务器机房 => 运营商网络 => 本机网络（局域网）

在不考虑复杂网络的情况下，从请求到响应需要经过 3 个节点，6 个步骤完成一次用户访问操作。

（2）部署 CDN 应用后网络路径：

请求：本机网络（局域网） => 运营商网络
响应：运营商网络 => 本机网络（局域网）

在不考虑复杂网络的情况下，从请求到响应需要经过 2 个节点，2 个步骤完成一次用户访问操作。

与不部署 CDN 服务相比，减少了 1 个节点，4 个步骤的访问。极大的提高了系统的响应速度。

CDN 特点

优点

本地 Cache 加速 - 提升访问速度，尤其含有大量图片和静态页面站点；
实现跨运营商的网络加速 - 消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量；
远程加速 - 远程访问用户根据 DNS 负载均衡技术智能自动选择 Cache 服务器，选择最快的 Cache 服务器，加快远程访问的速度；
带宽优化 - 自动生成服务器的远程 Mirror（镜像）cache 服务器，远程用户访问时从 cache 服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点 WEB 服务器负载等功能。
集群抗攻击 - 广泛分布的 CDN 节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种 D.D.o.S 攻击对网站的影响，同时保证较好的服务质量。

缺点

不适宜缓存动态资源
- 解决方案：主要缓存静态资源，动态资源建立多级缓存或准实时同步；
存在数据的一致性问题
- 解决方案（主要是在性能和数据一致性二者间寻找一个平衡）
- 设置缓存失效时间（1 个小时，过期后同步数据）。
- 针对资源设置版本号。

:::

【中级】反向代理缓存是如何工作的？

:::details 要点

反向代理（Reverse Proxy）方式是指以代理服务器来接受网络连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给客户端，此时代理服务器对外就表现为一个反向代理服务器。

反向代理位于应用服务器同一网络，处理所有对 WEB 服务器的请求。

反向代理缓存的原理：

如果用户请求的页面在代理服务器上有缓存的话，代理服务器直接将缓存内容发送给用户。
如果没有缓存则先向 WEB 服务器发出请求，取回数据，本地缓存后再发送给用户。

这种方式通过降低向 WEB 服务器的请求数，从而降低了 WEB 服务器的负载。

反向代理缓存一般针对的是静态资源，而将动态资源请求转发到应用服务器处理。常用的缓存应用服务器有 Varnish，Ngnix，Squid。

:::

【中级】缓存有哪些淘汰算法？

扩展：

Cache Replacement Policies - RR, FIFO, LIFO, & Optimal

Cache Replacement Policies - MRU, LRU, Pseudo-LRU, & LFU

:::details 要点

缓存一般存于访问速度较快的存储介质，快也就意味着资源昂贵并且有限。正所谓，好钢要用在刀刃上。因此，缓存要合理利用，需要设定一些机制，将一些访问频率偏低或过期的数据淘汰。

淘汰缓存首先要做的是，确定什么时候触发淘汰缓存，一般有以下几个思路：

基于空间 - 设置缓存空间大小。
基于容量 - 设置缓存存储记录数。
基于时间
- TTL（Time To Live，即存活期） - 缓存数据从创建到过期的时间。
- TTI（Time To Idle，即空闲期） - 缓存数据多久没被访问的时间。

接下来，就要确定如何淘汰缓存，常见的缓存淘汰算法有以下几个：

FIFO（First In First Out，先进先出） - 淘汰最先进入的缓存数据。缓存的行为就像一个队列。
- 优点：这种方案非常简单
- 缺点：可能会导致缓存命中率低。因为，进入缓存的先后顺序和访问频率无关，这种算法可能会将访问频率高的数据给淘汰。
LIFO（Last In First Out，后进先出） - 淘汰最后进入的缓存数据。缓存的行为就像一个栈。
- 优点：这种方案非常简单
- 缺点：和 FIFO 一样，也可能会导致缓存命中率低。因为，进入缓存的先后顺序和访问频率无关，这种算法可能会将访问频率高的数据给淘汰。
MRU（Most Recently Used，最近最多使用） - 淘汰最近最多使用缓存。
- 优点：适用于一些特殊场景，例如数据访问具有较强的局部性。举个例子，用户访问一个信息流页面，已经看过的内容，他肯定不想再看到，此时就可以使用 MRU。
- 缺点：某些情况下，可能会导致频繁的淘汰缓存，从而降低缓存命中率
LRU（Least Recently Used，最近最少使用） - 淘汰最近最少使用缓存。
- 优点：避免了 FIFO 缓存命中率低的问题。
- 缺点：存在临界区问题。假设，缓存只保留 1 分钟以内的热点数据。如果有个数据在 1 个小时的前 59 分钟访问了 1 万次（可见这是个热点数据），最后一分钟没有任何访问；而其他数据有被访问，就会导致这个热点数据被淘汰。
LFU（Less Frequently Used，最近最少频率使用） - 该算法对 LRU 做了进一步优化：利用额外的空间记录每个数据的使用频率，然后淘汰使用频率最低的数据，如果所有数据使用频率相同，可以用 FIFO 淘汰最早的缓存数据。
- 优点：解决了 LRU 的临界区问题。
- 缺点：记录使用频率，会产生额外的空间开销

:::

【高级】缓存更新有哪些策略？

:::details 要点

一般来说，系统如果不是严格要求缓存和数据库保持一致性的话，尽量不要将读请求和写请求串行化。串行化可以保证一定不会出现数据不一致的情况，但是它会导致系统的吞吐量大幅度下降。缓存更新的常见策略有以下几种：

Cache Aside
Wirte Through
Read Though
Wirte Behind

需要注意的是：以上几种缓存更新策略，都无法保证数据强一致。如果一定要保证强一致性，可以通过两阶段提交（2PC）或 Paxos 协议来实现。但是 2PC 太慢，而 Paxos 太复杂，所以如果不是非常重要的数据，不建议使用强一致性方案。

Cache Aside

Wirte Through

Read Though

Wirte Behind

:::

【高级】多级缓存架构如何设计？

:::details 要点

:::

【中级】什么是缓存穿透？如何应对？

:::details 要点

:::

【中级】什么是缓存击穿？如何应对？

:::details 要点

:::

【中级】什么是缓存雪崩？如何应对？

:::details 要点

:::

【中级】什么是缓存预热？如何预热？

:::details 要点

:::

读写分离

【基础】什么是读写分离？为什么需要读写分离？

:::details 要点

:::

【中级】如何实现读写分离？

:::details 要点

:::

分库分表

【基础】什么是分库分表？为什么需要分库分表？

:::details 要点

:::

【高级】如何实现分库分表？

:::details 要点

:::

【高级】分库分表后，如何应对扩容和迁移？

:::details 要点

:::

《极客时间教程 - 秒杀系统》笔记

发表于 2025-01-07 更新于 2025-04-01 分类于笔记，设计本文字数： 5.8k 阅读时长 ≈ 5 分钟

《极客时间教程 - 秒杀系统》笔记

开篇词丨秒杀系统架构设计都有哪些关键点？

秒杀的整体架构可以概括为“稳、准、快”几个关键字

稳-高可用 - 服务需要考虑各种容错场景，保证服务可用
准-一致性 - 高并发下的库存数量增减不能出错，避免超卖
快-高性能 - 支持高并发的读写

设计秒杀系统时应该注意的 5 个架构原则

秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统。

架构原则：“4 要 1 不要”

数据尽量少
- 请求及响应的数据量越小，则传输数据量越小，可以显著减少 CPU 和带宽；
- 依赖数据库的数据越少，数据库压力越小，I/O 耗时越少
请求数尽量少 - 合并 css+js，减少静态资源的请求数
路径尽量短
- 路径，是指用户发出请求、收到响应的整个过程中，数据经过的节点数。
- 路径越短，则 I/O 传输耗时越少，也更加可靠。
依赖尽量少 - 依赖，是指要完成一次用户请求必须依赖的系统或者服务。
避免单点
对于应用服务，应设计为无状态，然后以集群模式提供整体服务，以此提高可用性
对于数据库，应通过副本机制+故障转移，来保证可用性。

不同场景下的不同架构案例

（1）请求量级 10w QPS 的架构

架构要点：

把秒杀系统独立出来单独打造一个系统，这样可以有针对性地做优化
在系统部署上也独立做一个机器集群，这样秒杀的大流量就不会影响到正常的商品购买集群的机器负载；
将热点数据（如库存数据）单独放到一个缓存系统中，以提高“读性能”；
增加秒杀答题，防止有秒杀器抢单。

（1）请求量级 100w QPS 的架构

对页面进行彻底的动静分离，使得用户秒杀时不需要刷新整个页面，而只需要点击抢宝按钮，借此把页面刷新的数据降到最少；
在服务端对秒杀商品进行本地缓存，不需要再调用依赖系统的后台服务获取数据，甚至不需要去公共的缓存集群中查询数据，这样不仅可以减少系统调用，而且能够避免压垮公共缓存集群。
增加系统限流保护，防止最坏情况发生。

小结：架构之道，在于权衡取舍。要取得极致的性能，往往要在通用性、易用性、成本等方面有所牺牲，反之亦然。

如何才能做好动静分离？有哪些方案可选？

何为动静数据

“动态数据”和“静态数据”的主要区别就是看页面中输出的数据是否和 URL、浏览者、时间、地域相关，以及是否含有 Cookie 等私密数据。

所谓“动态”还是“静态”，并不是说数据本身是否动静，而是数据中是否含有和访问者相关的个性化数据。更通俗的来说，是不是每个人看到的页面是相同的。

怎样对静态数据做缓存呢？

第一，你应该把静态数据缓存到离用户最近的地方。常见技术：CDN、Cookie、服务器缓存
第二，静态化改造就是要直接缓存 HTTP 连接。例如：Nginx 静态缓存
第三，让谁来缓存静态数据也很重要。Web 服务器（如 Nginx、Apache、Varnish）更擅长处理大并发的静态文件请求。

如何做动静分离的改造

URL 唯一化。商品详情系统天然地就可以做到 URL 唯一化，比如每个商品都由 ID 来标识，那么 http://item.xxx.com/item.htm?id=xxxx 就可以作为唯一的 URL 标识。为啥要 URL 唯一呢？前面说了我们是要缓存整个 HTTP 连接，那么以什么作为 Key 呢？就以 URL 作为缓存的 Key，例如以 id=xxx 这个格式进行区分。
分离浏览者相关的因素。浏览者相关的因素包括身份、认证信息等。这部分少量数据可以通过动态请求来获取。
分离时间因素。服务端输出的时间也通过动态请求获取。
异步化地域因素。详情页面上与地域相关的因素做成异步方式获取，当然你也可以通过动态请求方式获取，只是这里通过异步获取更合适。
去掉 Cookie。服务端输出的页面包含的 Cookie 可以通过代码软件来删除，如 Web 服务器 Varnish 可以通过 unset req.http.cookie 命令去掉 Cookie。注意，这里说的去掉 Cookie 并不是用户端收到的页面就不含 Cookie 了，而是说，在缓存的静态数据中不含有 Cookie。

分离出动态内容之后，如何组织这些内容页就变得非常关键了。动态内容的处理通常有两种方案：

ESI 方案（或者 SSI）：即在 Web 代理服务器上做动态内容请求，并将请求插入到静态页面中，当用户拿到页面时已经是一个完整的页面了。这种方式对服务端性能有些影响，但是用户体验较好。
CSI 方案。即单独发起一个异步 JavaScript 请求，以向服务端获取动态内容。这种方式服务端性能更佳，但是用户端页面可能会延时，体验稍差。

动静分离的几种架构方案

方案 1：实体机单机部署

这种方案是将虚拟机改为实体机，以增大 Cache 的容量，并且采用了一致性 Hash 分组的方式来提升命中率。这里将 Cache 分成若干组，是希望能达到命中率和访问热点的平衡。Hash 分组越少，缓存的命中率肯定就会越高，但短板是也会使单个商品集中在一个分组中，容易导致 Cache 被击穿，所以我们应该适当增加多个相同的分组，来平衡访问热点和命中率的问题。

实体机单机部署有以下几个优点：

没有网络瓶颈，而且能使用大内存；
既能提升命中率，又能减少 Gzip 压缩；
减少 Cache 失效压力，因为采用定时失效方式，例如只缓存 3 秒钟，过期即自动失效。

缺点：

一定程度上也造成了 CPU 的浪费，因为单个的 Java 进程很难用完整个实体机的 CPU。
一个实体机上部署了 Java 应用又作为 Cache 来使用，这造成了运维上的高复杂度。

方案 2：统一 Cache 层

所谓统一 Cache 层，就是将单机的 Cache 统一分离出来，形成一个单独的 Cache 集群。

优点：

应用无需单独维护 Cache
运维简单
可以共享内存，最大化利用内存

缺点：

Cache 层内部交换网络成为瓶颈；
缓存服务器的网卡也会是瓶颈；
机器少风险较大，挂掉一台就会影响很大一部分缓存数据。

方案 3：CDN

动静分离后，缓存如果前置到 CDN，由于离用户更近，因此访问更快。

CDN 方案有以下问题：

失效问题。需要考虑如果让 CDN 分布在全国各地的 Cache 在秒级时间内失效。
命中率问题。如果将数据全部放到全国的 CDN 上，必然导致 Cache 分散，而 Cache 分散又会导致访问请求命中同一个 Cache 的可能性降低，那么命中率就成为一个问题。
发布更新问题。若业务迭代快速，则发布系统必须足够简洁高效

将商品详情系统放到全国的所有 CDN 节点上是不太现实的，因为存在失效问题、命中率问题以及系统的发布更新问题。那么是否可以选择若干个节点来尝试实施呢？答案是“可以”，但是这样的节点需要满足几个条件：

靠近访问量比较集中的地区；
离主站相对较远；
节点到主站间的网络比较好，而且稳定；
节点容量比较大，不会占用其他 CDN 太多的资源。

最后，还有一点也很重要，那就是：节点不要太多。

基于上面几个因素，选择 CDN 的二级 Cache 比较合适，因为二级 Cache 数量偏少，容量也更大，让用户的请求先回源的 CDN 的二级 Cache 中，如果没命中再回源站获取数据，部署方式如下图所示：

二八原则：有针对性地处理好系统的“热点数据”

所谓“静态热点数据”，就是能够提前预测的热点数据。例如，我们可以通过卖家报名的方式提前筛选出来，通过报名系统对这些热点商品进行打标。另外，我们还可以通过大数据分析来提前发现热点商品，比如我们分析历史成交记录、用户的购物车记录，来发现哪些商品可能更热门、更好卖，这些都是可以提前分析出来的热点。

所谓“动态热点数据”，就是不能被提前预测到的，系统在运行过程中临时产生的热点。例如，卖家在抖音上做了广告，然后商品一下就火了，导致它在短时间内被大量购买。

发现热点数据

动态热点发现系统的具体实现。

构建一个异步的系统，它可以收集交易链路上各个环节中的中间件产品的热点 Key，如 Nginx、缓存、RPC 服务框架等这些中间件（一些中间件产品本身已经有热点统计模块）。
建立一个热点上报和可以按照需求订阅的热点服务的下发规范，主要目的是通过交易链路上各个系统（包括详情、购物车、交易、优惠、库存、物流等）访问的时间差，把上游已经发现的热点透传给下游系统，提前做好保护。比如，对于大促高峰期，详情系统是最早知道的，在统一接入层上 Nginx 模块统计的热点 URL。
将上游系统收集的热点数据发送到热点服务台，然后下游系统（如交易系统）就会知道哪些商品会被频繁调用，然后做热点保护。

这里我给出了一个图，其中用户访问商品时经过的路径有很多，我们主要是依赖前面的导购页面（包括首页、搜索页面、商品详情、购物车等）提前识别哪些商品的访问量高，通过这些系统中的中间件来收集热点数据，并记录到日志中。

处理热点数据

处理热点数据通常有几种思路：一是优化，二是限制，三是隔离。

具体到“秒杀”业务，我们可以在以下几个层次实现隔离。

业务隔离。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就有了已知热点，因此可以提前做好预热。
系统隔离。系统隔离更多的是运行时的隔离，可以通过分组部署的方式和另外 99%分开。秒杀可以申请单独的域名，目的也是让请求落到不同的集群中。
数据隔离。秒杀所调用的数据大部分都是热点数据，比如会启用单独的 Cache 集群或者 MySQL 数据库来放热点数据，目的也是不想 0.01%的数据有机会影响 99.99%数据。

流量削峰这事应该怎么做？

流量削峰的思路：排队、答题、分层过滤

排队 - 使用 MQ 削峰、解耦

适用于内部上下游系统之间调用请求不平缓的场景，由于内部系统的服务质量要求不能随意丢弃请求，所以使用消息队列能起到很好的削峰和缓冲作用。

答题 - 延缓请求、限制秒杀器

适用于秒杀或者营销活动等应用场景，在请求发起端就控制发起请求的速度，因为越到后面无效请求也会越多，所以配合后面介绍的分层拦截的方式，可以更进一步减少无效请求对系统资源的消耗。

分层过滤 - 请求分别经过 CDN、前台读系统（如商品详情系统）、后台系统（如交易系统）和数据库这几层分层过滤。

分层过滤非常适合交易性的写请求，比如减库存或者拼车这种场景，在读的时候需要知道还有没有库存或者是否还有剩余空座位。但是由于库存和座位又是不停变化的，所以读的数据是否一定要非常准确呢？其实不一定，你可以放一些请求过去，然后在真正减的时候再做强一致性保证，这样既过滤一些请求又解决了强一致性读的瓶颈。

分层校验的基本原则是：

将动态请求的读数据缓存（Cache）在 Web 端，过滤掉无效的数据读；
对读数据不做强一致性校验，减少因为一致性校验产生瓶颈的问题；
对写数据进行基于时间的合理分片，过滤掉过期的失效请求；
对写请求做限流保护，将超出系统承载能力的请求过滤掉；
对写数据进行强一致性校验，只保留最后有效的数据。

影响性能的因素有哪些？又该如何提高系统的性能？

影响性能的因素：响应时间、线程数
如何发现瓶颈：
- 瓶颈点：CPU、内存、磁盘、带宽
- 针对 CPU 而言，可以使用 CPU 相关工具：JProfile、Yourkit、jstack，此外，还可以使用链路追踪进行链路分析
如何优化系统：编码、序列化、压缩、传输方式（NIO）、并发

秒杀系统“减库存”设计的核心逻辑

减库存的一般方式：

下单减库存：不会出现超卖；不能应对下单不付款的情况
付款减库存：高并发下，可能出现超卖——下单后无法付款的情况（库存已经清空）
预扣库存：买家下单后，库存为其保留一定的时间（如 10 分钟），超过这个时间，库存将会自动释放，释放后其他买家就可以继续购买。在买家付款前，系统会校验该订单的库存是否还有保留：如果没有保留，则再次尝试预扣；如果库存不足（也就是预扣失败）则不允许继续付款；如果预扣成功，则完成付款并实际地减去库存。

针对秒杀场景，一般“抢到就是赚到”，所以成功下单后却不付款的情况比较少，再加上卖家对秒杀商品的库存有严格限制，所以秒杀商品采用“下单减库存”更加合理。另外，理论上，“下单减库存”比“预扣库存”以及涉及第三方支付的“付款减库存”在逻辑上更为简单，所以性能上更占优势。

“下单减库存”在数据一致性上，主要就是保证大并发请求时库存数据不能为负数，也就是要保证数据库中的库存字段值不能为负数，一般我们有多种解决方案：一种是在应用程序中通过事务来判断，即保证减后库存不能为负数，否则就回滚；另一种办法是直接设置数据库的字段数据为无符号整数，这样减后库存字段值小于零时会直接执行 SQL 语句来报错；再有一种就是使用 CASE WHEN 判断语句，例如这样的 SQL 语句：

1	UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

准备 Plan B：如何设计兜底方案

高可用系统建设：

设计阶段：考虑系统的可扩展性和容错性。避免单点问题，采用多活方案（多机房部署）。
编码阶段：保证代码的健壮性。识别边界，捕获、处理异常；设置合适的超时机制。
测试阶段：测试用例覆盖度尽量全面。
发布阶段：自动化发布，支持灰度发布、回滚。
运行阶段：健全监控机制：日志、指标、链路监控
故障发生：容错处理、故障恢复、故障演练

降级

“降级”，就是当系统的容量达到一定程度时，限制或者关闭系统的某些非核心功能，从而把有限的资源保留给更核心的业务。

限流

限流就是当系统容量达到瓶颈时，我们需要通过限制一部分流量来保护系统，并做到既可以人工执行开关，也支持自动化保护的措施。

拒绝服务

过载保护 - 当系统负载达到一定阈值时，例如 CPU 使用率达到 90%或者系统 load 值达到 2*CPU 核数时，系统直接拒绝所有请求，这种方式是最暴力但也最有效的系统保护方式。

拒绝服务可以说是一种不得已的兜底方案，用以防止最坏情况发生，防止因把服务器压跨而长时间彻底无法提供服务。像这种系统过载保护虽然在过载时无法提供服务，但是系统仍然可以运作，当负载下降时又很容易恢复，所以每个系统和每个环节都应该设置这个兜底方案，对系统做最坏情况下的保护。

高可用建设需要长期规划并进行体系化建设，要在预防（建立常态的压力体系，例如上线前的单机压测到上线后的全链路压测）、管控（做好线上运行时的降级、限流和兜底保护）、监控（建立性能基线来记录性能的变化趋势以及线上机器的负载报警体系，发现问题及时预警）和恢复体系（遇到故障要及时止损，并提供快速的数据订正工具等）等这些地方加强建设。

分布式调度面试

发表于 2024-12-26 更新于 2025-04-01 分类于分布式，分布式调度本文字数： 28k 阅读时长 ≈ 26 分钟

分布式调度面试

服务注册和发现

【基础】什么是服务注册和发现？

:::details 要点

服务定义是服务提供者和服务消费者之间的约定，但是在微服务架构中，如何达成这个约定呢？这就依赖于服务注册和发现机制。

在微服务架构下，服务注册和发现机制中主要有三种角色：

服务提供者（RPC Server / Provider）
服务消费者（RPC Client / Consumer）
服务注册中心（Registry）

服务发现通常依赖于注册中心来协调服务发现的过程，其步骤如下：

服务提供者将接口信息以注册到注册中心。
服务消费者从注册中心读取和订阅服务提供者的地址信息。
如果有可用的服务，注册中心会主动通知服务消费者。
服务消费者根据可用服务的地址列表，调用服务提供者的接口。

这个过程很像是生活中的房屋租赁，房东将租房信息挂到中介公司，房客从中介公司查找租房信息。房客如果想要租房东的房子，通过中介公司牵线搭桥，联系上房东，双方谈妥签订协议，就可以正式建立起租赁关系。

:::

【中级】注册中心有哪些基本功能？

:::details 要点

从服务注册和发现的流程，可以看出，注册中心是服务发现的核心组件。常见的注册中心组件有：Nacos、Consul、Zookeeper 等。

注册中心的实现主要涉及几个问题：注册中心需要提供哪些接口，该如何部署；如何存储服务信息；如何监控服务提供者节点的存活；如果服务提供者节点有变化如何通知服务消费者，以及如何控制注册中心的访问权限。

元数据定义

构建微服务的首要问题是：服务提供者和服务消费者通信时，如何达成共识。具体来说，就是这个服务的接口名是什么？调用这个服务需要传递哪些参数？接口的返回值是什么类型？以及一些其他接口描述信息。

常见的定义服务元数据的方式有：

XML 文件 - 如果只是企业内部之间的服务调用，并且都是 Java 语言的话，选择 XML 配置方式是最简单的。
IDL 文件 - 如果企业内部存在多个跨语言服务，建议使用 IDL 文件方式进行描述服务。
REST API - 如果存在对外开放服务调用的情形的话，使用 REST API 方式则更加通用。

元数据存储

注册中心本质上是一个用于保存元数据的分布式存储。你如果明白了这一点，就会了解实现一个注册中心的所有要点都是围绕这个目标去构建的。

想要构建微服务，首先要解决的问题是，服务提供者如何发布一个服务，服务消费者如何引用这个服务。具体来说，就是这个服务的接口名是什么？调用这个服务需要传递哪些参数？接口的返回值是什么类型？以及一些其他接口描述信息。

服务的元数据信息通常有以下信息：

服务节点信息，如 IP、端口等。
接口定义，如接口名、请求参数、响应参数等。
请求失败的重试次数
序列化方式
压缩方式
通信协议
等等

在具体存储时，注册中心一般会按照“服务 - 分组 - 节点信息”的层次化的结构来存储。

注册中心 API

既然是分布式存储，势必要提供支持读写数据的接口，也就是 API，一般来说，需要支持以下功能：

服务注册接口：服务提供者通过调用服务注册接口来完成服务注册。
服务反注册接口：服务提供者通过调用服务反注册接口来完成服务注销。
心跳汇报接口：服务提供者通过调用心跳汇报接口完成节点存活状态上报。
服务订阅接口：服务消费者通过调用服务订阅接口完成服务订阅，获取可用的服务提供者节点列表。
服务变更查询接口：服务消费者通过调用服务变更查询接口，获取最新的可用服务节点列表。

除此之外，为了便于管理，注册中心还必须提供一些后台管理的 API，例如：

服务查询接口：查询注册中心当前注册了哪些服务信息。
服务修改接口：修改注册中心中某一服务的信息。

服务健康检测

注册中心除了要支持最基本的服务注册和服务订阅功能以外，还必须具备对服务提供者节点的健康状态检测功能，这样才能保证注册中心里保存的服务节点都是可用的。注册中心通常使用长连接或心跳探测方式检查服务健康状态。

还是以 ZooKeeper 为例，它是基于 ZooKeeper 客户端和服务端的长连接和会话超时控制机制，来实现服务健康状态检测的。在 ZooKeeper 中，客户端和服务端建立连接后，会话也随之建立，并生成一个全局唯一的 Session ID。服务端和客户端维持的是一个长连接，在 SESSION_TIMEOUT 周期内，服务端会检测与客户端的链路是否正常，具体方式是通过客户端定时向服务端发送心跳消息（ping 消息），服务器重置下次 SESSION_TIMEOUT 时间。如果超过 SESSION_TIMEOUT 后服务端都没有收到客户端的心跳消息，则服务端认为这个 Session 就已经结束了，ZooKeeper 就会认为这个服务节点已经不可用，将会从注册中心中删除其信息。

服务状态变更通知

一旦注册中心探测到有服务提供者节点新加入或者被剔除，就必须立刻通知所有订阅该服务的服务消费者，刷新本地缓存的服务节点信息，确保服务调用不会请求不可用的服务提供者节点。注册中心通常基于服务状态订阅来实现服务状态变更通知。

继续以 ZooKeeper 为例，基于 ZooKeeper 的 Watcher 机制，来实现服务状态变更通知给服务消费者的。服务消费者在调用 ZooKeeper 的 getData 方法订阅服务时，还可以通过监听器 Watcher 的 process 方法获取服务的变更，然后调用 getData 方法来获取变更后的数据，刷新本地缓存的服务节点信息。

集群部署

注册中心作为服务提供者和服务消费者之间沟通的桥梁，它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。根据 CAP 理论，三种特性无法同时达成，必须在可用性和一致性之间做取舍。于是，根据不同侧重点，注册中心可以分为 CP 和 AP 两个阵营：

CP 型注册中心 - 牺牲可用性来换取数据强一致性，最典型的例子就是 ZooKeeper，etcd，Consul 了。ZooKeeper 集群内只有一个 Leader，而且在 Leader 无法使用的时候通过算法选举出一个新的 Leader。这个 Leader 的目的就是保证写信息的时候只向这个 Leader 写入，Leader 会同步信息到 Followers，这个过程就可以保证数据的强一致性。但如果多个 ZooKeeper 之间网络出现问题，造成出现多个 Leader，发生脑裂的话，注册中心就不可用了。而 etcd 和 Consul 集群内都是通过 Raft 协议来保证强一致性，如果出现脑裂的话，注册中心也不可用。
AP 型注册中心 - 牺牲一致性（只保证最终一致性）来换取可用性，最典型的例子就是 Eureka、Nacos 了。对比下 Zookeeper，Eureka 不用选举一个 Leader，每个 Eureka 服务器单独保存服务注册地址，因此有可能出现数据信息不一致的情况。但是当网络出现问题的时候，每台服务器都可以完成独立的服务。

:::

【高级】注册中心有哪些扩展功能？

:::details 要点

多注册中心

对于服务消费者来说，要能够同时从多个注册中心订阅服务；

对于服务提供者来说，要能够同时向多个注册中心注册服务。

并行订阅服务

如果只支持串行订阅，如果服务消费者订阅的服务较多，并且某些服务节点的初始化连接过程中出现连接超时的情况，则后续所有的服务节点的初始化连接都需要等待它完成，这就会导致消费者启动非常慢。

可以每订阅一个服务就单独用一个线程来处理，这样的话即使遇到个别服务节点连接超时，其他服务节点的初始化连接也不受影响，最慢也就是这个服务节点的初始化连接耗费的时间，最终所有服务节点的初始化连接耗时控制在了 30 秒以内。

批量注销服务

在与注册中心的多次交互中，可能由于网络抖动、注册中心集群异常等原因，导致个别调用失败。对于注册中心来说，偶发的注册调用失败对服务调用基本没有影响，其结果顶多就是某一个服务少了一个可用的节点。但偶发的反注册调用失败会导致不可用的节点残留在注册中心中，变成“僵尸节点”。

需要定时去清理注册中心中的“僵尸节点”，如果支持批量注销服务，就可以一次调用就把该节点上提供的所有服务同时注销掉。

服务变更信息增量更新

为了减少服务消费者从注册中心中拉取的服务可用节点信息的数据量，这个时候可以通过增量更新的方式，注册中心只返回变化的那部分节点信息。尤其在只有少数节点信息变更时，此举可以大大减少服务消费者从注册中心拉取的数据量，从而最大程度避免产生网络风暴。

心跳开关保护机制

在网络频繁抖动的情况下，注册中心中可用的节点会不断变化，这时候服务消费者会频繁收到服务提供者节点变更的信息，于是就不断地请求注册中心来拉取最新的可用服务节点信息。当有成百上千个服务消费者，同时请求注册中心获取最新的服务提供者的节点信息时，可能会把注册中心的带宽给占满，尤其是注册中心是百兆网卡的情况下。

所以针对这种情况，需要一种保护机制，即使在网络频繁抖动的时候，服务消费者也不至于同时去请求注册中心获取最新的服务节点信息。

我曾经就遇到过这种情况，一个可行的解决方案就是给注册中心设置一个开关，当开关打开时，即使网络频繁抖动，注册中心也不会通知所有的服务消费者有服务节点信息变更，比如只给 10% 的服务消费者返回变更，这样的话就能将注册中心的请求量减少到原来的 1/10。

当然打开这个开关也是有一定代价的，它会导致服务消费者感知最新的服务节点信息延迟，原先可能在 10s 内就能感知到服务提供者节点信息的变更，现在可能会延迟到几分钟，所以在网络正常的情况下，开关并不适合打开；可以作为一个紧急措施，在网络频繁抖动的时候，才打开这个开关。

服务节点摘除保护机制

服务提供者在进程启动时，会注册服务到注册中心，并每隔一段时间，汇报心跳给注册中心，以标识自己的存活状态。如果隔了一段固定时间后，服务提供者仍然没有汇报心跳给注册中心，注册中心就会认为该节点已经处于“dead”状态，于是从服务的可用节点信息中移除出去。

如果遇到网络问题，大批服务提供者节点汇报给注册中心的心跳信息都可能会传达失败，注册中心就会把它们都从可用节点列表中移除出去，造成剩下的可用节点难以承受所有的调用，引起“雪崩”。但是这种情况下，可能大部分服务提供者节点是可用的，仅仅因为网络原因无法汇报心跳给注册中心就被“无情”的摘除了。

这个时候就需要根据实际业务的情况，设定一个阈值比例，即使遇到刚才说的这种情况，注册中心也不能摘除超过这个阈值比例的节点。

这个阈值比例可以根据实际业务的冗余度来确定，我通常会把这个比例设定在 20%，就是说注册中心不能摘除超过 20% 的节点。因为大部分情况下，节点的变化不会这么频繁，只有在网络抖动或者业务明确要下线大批量节点的情况下才有可能发生。而业务明确要下线大批量节点的情况是可以预知的，这种情况下可以关闭阈值保护；而正常情况下，应该打开阈值保护，以防止网络抖动时，大批量可用的服务节点被摘除。

白名单机制

在实际的微服务测试和部署时，通常包含多套环境，比如生产环境一套、测试环境一套。开发在进行业务自测、测试在进行回归测试时，一般都是用测试环境，部署的 RPC Server 节点注册到测试的注册中心集群。但经常会出现开发或者测试在部署时，错误的把测试环境下的服务节点注册到了线上注册中心集群，这样的话线上流量就会调用到测试环境下的 RPC Server 节点，可能会造成意想不到的后果。

为了防止这种情况发生，注册中心需要提供一个保护机制，你可以把注册中心想象成一个带有门禁的房间，只有拥有门禁卡的 RPC Server 才能进入。在实际应用中，注册中心可以提供一个白名单机制，只有添加到注册中心白名单内的 RPC Server，才能够调用注册中心的注册接口，这样的话可以避免测试环境中的节点意外跑到线上环境中去。

静态注册中心

因为服务提供者是向服务消费者提供服务的，服务是否可用，服务消费者应该比注册中心更清楚。因此，可以直接在服务消费者端，根据调用服务提供者是否成功来判定服务提供者是否可用。如果服务消费者调用某一个服务提供者节点连续失败超过一定次数，可以在本地内存中将这个节点标记为不可用。并且每隔一段固定时间，服务消费者都要向标记为不可用的节点发起保活探测，如果探测成功了，就将标记为不可用的节点再恢复为可用状态，重新发起调用。

:::

负载均衡

【基础】什么是负载均衡？为什么需要负载均衡？

:::details 要点

“负载均衡（Load Balance，简称 LB）”是一种技术，用来在多个计算机、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到优化资源利用率、最大化吞吐率、最小化响应时间、同时避免过载的目的。

负载均衡的主要作用如下：

高并发：负载均衡可以优化资源使用率，通过算法调整负载，尽力均匀的分配资源，以此提高资源利用率、从而提升整体吞吐量。
伸缩性：发生增减资源时，负载均衡可以自动调整分发，使得应用集群具备伸缩性。
高可用：负载均衡器可以监控候选机器，当某机器不可用时，自动跳过，将请求分发给可用的机器。这使得应用集群具备高可用的特性。
安全防护：有些负载均衡软件或硬件提供了安全性功能，如：黑白名单、防火墙，防 DDos 攻击等。

:::

【中级】负载均衡技术有哪些分类？

:::details 要点

支持负载均衡的技术很多，我们可以通过不同维度去进行分类。

载体维度分类

从支持负载均衡的载体来看，可以将负载均衡分为两类：

硬件负载均衡
软件负载均衡

硬件负载均衡

硬件负载均衡，一般是在定制处理器上运行的独立负载均衡服务器，价格昂贵，土豪专属。

硬件负载均衡的主流产品有：F5 和 A10。

硬件负载均衡的优点：

功能强大：支持全局负载均衡并提供较全面的、复杂的负载均衡算法。
性能强悍：硬件负载均衡由于是在专用处理器上运行，因此吞吐量大，可支持单机百万以上的并发。
安全性高：往往具备防火墙，防 DDos 攻击等安全功能。

硬件负载均衡的缺点：

成本昂贵：购买和维护硬件负载均衡的成本都很高。
扩展性差：当访问量突增时，超过限度不能动态扩容。

软件负载均衡

软件负载均衡，应用最广泛，无论大公司还是小公司都会使用。

软件负载均衡从软件层面实现负载均衡，一般可以在任何标准物理设备上运行。

软件负载均衡的 主流产品 有：Nginx、HAProxy、LVS。

LVS 可以作为四层负载均衡器。其负载均衡的性能要优于 Nginx。
HAProxy 可以作为 HTTP 和 TCP 负载均衡器。
Nginx、HAProxy 可以作为四层或七层负载均衡器。

软件负载均衡的优点：

扩展性好：适应动态变化，可以通过添加软件负载均衡实例，动态扩展到超出初始容量的能力。
成本低廉：软件负载均衡可以在任何标准物理设备上运行，降低了购买和运维的成本。

软件负载均衡的缺点：

性能略差：相比于硬件负载均衡，软件负载均衡的性能要略低一些。

网络通信分类

软件负载均衡从通信层面来看，又可以分为四层和七层负载均衡。

七层负载均衡：就是可以根据访问用户的 HTTP 请求头、URL 信息将请求转发到特定的主机。
- DNS 重定向
- HTTP 重定向
- 反向代理
四层负载均衡：基于 IP 地址和端口进行请求的转发。
- 修改 IP 地址
- 修改 MAC 地址

DNS 负载均衡

DNS 负载均衡一般用于互联网公司，复杂的业务系统不适合使用。大型网站一般使用 DNS 负载均衡作为 第一级负载均衡手段，然后在内部使用其它方式做第二级负载均衡。DNS 负载均衡属于七层负载均衡。

DNS 即 域名解析服务，是 OSI 第七层网络协议。DNS 被设计为一个树形结构的分布式应用，自上而下依次为：根域名服务器，一级域名服务器，二级域名服务器，… ，本地域名服务器。显然，如果所有数据都存储在根域名服务器，那么 DNS 查询的负载和开销会非常庞大。

因此，DNS 查询相对于 DNS 层级结构，是一个逆向的递归流程，DNS 客户端依次请求本地 DNS 服务器，上一级 DNS 服务器，上上一级 DNS 服务器，… ，根 DNS 服务器（又叫权威 DNS 服务器），一旦命中，立即返回。为了减少查询次数，每一级 DNS 服务器都会设置 DNS 查询缓存。

DNS 负载均衡的工作原理就是：基于 DNS 查询缓存，按照负载情况返回不同服务器的 IP 地址。

DNS 重定向的优点：

使用简单：负载均衡工作，交给 DNS 服务器处理，省掉了负载均衡服务器维护的麻烦
提高性能：可以支持基于地址的域名解析，解析成距离用户最近的服务器地址（类似 CDN 的原理），可以加快访问速度，改善性能；

DNS 重定向的缺点：

可用性差：DNS 解析是多级解析，新增/修改 DNS 后，解析时间较长；解析过程中，用户访问网站将失败；
扩展性差：DNS 负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展；
维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）

HTTP 负载均衡

HTTP 负载均衡是基于 HTTP 重定向实现的。HTTP 负载均衡属于七层负载均衡。

HTTP 重定向原理是：根据用户的 HTTP 请求计算出一个真实的服务器地址，将该服务器地址写入 HTTP 重定向响应中，返回给浏览器，由浏览器重新进行访问。

HTTP 重定向的优点：方案简单。

HTTP 重定向的缺点：

额外的转发开销：每次访问需要两次请求服务器，增加了访问的延迟。
降低搜索排名：使用重定向后，搜索引擎会视为 SEO 作弊。
如果负载均衡器宕机，就无法访问该站点。

由于其缺点比较明显，所以这种负载均衡策略实际应用较少。

反向代理负载均衡

反向代理（Reverse Proxy）方式是指以 代理服务器 来接受网络请求，然后 将请求转发给内网中的服务器，并将从内网中的服务器上得到的结果返回给网络请求的客户端。反向代理负载均衡属于七层负载均衡。

反向代理服务的主流产品：Nginx、Apache。

正向代理与反向代理有什么区别？

正向代理：发生在 客户端，是由用户主动发起的。翻墙软件就是典型的正向代理，客户端通过主动访问代理服务器，让代理服务器获得需要的外网数据，然后转发回客户端。
反向代理：发生在 服务端，用户不知道代理的存在。

反向代理是如何实现负载均衡的呢？以 Nginx 为例，如下所示：

首先，在代理服务器上设定好负载均衡规则。然后，当收到客户端请求，反向代理服务器拦截指定的域名或 IP 请求，根据负载均衡算法，将请求分发到候选服务器上。其次，如果某台候选服务器宕机，反向代理服务器会有容错处理，比如分发请求失败 3 次以上，将请求分发到其他候选服务器上。

反向代理的优点：

多种负载均衡算法：支持多种负载均衡算法，以应对不同的场景需求。
可以监控服务器：基于 HTTP 协议，可以监控转发服务器的状态，如：系统负载、响应时间、是否可用、连接数、流量等，从而根据这些数据调整负载均衡的策略。

反向代理的缺点：

额外的转发开销：反向代理的转发操作本身是有性能开销的，可能会包括创建连接，等待连接响应，分析响应结果等操作。
增加系统复杂度：反向代理常用于做分布式应用的水平扩展，但反向代理服务存在以下问题，为了解决以下问题会给系统整体增加额外的复杂度和运维成本：
反向代理服务如果自身宕机，就无法访问站点，所以需要有 高可用 方案，常见的方案有：主备模式（一主一备）、双主模式（互为主备）。
- 反向代理服务自身也存在性能瓶颈，随着需要转发的请求量不断攀升，需要有 可扩展 方案。

IP 负载均衡

IP 负载均衡是在网络层通过修改请求目的地址进行负载均衡。

如上图所示，IP 均衡处理流程大致为：

客户端请求 192.168.137.10，由负载均衡服务器接收到报文。
负载均衡服务器根据算法选出一个服务节点 192.168.0.1，然后将报文请求地址改为该节点的 IP。
真实服务节点收到请求报文，处理后，返回响应数据到负载均衡服务器。
负载均衡服务器将响应数据的源地址改负载均衡服务器地址，返回给客户端。

IP 负载均衡在内核进程完成数据分发，较反向代理负载均衡有更好的处理性能。但是，由于所有请求响应都要经过负载均衡服务器，集群的吞吐量受制于负载均衡服务器的带宽。

数据链路层负载均衡

数据链路层负载均衡是指在通信协议的数据链路层修改 mac 地址进行负载均衡。

在 Linux 平台上最好的链路层负载均衡开源产品是 LVS (Linux Virtual Server)。

LVS 是基于 Linux 内核中 netfilter 框架实现的负载均衡系统。netfilter 是内核态的 Linux 防火墙机制，可以在数据包流经过程中，根据规则设置若干个关卡（hook 函数）来执行相关的操作。

LVS 的工作流程大致如下：

当用户访问 www.sina.com.cn 时，用户数据通过层层网络，最后通过交换机进入 LVS 服务器网卡，并进入内核网络层。
进入 PREROUTING 后经过路由查找，确定访问的目的 VIP 是本机 IP 地址，所以数据包进入到 INPUT 链上
IPVS 是工作在 INPUT 链上，会根据访问的 vip+port 判断请求是否 IPVS 服务，如果是则调用注册的 IPVS HOOK 函数，进行 IPVS 相关主流程，强行修改数据包的相关数据，并将数据包发往 POSTROUTING 链上。
POSTROUTING 上收到数据包后，根据目标 IP 地址（后端服务器），通过路由选路，将数据包最终发往后端的服务器上。

开源 LVS 版本有 3 种工作模式，每种模式工作原理截然不同，说各种模式都有自己的优缺点，分别适合不同的应用场景，不过最终本质的功能都是能实现均衡的流量调度和良好的扩展性。主要包括三种模式：DR 模式、NAT 模式、Tunnel 模式。

:::

【高级】负载均衡有哪些算法？

:::details 要点

负载均衡器的实现可以分为两个部分：

根据负载均衡算法在候选机器列表选出一个机器；
将请求数据发送到该机器上。

负载均衡算法是负载均衡服务核心中的核心。负载均衡产品多种多样，但是各种负载均衡算法原理是共性的。

负载均衡算法有很多种，分别适用于不同的应用场景。本章节将由浅入深的，逐一讲解各种负载均衡算法的策略和特性，并根据算法之间的互补关系将它们串联起来。

注：负载均衡算法的实现，推荐阅读 Dubbo 官方负载均衡算法说明，源码讲解非常详细，非常值得借鉴。

下文中的各种算法的可执行示例已归档在 Github 仓库：java-load-balance，可以通过执行 io.github.dunwu.javatech.LoadBalanceDemo 查看各算法执行效果。

轮询算法

“轮询算法（Round Robin）”的策略是：将请求“依次”分发到候选机器。

如下图所示，轮询负载均衡器收到来自客户端的 6 个请求，编号为 1、4 的请求会被发送到服务端 0；编号为 2、5 的请求会被发送到服务端 1；编号为 3、6 的请求会被发送到服务端 2。

轮询算法适合的场景需要满足：各机器处理能力相近，且每个请求工作量差异不大。

随机算法

“随机算法（Random）” 将请求“随机”分发到候选机器。

如下图所示，随机负载均衡器收到来自客户端的 6 个请求，会随机分发请求，可能会出现：编号为 1、5 的请求会被发送到服务端 0；编号为 2、4 的请求会被发送到服务端 1；编号为 3、6 的请求会被发送到服务端 2。

随机算法适合的场景需要满足：各机器处理能力相近，且每个请求工作量差异不大。

学习过概率论的都知道，调用量较小的时候，可能负载并不均匀，调用量越大，负载越均衡。

加权轮询/随机算法

轮询/随机算法适合的场景都需要满足：各机器处理能力相近，且每个请求工作量差异不大。

在理想状况下，假设每个机器的硬件条件相同，如：CPU、内存、网络 IO 等配置都相同；并且每个请求的耗时一样（请求传输时间、请求访问数据时间、计算时间等），这时轮询算法才能真正做到负载均衡。显然，要满足以上条件都相同是几乎不可能的，更不要说实际的网络通信中还有更多复杂的情况。

以上，如果有一点不能满足，都无法做到真正的负载均衡。个体存在较大差异，当请求量较大时，处理较慢的机器可能会逐渐积压请求，从而导致过载甚至宕机。

如下图所示，假设存在这样的场景：

服务端 1 的处理能力远低于服务端 0 和服务端 2；
轮询/随机算法可以保证将请求尽量均匀的分发给两个机器；
编号为 1、4 的请求被发送到服务端 0；编号为 3、6 的请求被发送到服务端 2；二者处理能力强，应对游刃有余；
编号为 2、5 的请求被发送到服务端 1，服务端 1 处理能力弱，应对捉襟见肘，导致过载。

《蜘蛛侠》电影中有一句经典台词：能力越大，责任越大。显然，以上情况不符合这句话，处理能力强的机器并没有被分发到更多的请求，它的处理能力被闲置了。那么，如何解决这个问题呢？

一种比较容易想到的思路是：引入权重属性，可以根据机器的硬件条件为其设置合理的权重值，负载均衡时，优先将请求分发到权重较高的机器。

“加权轮询算法（Weighted Round Robbin）” 和“加权随机算法（Weighted Random）” 都采用了加权的思路，在轮询/随机算法的基础上，引入了权重属性，优先将请求分发到权重较高的机器。这样，就可以针对性能高、处理速度快的机器设置较高的权重，让其处理更多的请求；而针对性能低、处理速度慢的机器则与之相反。一言以蔽之，加权策略强调了——能力越大，责任越大。

如下图所示，服务端 0 设置权重为 3，服务端 1 设置权重为 1，服务端 2 设置权重为 2。负载均衡器收到来自客户端的 6 个请求，那么编号为 1、2、5 的请求会被发送到服务端 0，编号为 4 的请求会被发送到服务端 1，编号为 3、6 的请求会被发送到机器 2。

最少连接数算法

加权轮询/随机算法虽然一定程度上解决了机器处理能力不同时的负载均衡场景，但它最大的问题在于不能动态应对网络中负载不均的场景。加权的思路是在负载均衡处理的事前，预设好不同机器的权重，然后分发。然而，每个请求的连接时长不同，负载均衡器也不可能准确预估出请求的连接时长。因此，采用加权轮询/随机算法算法，都无法动态应对连接时长不均的网络场景，可能会出现某些机器当前连接数过多，而另一些机器的连接过少的情况，即并非真正的流量负载均衡。

如下图所示，假设存在这样的场景：

3 个服务端的处理能力相同；
编号为 1、4 的请求被发送到服务端 0，但是 1 很快就断开连接，此时只有 4 请求连接服务端 0；
编号为 2、5 的请求被发送到服务端 1，但是 2 始终保持长连接；该系统继续运行时，服务端 1 发生过载；
编号为 3、6 的请求被发送到服务端 2，但是 3 很快就断开连接，此时只有 6 请求连接服务端 2；

既然，请求的连接时长不同，会导致有的服务端处理慢，积压大量连接数；而有的服务端处理快，保持的连接数少。那么，我们不妨想一下，如果负载均衡器监控一下服务端当前所持有的连接数，优先将请求分发给连接数少的服务端，不就能有效提高分发效率了吗？最少连接数算法正是采用这个思路去设计的。

“最少连接数算法（Least Connections）” 将请求分发到连接数/请求数最少的候选机器。

要根据机器连接数分发，显然要先维护机器的连接数。因此，最少连接数算法需要实时追踪每个候选机器的活跃连接数；然后，动态选出连接数最少的机器，优先分发请求。最少连接数算法会记录当前时刻，每个候选节点正在处理的连接数，然后选择连接数最小的节点。该策略能够动态、实时地反应机器的当前状况，较为合理地将负责分配均匀，适用于对当前系统负载较为敏感的场景。

由此可见，最少连接数算法适用于对系统负载较为敏感且请求连接时长相差较大的场景。

如下图所示，假设存在这样的场景：

服务端 0 和服务端 1 的处理能力相同；
编号为 1、3 的请求被发送到服务端 0，但是 1、3 很快就断开连接；
编号为 2、4 的请求被发送到服务端 1，但是 2、4 保持长连接；
由于服务端 0 当前连接数最少，编号为 5、6 的请求被分发到服务端 0。

“加权最少连接数算法（Weighted Least Connection）”在最少连接数算法的基础上，根据机器的性能为每台机器分配权重，再根据权重计算出每台机器能处理的连接数。

最少响应时间算法

“最少响应时间算法（Least Time）” 将请求分发到响应时间最短的候选机器。最少响应时间算法和最少连接数算法二者的目标其实是殊途同归，都是动态调整，将请求尽量分发到处理能力强的机器上。不同点在于，最少连接数关注的维度是机器持有的连接数，而最少响应时间关注的维度是机器上一次响应时间哪个最短。理论上来说，持有的连接数少，响应时间短，都可以表明机器潜在的处理能力比较强。

最少响应时间算法具有高度的敏感性、自适应性。但是，由于它需要持续监控候选机器的响应时延，相比于监控候选机器的连接数，会显著增加监控的开销。此外，请求的响应时延并不一定能完全反应机器的处理能力，有可能某机器上一次处理的请求恰好是一个开销非常小的请求。

哈希算法

前面提到的负载均衡算法，都只适用于无状态应用。所谓无状态应用，意味着：请求无论分发到集群中的任意机器上，得到的响应都是相同的：然而，有状态服务则不然：请求分发到不同的机器上，得到的结果是不一样的。典型的无状态应用是普通的 Web 服务器；典型的有状态应用是各种分布式数据库（如：Redis、ElasticSearch 等），这些数据库存储了大量，乃至海量的数据，无法全部存储在一台机器上，为了提高整体容量以及吞吐量，采用了分区（分片）的设计，将数据化整为零的存储在不同机器上。

对于有状态应用，不仅仅需要保证负载的均衡，更为重要的是，需要保证针对相同数据的请求始终访问的是相同的机器，否则，就无法获取到正确的数据。

那么，如何解决有状态应用的负载均衡呢？有一种方案是哈希算法。

“哈希算法（Hash）” 根据一个 key （可以是唯一 ID、IP、URL 等），通过哈希函数计算得到一个数值，用该数值在候选机器列表的进行取模运算，得到的结果便是选中的机器。

这种算法可以保证，同一关键字（IP 或 URL 等）的请求，始终会被转发到同一台机器上。哈希负载均衡算法常被用于实现会话粘滞（Sticky Session）。

但是，哈希算法的问题是：当增减节点时，由于哈希取模函数的基数发生变化，会影响大部分的映射关系，从而导致之前的数据不可访问。要解决这个问题，就必须根据新的计算公式迁移数据。显然，如果数据量很大的情况下，迁移成本很高；并且，在迁移过程中，要保证业务平滑过渡，需要使用数据双写等较为复杂的技术手段。

一致性哈希算法

哈希算法的缺点是：当集群中出现增减节点时，由于哈希取模函数的基数发生变化，会导致大量集群中的机器不可用；需要通过代价高昂的数据迁移，来解决问题。那么，我们自然会希望有一种更优化的方案，来尽量减少影响的机器数。一致性哈希算法就是为了这个目标而应运而生。

一致性哈希算法对哈希算法进行了改良。“一致性哈希算法（Consistent Hash）”，根据哈希算法将对应的 key 哈希到一个具有 2^32 个桶的空间，并且头尾相连（0 到 2^32-1），即一个闭合的环形，这个圆环被称为“哈希环”。哈希算法是对节点的数量进行取模运算；而一致性哈希算法则是对 2^32 进行取模运算。

哈希环的空间是按顺时针方向组织的，需要对指定 key 的数据进行读写时，会执行两步：

先对节点进行哈希计算，计算的关键字通常是 IP 或其他唯一标识（例：hash(ip)），然后对 2^32 取模，以确定节点在哈希环上的位置。
先对 key 进行哈希计算（hash(key)），然后对 2^32 取模，以确定 key 在哈希环上的位置。
然后根据 key 的位置，顺时针找到的第一个节点，就是 key 对应的节点。

所以，一致性哈希是将“存储节点”和“数据”都映射到一个顺时针排序的哈希环上。

一致性哈希算法会尽可能保证，相同的请求被分发到相同的机器上。当出现增减节点时，只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响，不会引起剧烈变动。

相同的请求是指：一般在使用一致性哈希时，需要指定一个 key 用于 hash 计算，可能是：用户 ID、请求方 IP、请求服务名称，参数列表构成的串
尽可能是指：哈希环上出现增减节点时，少数机器的变化不应该影响大多数的请求。

（1）增加节点

如下图所示，假设，哈希环中新增了一个节点 S4，新增节点经过哈希计算映射到图中位置：

此时，只有 K1 收到影响；而 K0、K2 均不受影响。

（2）减少节点

如下图所示，假设，哈希环中减少了一个节点 S0：

此时，只有 K0 收到影响；而 K1、K2 均不受影响。

一致性哈希算法并不保证节点能够在哈希环上分布均匀，由此而产生一个问题，哈希环上可能有大量的请求集中在一个节点上。从概率角度来看，哈希环上的节点越多，分布就越均匀。正因为如此，一致性哈希算法不适用于节点数过少的场景。

如下图所示：极端情况下，可能由于节点在哈希环上分布不均，有大量请求计算得到的 key 会被集中映射到少数节点，甚至某一个节点上。此外，节点分布不均匀的情况下，进行容灾与扩容时，哈希环上的相邻节点容易受到过大影响，从而引发雪崩式的连锁反应。

虚拟一致性哈希算法

在一致性哈希算法中，如果节点数过少，可能会分布不均，从而导致负载不均衡。在实际生产环境中，一个分布式系统应该具备良好的伸缩性，既能从容的扩展到大规模的集群，也要能支持小规模的集群。为此，又产生了虚拟哈希算法，进一步对一致性哈希算法进行了改良。

虚拟哈希算法的解决思路是：虽然实际的集群可能节点数较少，但是在哈希环上引入大量的虚拟哈希节点。具体来说，“虚拟哈希算法”有二次映射：先将虚拟节点映射到哈希环上，再将虚拟节点映射到实际节点上。

如下图所示，假设存在这样的场景：

分布式集群中有 4 个真实节点，分别是：S0、S1、S2、S3；
我们不妨先假定分配给哈希环 12 个虚拟节点，并将虚拟节点映射到真实节点上，映射关系如下：
- S0 - S0_0、S0_1、S0_2、S0_3
- S1 - S1_0、S1_1、S1_2、S1_3
- S2 - S2_0、S2_1、S2_2、S2_3
- S3 - S3_0、S3_1、S3_2、S3_3

通过引入虚拟哈希节点，是的哈希环上的节点分布相对均匀了。举例来说，假如此时，某请求的 key 哈希取模后，先映射到哈希环的 [S3_2, S0_0]、[S3_0, S0_1]、[S3_1, S0_2] 这三个区间的任意一点；接下来的二次映射都会匹配到真实节点 S0。

在实际应用中，虚拟哈希节点数一般都比较大（例如：Redis 的虚拟哈希槽有 16384 个），较大的数量保证了虚拟哈希环上的节点分布足够均匀。

虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高。例如，当某个节点被移除时，分配给该节点的多个虚拟节点会被一并移除，而这些虚拟节点按顺时针方向的下一个虚拟节点，可能会对应不同的真实节点，即这些不同的真实节点共同分担了节点变化导致的压力。

此外，有了虚拟节点后，可以通过调整分配给真实节点的虚拟节点数，来达到设置权重一样的效果，使得负载均衡更加灵活。

综上所述，虚拟一致性哈希算法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。

:::

流量控制

【基础】什么是流量控制？为什么需要流量控制？

:::details 要点

流量控制（Flow Control），根据流量、并发线程数、响应时间等指标，把随机到来的流量调整成合适的形状，即流量塑形。避免应用被瞬时的流量高峰冲垮，从而保障应用的高可用性。

复杂的分布式系统架构中的应用程序往往具有数十个依赖项，每个依赖项都会不可避免地在某个时刻失败。如果主机应用程序未与这些外部故障隔离开来，则可能会被波及。

例如，对于依赖于 30 个服务的应用程序，假设每个服务的正常运行时间为 99.99％，则可以期望：

99.99³⁰ = 99.7％的正常运行时间

10 亿个请求中的 0.3％= 3,000,000 个失败

即使所有依赖项都具有出色的正常运行时间，每月也会有 2 个小时以上的停机时间。

然而，现实情况一般比这种估量情况更糟糕。

当一切正常时，整体系统如下所示：

图片来自 Hystrix Wiki

在分布式系统架构下，这些强依赖的子服务稳定与否对系统的影响非常大。但是，依赖的子服务可能有很多不可控问题：如网络连接、资源繁忙、服务宕机等。例如：下图中有一个 QPS 为 50 的依赖服务 I 出现不可用，但是其他依赖服务是可用的。

图片来自 Hystrix Wiki

当流量很大的情况下，某个依赖的阻塞，会导致上游服务请求被阻塞。当这种级联故障愈演愈烈，就可能造成整个线上服务不可用的雪崩效应，如下图。这种情况若持续恶化，如果上游服务本身还被其他服务所依赖，就可能出现多米洛骨牌效应，导致多个服务都无法正常工作。

图片来自 Hystrix Wiki

:::

【基础】流量控制有哪些衡量指标？

:::details 要点

:::

【中级】流量控制有哪些保护机制？

:::details 要点

流量控制常见的手段就是限流、熔断、降级。

什么是降级？

降级是保障服务能够稳定运行的一种保护方式：面对突增的流量，牺牲一些吞吐量以换取系统的稳定。常见的降级实现方式有：开关降级、限流降级、熔断降级。

什么是限流？

限流一般针对下游服务，当上游流量较大时，避免被上游服务的请求撑爆。

限流就是限制系统的输入和输出流量，以达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

限流规则包含三个部分：时间粒度，接口粒度，最大限流值。限流规则设置是否合理直接影响到限流是否合理有效。

什么是熔断？

熔断一般针对上游服务，当下游服务超时/异常较多时，避免被下游服务拖垮。

当调用链路中某个资源出现不稳定，例如，超时异常比例升高的时候，则对这个资源的调用进行限制，并让请求快速失败，避免影响到其它的资源，最终产生雪崩的效果。

熔断尽最大的可能去完成所有的请求，容忍一些失败，熔断也能自动恢复。熔断的常见策略有：

在每秒请求异常数超过多少时触发熔断降级
在每秒请求异常错误率超过多少时触发熔断降级
在每秒请求平均耗时超过多少时触发熔断降级

:::

流量控制有哪些衡量指标

:::details 要点

流量控制有以下几个角度：

流量指标，例如 QPS、并发线程数等。
资源的调用关系，例如资源的调用链路，资源和资源之间的关系，调用来源等。
控制效果，例如排队等待、直接拒绝、Warm Up（预热）等。

:::

【中级】流量控制有哪些隔离模式？

:::details 要点

线程池隔离

信号量隔离

资源隔离

:::

【高级】有哪些限流算法？

:::details 要点

常见的限流算法有：固定窗口限流算法、滑动窗口限流算法、漏桶限流算法、令牌桶限流算法。

固定窗口限流算法

固定窗口限流算法的原理

固定窗口限流算法的基本策略是：

设置一个固定时间窗口，以及这个固定时间窗口内的最大请求数；
为每个固定时间窗口设置一个计数器，用于统计请求数；
一旦请求数超过最大请求数，则请求会被拦截。

固定窗口限流算法的利弊

固定窗口限流算法的优点是：实现简单。

固定窗口限流算法的缺点是：存在临界问题。所谓临界问题，是指：流量分别集中在一个固定时间窗口的尾部和一个固定时间窗口的头部。举例来说，假设限流规则为每分钟不超过 100 次请求。在第一个时间窗口中，起初没有任何请求，在最后 1 s，收到 100 次请求，由于没有达到阈值，所有请求都通过；在第二个时间窗口中，第 1 秒就收到 100 次请求，而后续没有任何请求。虽然，这两个时间窗口内的流量都符合限流要求，但是在两个时间窗口临界的这 2s 内，实际上有 200 次请求，显然是超过预期吞吐量的，存在压垮系统的可能。

滑动窗口限流算法

滑动窗口限流算法的原理

滑动窗口限流算法是对固定窗口限流算法的改进，解决了临界问题。

滑动窗口限流算法的基本策略是：

将固定时间窗口分片为多个子窗口，每个子窗口的访问次数独立统计；
当请求时间大于当前子窗口的最大时间时，则将当前子窗口废弃，并将计时窗口向前滑动，并将下一个子窗口置为当前窗口。
要保证所有子窗口的统计数之和不能超过阈值。

滑动窗口限流算法就是针对固定窗口限流算法的更细粒度的控制，分片越多，则限流越精准。

滑动窗口限流算法的利弊

滑动窗口限流算法的优点是：在滑动窗口限流算法中，临界位置的突发请求都会被算到时间窗口内，因此可以解决计数器算法的临界问题。

滑动窗口限流算法的缺点是：

额外的内存开销 - 滑动时间窗口限流算法的时间窗口是持续滑动的，并且除了需要一个计数器来记录时间窗口内接口请求次数之外，还需要记录在时间窗口内每个接口请求到达的时间点，所以存在额外的内存开销。
限流的控制粒度受限于窗口分片粒度 - 滑动窗口限流算法，只能在选定的时间粒度上限流，对选定时间粒度内的更加细粒度的访问频率不做限制。但是，由于每个分片窗口都有额外的内存开销，所以也并不是分片数越多越好的。

漏桶限流算法

漏桶限流算法的原理

漏桶限流算法的基本策略是：

水（请求）以任意速率由入口进入到漏桶中；
水以固定的速率由出口出水（请求通过）；
漏桶的容量是固定的，如果水的流入速率大于流出速率，最终会导致漏桶中的水溢出（这意味着请求拒绝）。

漏桶限流算法的利弊

漏桶限流算法的优点是：流量速率固定——即无论流量多大，即便是突发的大流量，处理请求的速度始终是固定的。

漏桶限流算法的缺点是：不能灵活的调整流量。例如：一个集群通过增减节点的方式，弹性伸缩了其吞吐能力，漏桶限流算法无法随之调整。

漏桶策略适用于间隔性突发流量且流量不用即时处理的场景。

令牌桶限流算法

令牌桶限流算法的原理

令牌桶算法的原理：

接口限制 T 秒内最大访问次数为 N，则每隔 T/N 秒会放一个 token 到桶中
桶内最多存放 M 个 token，如果 token 到达时令牌桶已经满了，那么这个 token 就会被丢弃
接口请求会先从令牌桶中取 token，拿到 token 则处理接口请求，拿不到 token 则进行限流处理

令牌桶限流算法的利弊

因为令牌桶存放了很多令牌，那么大量的突发请求会被执行，但是它不会出现临界问题，在令牌用完之后，令牌是以一个恒定的速率添加到令牌桶中的，因此不能再次发送大量突发请求。

规定固定容量的桶，token 以固定速度往桶内填充，当桶满时 token 不会被继续放入，每过来一个请求把 token 从桶中移除，如果桶中没有 token 不能请求。

令牌桶算法适用于有突发特性的流量，且流量需要即时处理的场景。

扩展

Guava 的 RateLimiter 工具类就是基于令牌桶算法实现，其源码分析可以参考：RateLimiter 基于漏桶算法，但它参考了令牌桶算法

:::

网关路由

【基础】什么是服务路由？路由有什么用？

:::details 要点

服务路由是指通过一定的规则从集群中选择合适的节点。

负载均衡的作用和服务路由的功能看上去很近似，二者有什么区别呢？

负载均衡的目标是提供服务分发而不是解决路由问题，常见的静态、动态负载均衡算法无法实现精细化的路由管理，但是负载均衡也可以简单看做是路由方案的一种。

服务路由通常用于以下场景，目的在于实现流量隔离：

分组调用：一般来讲，为了保证服务的高可用性，实现异地多活的需求，一个服务往往不止部署在一个数据中心，而且出于节省成本等考虑，有些业务可能不仅在私有机房部署，还会采用公有云部署，甚至采用多家公有云部署。服务节点也会按照不同的数据中心分成不同的分组，这时对于服务消费者来说，选择哪一个分组调用，就必须有相应的路由规则。
蓝绿发布：蓝绿发布场景中，一共有两套服务群组：一套是提供旧版功能的服务群组，标记为绿色；另一套是提供新版功能的服务群组，标记为蓝色。两套服务群组都是功能完善的，并且正在运行的系统，只是服务版本和访问流量不同。新版群组（蓝色）通常是为了做内部测试、验收，不对外部用户暴露。
- 如果新版群组（蓝色）运行稳定，并测试、验收通过后，则通过服务路由、负载均衡等手段逐步将外部用户流量导向新版群组（蓝色）。
- 如果新版群组（蓝色）运行不稳定，或测试、验收不通过，则排查、解决问题后，再继续测试、验收。
灰度发布：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行 A/B 测试，即让一部分用户使用特性 A，一部分用户使用特性 B：如果用户对 B 没有什么反对意见，那么逐步扩大发布范围，直到把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。要支持灰度发布，就要求服务能够根据一定的规则，将流量隔离。
流量切换：在业务线上运行过程中，经常会遇到一些不可抗力因素导致业务故障，比如某个机房的光缆被挖断，或者发生着火等事故导致整个机房的服务都不可用。这个时候就需要按照某个指令，能够把原来调用这个机房服务的流量切换到其他正常的机房。
线下测试联调：线下测试时，可能会缺少相应环境。可以将测试应用注册到线上，然后开启路由规则，在本地进行测试。
读写分离。对于大多数互联网业务来说都是读多写少，所以在进行服务部署的时候，可以把读写分开部署，所有写接口可以部署在一起，而读接口部署在另外的节点上。

:::

服务路由有哪些常见规则？

:::details 要点

条件路由

条件路由是基于条件表达式的路由规则。各个 RPC 框架的条件路由表达式各不相同。

我们不妨参考一下 Dubbo 的条件路由。Dubbo 的条件路由有两种配置粒度，如下：

应用粒度

# app1 的消费者只能消费所有端口为 20880 的服务实例
# app2 的消费者只能消费所有端口为 20881 的服务实例
---
scope: application
force: true
runtime: true
enabled: true
key: governance-conditionrouter-consumer
conditions:
  - application=app1 => address=*:20880
  - application=app2 => address=*:20881

服务粒度

# DemoService 的 sayHello 方法只能消费所有端口为 20880 的服务实例
# DemoService 的 sayHi 方法只能消费所有端口为 20881 的服务实例
---
scope: service
force: true
runtime: true
enabled: true
key: org.apache.dubbo.samples.governance.api.DemoService
conditions:
  - method=sayHello => address=*:20880
  - method=sayHi => address=*:20881

其中，conditions 定义具体的路由规则内容。conditions 部分是规则的主体，由 1 到任意多条规则组成。详见：Dubbo 路由规则

Dubbo 的条件路由规则由两个条件组成，分别用于对服务消费者和提供者进行匹配。条件路由规则的格式如下：

1	[服务消费者匹配条件] => [服务提供者匹配条件]

服务消费者匹配条件：所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
服务提供者匹配条件：所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。

condition:// 代表了这是一段用条件表达式编写的路由规则，下面是一个条件路由规则示例：

1	host = 10.20.153.10 => host = 10.20.153.11

该条规则表示 IP 为 10.20.153.10 的服务消费者只可调用 IP 为 10.20.153.11 机器上的服务，不可调用其他机器上的服务。

下面列举一些 Dubbo 条件路由的典型应用场景：

如果服务消费者的匹配条件为空，就表示所有的服务消费者都可以访问，就像下面的表达式一样。

1	=> host != 10.20.153.11

如果服务提供者的过滤条件为空，就表示禁止所有的服务消费者访问，就像下面的表达式一样。

1	host = 10.20.153.10 =>

排除某个服务节点

1	=> host != 172.22.3.91

白名单

1	register.ip != 10.20.153.10,10.20.153.11 =>

黑名单

1	register.ip = 10.20.153.10,10.20.153.11 =>

只暴露部分机器节点

1	=> host = 172.22.3.1,172.22.3.2

为重要应用提供额外的机器节点

1	application != kylin => host != 172.22.3.95,172.22.3.96

读写分离

1 2	method = find,list,get,is => host = 172.22.3.94,172.22.3.95,172.22.3.96 method != find,list,get,is => host = 172.22.3.97,172.22.3.98

前后台分离

1 2	application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93 application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96

隔离不同机房网段

1	host != 172.22.3.* => host != 172.22.3.*

提供者与消费者部署在同集群内，本机只访问本机的服务

1	=> host = $host

脚本路由

脚本路由是基于脚本语言的路由规则，常用的脚本语言比如 JavaScript、Groovy、JRuby 等。

1 2	'script://0.0.0.0/com.foo.BarService?category=routers&dynamic=false&rule=' + URL.encode('（function route(invokers) { ... } (invokers)）')

这里面 script:// 就代表了这是一段脚本语言编写的路由规则，具体规则定义在脚本语言的 route 方法实现里，比如下面这段用 JavaScript 编写的 route() 方法表达的意思是，只有 IP 为 10.20.153.10 的服务消费者可以发起服务调用。

function route(invokers){
  var result = new java.util.ArrayList(invokers.size());
  for(i =0; i < invokers.size(); i ++){
    if("10.20.153.10".equals(invokers.get(i).getUrl().getHost())){
       result.add(invokers.get(i));
    }
  }
  return result;
 } (invokers)）;

标签路由

标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。

标签主要是指对服务提供者的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标。一般，动态规则优先级比静态规则更高，当两种规则同时存在且出现冲突时，将以动态规则为准。

以 Dubbo 的标签路由用法为例

（1）动态规则打标，可随时在服务治理控制台下发标签归组规则

# governance-tagrouter-provider 应用增加了两个标签分组 tag1 和 tag2
# tag1 包含一个实例 127.0.0.1:20880
# tag2 包含一个实例 127.0.0.1:20881
---
  force: false
  runtime: true
  enabled: true
  key: governance-tagrouter-provider
  tags:
    - name: tag1
      addresses: ["127.0.0.1:20880"]
    - name: tag2
      addresses: ["127.0.0.1:20881"]
 ...

（2）静态规则打标

1	<dubbo:provider tag="tag1"/>

1	<dubbo:service tag="tag1"/>

1	java -jar xxx-provider.jar -Ddubbo.provider.tag={the tag you want, may come from OS ENV}

（3）服务消费者指定标签路由

1	RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"tag1");

请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。

路由规则获取方式

路由规则的获取方式主要有三种：

本地静态配置：顾名思义就是路由规则存储在服务消费者本地上。服务消费者发起调用时，从本地固定位置读取路由规则，然后按照路由规则选取一个服务节点发起调用。
配置中心管理：这种方式下，所有的服务消费者都从配置中心获取路由规则，由配置中心来统一管理。
注册中心动态下发：这种方式下，一般是运维人员或者开发人员，通过服务治理平台修改路由规则，服务治理平台调用配置中心接口，把修改后的路由规则持久化到配置中心。因为服务消费者订阅了路由规则的变更，于是就会从配置中心获取最新的路由规则，按照最新的路由规则来执行。

一般来讲，服务路由最好是存储在配置中心，由配置中心来统一管理。这样的话，所有的服务消费者就不需要在本地管理服务路由，因为大部分的服务消费者并不关心服务路由的问题，或者说也不需要去了解其中的细节。通过配置中心，统一给各个服务消费者下发统一的服务路由，节省了沟通和管理成本。

但也不排除某些服务消费者有特定的需求，需要定制自己的路由规则，这个时候就适合通过本地配置来定制。

而动态下发可以理解为一种高级功能，它能够动态地修改路由规则，在某些业务场景下十分有用。比如某个数据中心存在问题，需要把调用这个数据中心的服务消费者都切换到其他数据中心，这时就可以通过动态下发的方式，向配置中心下发一条路由规则，将所有调用这个数据中心的请求都迁移到别的地方。

:::

分布式任务

【中级】在 Java 中，实现一个进程内定时任务有哪些方案？

:::details 要点

定时器有非常多的使用场景，例如生成年/月/周/日统计报表、财务对账、会员积分结算、邮件推送等，都是定时器的使用场景。定时器一般有三种表现形式：按固定周期定时执行、延迟一定时间后执行、指定某个时刻执行。

所以定时器的内部结构一般需要一个任务队列和一个异步轮询线程，并且能够提供三种基本操作：

Schedule 新增任务至任务集合；
Cancel 取消某个任务；
Run 执行到期的任务。

JDK 原生提供了三种常用的定时器实现方式，分别为 Timer、DelayedQueue 和 ScheduledThreadPoolExecutor。

JDK 内置的三种实现定时器的方式，实现思路都非常相似，都离不开任务、任务管理、任务调度三个角色。三种定时器新增和取消任务的时间复杂度都是 O(logn)，面对海量任务插入和删除的场景，这三种定时器都会遇到比较严重的性能瓶颈。对于性能要求较高的场景，一般都会采用时间轮算法来实现定时器。

Timer

Timer 属于 JDK 比较早期版本的实现，它可以实现固定周期的任务，以及延迟任务。Timer 会启动一个异步线程去执行到期的任务，任务可以只被调度执行一次，也可以周期性反复执行多次。我们先来看下 Timer 是如何使用的，示例代码如下。

Timer timer = new Timer();
timer.scheduleAtFixedRate(new TimerTask() {
    @Override
    public void run() {
        // do something
    }
}, 10000, 1000);  // 10s 后调度一个周期为 1s 的定时任务

可以看出，任务是由 TimerTask 类实现，TimerTask 是实现了 Runnable 接口的抽象类，Timer 负责调度和执行 TimerTask。接下来我们看下 Timer 的内部构造。

public class Timer {

    private final TaskQueue queue = new TaskQueue();
    private final TimerThread thread = new TimerThread(queue);

    public Timer(String name) {
        thread.setName(name);
        thread.start();
    }
}

TaskQueue 是由数组结构实现的小根堆，deadline 最近的任务位于堆顶端，queue[1] 始终是最优先被执行的任务。所以使用小根堆的数据结构，Run 操作时间复杂度 O(1)，新增（Schedule）和取消（Cancel）操作的时间复杂度都是 O(logn)。

Timer 内部启动了一个 TimerThread 异步线程，不论有多少任务被加入数组，始终都是由 TimerThread 负责处理。TimerThread 会定时轮询 TaskQueue 中的任务，如果堆顶的任务的 deadline 已到，那么执行任务；如果是周期性任务，执行完成后重新计算下一次任务的 deadline，并再次放入小根堆；如果是单次执行的任务，执行结束后会从 TaskQueue 中删除。

Timer 只使用一个线程来执行任务意味着同一时间只能有一个任务得到执行，而前一个任务的延迟或者异常会影响到之后的任务。如果有一个定时任务在运行时，产生未处理的异常，那么当前这个线程就会停止，那么所有的定时任务都会停止，受到影响。

不推荐使用 Timer ，因为 Timer 存在以下设计缺陷：

Timer 是单线程模式。如果某个 TimerTask 执行时间很久，会影响其他任务的调度。
Timer 的任务调度是基于系统绝对时间的，如果系统时间不正确，可能会出现问题。
TimerTask 如果执行出现异常，Timer 并不会捕获，会导致线程终止，其他任务永远不会执行。

ScheduledExecutorService

为了解决 Timer 的设计缺陷，JDK 提供了功能更加丰富的 ScheduledThreadPoolExecutor。ScheduledThreadPoolExecutor 提供了周期执行任务和延迟执行任务的特性。

public class ScheduledExecutorServiceTest {
    public static void main(String[] args) {
        ScheduledExecutorService executor = Executors.newScheduledThreadPool(5);
         // 1s 延迟后开始执行任务，每 2s 重复执行一次
        executor.scheduleAtFixedRate(() -> System.out.println("Hello World"), 1000, 2000, TimeUnit.MILLISECONDS);
    }
}

ScheduledThreadPoolExecutor 继承于 ThreadPoolExecutor，因此它具备线程池异步处理任务的能力。线程池主要负责管理创建和管理线程，并从自身的阻塞队列中不断获取任务执行。线程池有两个重要的角色，分别是任务和阻塞队列。ScheduledThreadPoolExecutor 在 ThreadPoolExecutor 的基础上，重新设计了任务 ScheduledFutureTask 和阻塞队列 DelayedWorkQueue。ScheduledFutureTask 继承于 FutureTask，并重写了 run() 方法，使其具备周期执行任务的能力。DelayedWorkQueue 内部是优先级队列，deadline 最近的任务在队列头部。对于周期执行的任务，在执行完会重新设置时间，并再次放入队列中。

DelayedQueue

DelayedQueue 是 JDK 中一种可以延迟获取对象的阻塞队列，其内部是采用优先级队列 PriorityQueue 存储对象。DelayQueue 中的每个对象都必须实现 Delayed 接口，并重写 compareTo 和 getDelay 方法。DelayedQueue 的使用方法如下：

public class DelayQueueTest {

    public static void main(String[] args) throws Exception {

        BlockingQueue<SampleTask> delayQueue = new DelayQueue<>();
        long now = System.currentTimeMillis();
        delayQueue.put(new SampleTask(now + 1000));
        delayQueue.put(new SampleTask(now + 2000));
        delayQueue.put(new SampleTask(now + 3000));
        for (int i = 0; i < 3; i++) {
            System.out.println(new Date(delayQueue.take().getTime()));
        }
    }

    static class SampleTask implements Delayed {

        long time;

        public SampleTask(long time) {
            this.time = time;
        }

        public long getTime() {
            return time;
        }

        @Override

        public int compareTo(Delayed o) {
            return Long.compare(this.getDelay(TimeUnit.MILLISECONDS), o.getDelay(TimeUnit.MILLISECONDS));
        }

        @Override

        public long getDelay(TimeUnit unit) {
            return unit.convert(time - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
        }
    }

}

DelayQueue 提供了 put() 和 take() 的阻塞方法，可以向队列中添加对象和取出对象。对象被添加到 DelayQueue 后，会根据 compareTo() 方法进行优先级排序。getDelay() 方法用于计算消息延迟的剩余时间，只有 getDelay <=0 时，该对象才能从 DelayQueue 中取出。

DelayQueue 在日常开发中最常用的场景就是实现重试机制。例如，接口调用失败或者请求超时后，可以将当前请求对象放入 DelayQueue，通过一个异步线程 take() 取出对象然后继续进行重试。如果还是请求失败，继续放回 DelayQueue。为了限制重试的频率，可以设置重试的最大次数以及采用指数退避算法设置对象的 deadline，如 2s、4s、8s、16s ……以此类推。

相比于 Timer，DelayQueue 只实现了任务管理的功能，需要与异步线程配合使用。DelayQueue 使用优先级队列实现任务的优先级排序，新增（Schedule）和取消（Cancel）操作的时间复杂度也是 O(logn)。

时间轮

时间轮（Timing Wheel）是 George Varghese 和 Tony Lauck 在 1996 年的论文 Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility 实现的，它在 Linux 内核中使用广泛，是 Linux 内核定时器的实现方法和基础之一。

时间轮可以理解为一种环形结构，像钟表一样被分为多个 slot 槽位。每个 slot 代表一个时间段，每个 slot 中可以存放多个任务，使用的是链表结构保存该时间段到期的所有任务。时间轮通过一个时针随着时间一个个 slot 转动，并执行 slot 中的所有到期任务。

图片 22.png

那么当时针走到第 6 个 slot 时，怎么区分每个任务是否需要立即执行，还是需要等待下一圈 round，甚至更久时间之后执行呢？所以我们需要把 round 信息保存在任务中。例如图中第 6 个 slot 的链表中包含 3 个任务，第一个任务 round=0，需要立即执行；第二个任务 round=1，需要等待 1*8=8s 后执行；第三个任务 round=2，需要等待 2*8=8s 后执行。所以当时针转动到对应 slot 时，只执行 round=0 的任务，slot 中其余任务的 round 应当减 1，等待下一个 round 之后执行。

时间轮定时器最大的优势就是，任务的新增和取消都是 O(1) 时间复杂度，而且只需要一个线程就可以驱动时间轮进行工作。

HashedWheelTimer 是 Netty 中时间轮算法的实现类。

:::

【中级】分布式定时任务有哪些方案？

:::details 要点

分布式定时任务常见方案有：

Quartz
XXL-Job
ElasticJob

Quartz

Quartz 是一个经典的开源定时调度框架。它支持进程内调度和分布式调度。

Quartz 提供两种基本作业存储类型：

RAMJobStore - 在默认情况下 Quartz 将任务调度的运行信息保存在内存中，这种方法提供了最佳的性能，因为内存中数据访问最快。不足之处是缺乏数据的持久性，当程序路途停止或系统崩溃时，所有运行的信息都会丢失。
JobStoreTX - 所有的任务信息都会保存到数据库中，可以控制事物，还有就是如果应用服务器关闭或者重启，任务信息都不会丢失，并且可以恢复因服务器关闭或者重启而导致执行失败的任务

XXL-Job

xxl-job 是一个分布式任务调度平台。

设计思想

将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。

将任务抽象成分散的 JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的 JobHandler 中业务逻辑。

因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；

系统组成

调度模块（调度中心）：
负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块；
支持可视化、简单且动态的管理调度信息，包括任务新建，更新，删除，GLUE 开发和任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器 Failover。
执行模块（执行器）：
负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效；
接收“调度中心”的执行请求、终止请求和日志请求等。

输入图片说明

ElasticJob

两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。它通过弹性调度、资源管控、以及作业治理的功能，打造一个适用于互联网场景的分布式调度解决方案，并通过开放的架构设计，提供多元化的作业生态。它的各个产品使用统一的作业 API，开发者仅需一次开发，即可随意部署。

ElasticJob 采用去中心化架构，没有作业调度中心。它以框架的形式，集成到应用中，提供调度服务。

ElasticJob-Lite 定位为轻量级无中心化解决方案，使用 jar 的形式提供分布式任务的协调服务。

ElasticJob-Cloud 采用自研 Mesos Framework 的解决方案，额外提供资源治理、应用分发以及进程隔离等功能。

ElasticJob-Cloud Architecture

ElasticJob-Lite 和 ElasticJob-Cloud 对比：

ElasticJob-Lite	ElasticJob-Cloud
无中心化	是	`否`
资源分配	不支持	`支持`
作业模式	常驻	`常驻 + 瞬时`
部署依赖	ZooKeeper	`ZooKeeper + Mesos`

ElasticJob-Cloud 的优势在于对资源细粒度治理，适用于需要削峰填谷的大数据系统。

:::

分布式协同面试

发表于 2024-12-16 更新于 2025-04-01 分类于分布式，分布式协同，分布式协同综合本文字数： 28k 阅读时长 ≈ 26 分钟

分布式协同面试

复制

【基础】什么是复制？复制有什么作用？

:::details 要点

复制主要指通过网络在多台机器上保存相同数据的副本。

复制数据，可能出于各种各样的原因：

提高可用性 - 当部分组件出现位障，系统依然可以继续工作，系统依然可以继续工作。
降低访问延迟 - 使数据在地理位置上更接近用户。
提高读吞吐量 - 扩展至多台机器以同时提供数据访问服务。

:::

【中级】复制有哪些模式？

:::details 要点

复制的模式有以下几种：

主从复制 - 所有的写入操作都发送到主节点，由主节点负责将数据更改事件发送到从节点。每个从节点都可以接收读请求，但内容可能是过期值。支持主从复制的系统：
- 数据库：Mysql、PostgreSQL、MongoDB 等
- 消息队列：Kafka、RabbitMQ 等
多主复制 - 系统存在多个主节点，每个都可以接收写请求，客户端将写请求发送到其中的一个主节点上，由该主节点负责将数据更改事件同步到其他主节点和自己的从节点。
无主复制 - 系统中不存在主节点，每一个节点都能接受客户端的写请求。此外，读取时从多个节点上并行读取，以此检测和纠正某些过期数据。支持无主复制的系统：
- 数据库：Cassandra

此外，复制还需要考虑以下问题：

同步还是异步
如何处理失败的副本
如何保证数据一致

:::

【中级】主从复制是如何工作的？

:::details 要点

最常见的解决方案就是主从复制，其原理如下：

主从复制模式中只有一个主副本（或称为主节点），其余称为从副本（或称为从节点）。

所有的写请求只能发送给主副本，主副本首先将新数据写入本地存储。
然后，主副本将数据更改作为复制的日志或更新流发送给所有从副本。每个从副本获得更新数据之后将其应用到本地，且严格保持与主副本相同的写入顺序。
读请求既可以在主副本上，也可以在从副本上执行。

再次强调，只有主副本才可以接受写请求：从客户端的角度来看，从副本都是只读的。如果由于某种原因，例如与主节点之间的网络中断而导致主节点无法连接，主从复制方案就会影响所有的写入操作。

主从复制系统

:::

【中级】同步复制、半同步复制、异步复制有什么差异？

:::details 要点

主从复制——同步和异步

一般，复制速度会非常快；但是，系统不能保证复制多久能完成。有些情况下，从节点可能落后主节点几分钟甚至更长时间，例如：从节点刚从故障中恢复；或系统已经接近最大设计上限；或节点之间的网络出现问题。

全同步复制的优缺点：

优点：只有所有从节点都完成复制，才视为成功，因此是强一致的。
缺点：即使只有一个从节点未完成复制，写入都不能视为成功。所有从节点完成复制过程之前，主节点会阻塞后续所有的写操作。

因此，把所有从节点都配置为同步复制有些不切实际。因为这样的话，任何一个同步节点的中断都会导致整个系统更新停滞不前。

全异步复制的优缺点：

优点：不管从节点上数据多么滞后，主节点总是可以继续响应写请求，系统的性能更好。
缺点：如果主节点发生故障且不可恢复，则所有尚未复制到从节点的写请求都会丢失。

还有一种折中的方案——半同步复制：只要有一个从节点或半数以上的从节点同步成功，就视为同步，直接返回结果；剩下的节点都通过异步方式同步。万一同步的从节点变得不可用或性能下降，则将另一个异步的从节点提升为同步模式。这样可以保证至少有两个节点（即主节点和一个同步从节点）拥有最新的数据副本。

:::

【中级】新的从节点如何复制主节点数据？

:::details 要点

两种不可行的方案：

由于主节点会源源不断接受新的写入数据，数据始终处于变化中，因此一次性从主节点复制数据到从节点是无法保证数据一致的。
另一种思路是：考虑锁定数据库（使其不可写）来使磁盘上的文件保持一致，但这会违反高可用的设计目标。

可行的方案：

生成主节点某时刻的快照，避免长时间锁定数据库。
将快照复制到从节点。
从节点复制主节点快照过程中，所有的数据变更写入一个日志中（这个数据变更日志在不同数据库中有着不同的称呼，Mysql 称其为 binlog；Redis 称其为 AOF）。
从节点复制完主节点的快照后，请求数据变更日志中的数据，并基于此补全数据，这个过程称为追赶，直至主从数据一致。井重复步骤 1 ～步骤 4 。

:::

【高级】如何通过主从复制技术来实现系统高可用呢？

:::details 要点

从节点失效：追赶式恢复

从节点的本地磁盘上都保存了副本收到的数据变更日志。如果从节点从故障中恢复，可以和主节点对比数据变更日志的偏移量，从而确认数据是否滞后。如果数据存在滞后，则向主节点请求数据变更日志，并补全数据。这个过程称为追赶。

主节点失效：节点切换

主节点失效后，需要选举出新主节点。然后，客户端需要更新路由，将所有写请求发送给新的主节点；其他从节点要接受来自新的主节点上的变更数据。这个过程称之为切换。

主节点切换可以手动或自动进行。自动切换的步骤通常如下：

确认主节点失效。有很多种出错可能性，很难准确检测出问题的原因。所以，大多数系统都基于超时机制来确认主节点是否失效：节点间频繁地互相发生发送心跳存活悄息，如果发现某一个节点在一段比较长时间内没有响应，即认为该节点发生失效。
选举新的主节点。基于多数派共识选主。候选节点最好与原主节点的数据差异最小，这样可以最小化数据丢失的风险。
重新配置系统使新主节点生效。客户端现在需要将写请求发送给新的主节点。原主节点若恢复，需降级处理，避免脑裂。

:::

【高级】复制日志如何实现？

:::details 要点

复制日志的视线方式：

基于语句的复制 - 将数据写操作写入日志。主要缺点是必须完全按照相同顺序执行，否则可能会产生不同的结果。
基于预写日志（WAL）传输 - 通常每个写操作都是以追加写的方式写入到日志中。主要缺点是日志描述的数据结果非常底层，如果数据库不同版本的存储格式存在差异，就可能无法兼容。
- 对于日志结构存储引擎，日志是主要的存储方式。日志段在后台压缩井支持垃圾回收。
- 对于采用覆写磁盘的 BTree 结构，每次修改会预先写入日志，如系统发生崩溃，通过索引更新的方式迅速恢复到此前一致状态。
基于行的逻辑日志复制 - 如果复制和存储引擎采用不同的日志格式，这样复制与存储的逻辑就可以剥离。这种复制日志称为逻辑日志，以区分物理存储引擎的数据表示。
基于触发器的复制 - 这种方式很灵活，可以定制化控制复制逻辑。主要缺点是复制开销更高，也更容易出错。

:::

【高级】多主复制是如何工作的？

:::details 要点

对主从复制模型进行自然的扩展，则可以配置多个主节点，每个主节点都可以接受写操作，后面复制的流程类似：处理写的每个主节点都必须将该数据更改转发到所有其他节点。这就是多主节点（也称为主－主，或主动／主动）复制。此时，每个主节点还同时扮演其他主节点的从节点。

在一个数据中心内部使用多主节点基本没有太大意义，其复杂性已经超过所能带来的好处。

但是，以下场景这种配置则是合理的：

多数据中心
离线客户端操作
协作编辑

多数据中心

有了多主节点复制模型，则可以在每个数据中心都配置主节点。在每个数据中心内，采用常规的主从复制方案；而在数据中心之间，由各个数据中心的主节点来负责同其他数据中心的主节点进行数据的交换、更新。

部署单主节点的主从复制方案与多主复制方案之间的差异

性能：对于主从复制，每个写请求都必须经由广域网传送至主节点所在的数据中心。这会大大增加写入延迟，井基本偏离了采用多数据中心的初衷（即就近访问）。而在多主节点模型中，每个写操作都可以在本地数据中心快速响应，然后采用异步复制方式将变化同步到其他数据中心。因此，对上层应用有效屏蔽了数据中心之间的网络延迟，使得终端用户所体验到的性能更好。
容忍数据中心失效：对于主从复制，如果主节点所在的数据中心发生故障，必须切换至另一个数据中心，将其中的一个从节点被提升为主节点。在多主节点模型中，每个数据中心则可以独立于其他数据中心继续运行，发生故障的数据中心在恢复之后更新到最新状态。
容忍网络问题：数据中心之间的通信通常经由广域网，它往往不如数据中心内的本地网络可靠。对于主从复制模型，由于写请求是同步操作，对数据中心之间的网络性能和稳定性等更加依赖。多主节点模型则通常采用异步复制，可以更好地容忍此类问题，例如临时网络闪断不会妨碍写请求最终成功。

:::

【高级】无主复制是如何工作的？

:::details 要点

无主复制模式，系统中不存在主节点，每一个节点都能接受客户端的写请求。此外，读取时从多个节点上并行读取，以此检测和纠正某些过期数据。

读修复和反熵

复制模型应确保所有数据最终复制到所有的副本。当一个失效的节点重新上线之后，如何赶上中间错过的那些写请求呢？

有以下两种机制：

读修复 - 客户端并行读取多个副本，根据版本识别过期返回值并更新最新值到相应副本。这种方法主要适合那些被频繁读取的场景。
反熵 - 利用后台进程不断查找副本间的数据差异，将任何缺少的数据从一个副本复制到另一个副本。与基于主节点复制的复制日志不同，反熵过程并不保证以特定的顺序复制写入，并且会引入明显的同步滞后。

QuorumNWR 算法

无主复制模式中，究竟多少个副本完成才可以认为写成功？

如果有 n 个副本，写人需要 w 个节点确认，读取必须至少查询 r 个节点，则只要 w+r>n ，读取的节点中一定会包含最新值。

并发写冲突

无主模式中，并发向多副本写操作，以及读时修复或数据回传都会导致并发写冲突。如何解决冲突呢？有以下几种机制：

最后写入者获胜（丢弃并发写入） - 每个副本总是保存最新值，允许覆盖井丢弃旧值。
Happens Before - 利用全序的逻辑时钟来确定事件发生的前后顺序。
向量时钟、版本向量时钟 - 本质上是将全序的逻辑时钟改造为维护所有副本版本号的合集，基于此合集可以进行偏序比较。

:::

分区

【基础】什么是分区？为什么要分区？

:::details 要点

分区通常是这样定义的，即每一条数据（或者每条记录，每行或每个文档）只属于某个特定分区。实际上，每个分区都可以视为一个完整的小型数据库，虽然数据库可能存在一些跨分区的操作。

在不同系统中，分区有着不同的称呼，例如它对应于 MongoDB, Elasticsearch 和 SolrCloud 中的 shard, HBase 的 region, Bigtable 中的 tablet, Cassandra 和 Riak 中的 vnode ，以及 Couch base 中的 vBucket。总体而言，分区是最普遍的术语。

数据量如果太大，单台机器进行存储和处理就会成为瓶颈，因此需要引入数据分区机制。

分区的目地是通过多台机器均匀分布数据和查询负载，避免出现热点。这需要选择合适的数据分区方案，在节点添加或删除时重新动态平衡分区。

:::

【中级】分区有哪些模式？

:::details 要点

分区通常与复制结合使用，即每个分区在多个节点都存有副本。这意味着某条记录属于特定的分区，而同样的内容会保存在不同的节点上以提高系统的容错性。

一个节点上可能存储了多个分区。每个分区都有自己的主副本，例如被分配给某节点，而从副本则分配在其他一些节点。一个节点可能既是某些分区的主副本，同时又是其他分区的从副本。

分区主要有两种模式：

基于关键字区间的分区 - 先对关键字进行排序，每个分区只负责一段包含最小到最大关键字范围的一段关键字。对关键字排序的优点是可以支持高效的区间查询，但是如果应用程序经常访问与排序一致的某段关键字，就会存在热点的风险。采用这种方怯，当分区太大时，通常将其分裂为两个子区间，从而动态地再平衡分区。典型代表：HBase
哈希分区 - 将哈希函数作用于每个关键字，每个分区负责一定范围的哈希值。这种方法打破了原关键字的顺序关系，它的区间查询效率比较低，但可以更均匀地分配负载。采用哈希分区时，通常事先创建好足够多（但固定数量）的分区，让每个节点承担多个分区，当添加或删除节点时将某些分区从一个节点迁移到另一个节点，也可以支持动态分区。典型代表：Elasticsearch、Redis。

:::

【高级】二级索引如何分区？

:::details 要点

二级索引是关系数据库的必备特性，在文档数据库中应用也非常普遍。但考虑到其复杂性，许多键值存储（如 HBase 和 Voldemort）并不支持二级索引。此外，二级索引技术也是 Solr 和 Elasticsearch 等搜索引擎数据库存在之根本。

分区不仅仅是针对数据，二级索引也需要分区。通常有两种方法：

基于文档来分区二级索引（本地索引） - 二级索引存储在与关键字相同的分区中，这意味着写入时我们只需要更新一个分区，但缺点是读取二级索引时需要在所有分区上并行执行。它广泛用于实践： MongoDB 、Riak、Cassandra、Elasticsearch 、SolrCloud 和 VoltDB 都支持基于文档分区二级索引。

基于词条来分区二级索引（全局索引） - 它是基于索引的值而进行的独立分区。二级索引中的条目可能包含来自关键字的多个分区里的记录。在写入时，不得不更新二级索引的多个分区；但读取时，则可以从单个分区直接快速提取数据。

:::

【基础】什么是分区再均衡？

:::details 要点

集群节点数变化，数据规模增长等情况，都会导致分区的分布不均。要保持分区的均衡，势必要将数据和请求进行迁移，这样一个迁移负载的过程称为分区再均衡。

:::

【高级】分区再均衡有哪些策略？

:::details 要点

固定数量的分区

创建远超实际节点数的分区数，然后为每个节点分配多个分区。接下来，如果集群中添加了一个新节点，该新节点可以从每个现有的节点上匀走几个分区，直到分区再次达到全局平衡。

选中的整个分区会在节点之间迁移，但分区的总数量仍维持不变，也不会改变关键字到分区的映射关系。这里唯一要调整的是分区与节点的对应关系。考虑到节点间通过网络传输数据总是需要些时间，这样调整可以逐步完成，在此期间，旧分区仍然可以接收读写请求。

原则上，也可以将集群中的不同的硬件配置因素考虑进来，即性能更强大的节点将分配更多的分区，从而分担更多的负载。

目前，Riak、Elasticsearch、Couchbase 和 Voldemort 都支持这种动态平衡方法。

使用该策略时，分区的数量往往在数据库创建时就确定好，之后不会改变。原则上也可以拆分和合并分区（稍后介绍），但固定数量的分区使得相关操作非常简单，因此许多采用固定分区策略的数据库决定不支持分区拆分功能。所以，在初始化时，已经充分考虑将来扩容增长的需求（未来可能拥有的最大节点数），设置一个足够大的分区数。而每个分区也有些额外的管理开销，选择过高的数字可能会有副作用。

动态分区

对于采用关键宇区间分区的数据库，如果边界设置有问题，最终可能会出现所有数据都挤在一个分区而其他分区基本为空，那么设定固定边界、固定数量的分区将非常不便：而手动去重新配置分区边界又非常繁琐。

因此，一些数据库如 HBase 和 RethinkDB 等采用了动态创建分区。当分区的数据增长超过一个可配的参数阔值（HBase 上默认值是 10GB），它就拆分为两个分区，每个承担一半的数据量。相反，如果大量数据被删除，并且分区缩小到某个阈值以下，则将其与相邻分区进行合井。该过程类似于 B 树的分裂操作。

每个分区总是分配给一个节点，而每个节点可以承载多个分区，这点与固定数量的分区一样。当一个大的分区发生分裂之后，可以将其中的一半转移到其他某节点以平衡负载。对于 HBase，分区文件的传输需要借助 HDFS。

动态分区的一个优点是分区数量可以自动适配数据总量。如果只有少量的数据，少量的分区就足够了，这样系统开销很小；如果有大量的数据，每个分区的大小则被限制在一个可配的最大值。

但是，需要注意的是，对于一个空的数据库，因为没有任何先验知识可以帮助确定分区的边界，所以会从一个分区开始。可能数据集很小，但直到达到第一个分裂点之前，所有的写入操作都必须由单个节点来处理，而其他节点则处于空闲状态。为了缓解这个问题，HBase 和 MongoDB 允许在一个空的数据库上配置一组初始分区（这被称为预分裂）。对于关键字区间分区，预分裂要求已经知道一些关键字的分布情况。

动态分区不仅适用于关键字区间分区，也适用于基于哈希的分区策略。MongoDB 从版本 2.4 开始，同时支持二者，井且都可以动态分裂分区。

按节点比例分区

采用动态分区策略，拆分和合并操作使每个分区的大小维持在设定的最小值和最大值之间，因此分区的数量与数据集的大小成正比关系。另一方面，对于固定数量的分区方式，其每个分区的大小也与数据集的大小成正比。两种情况，分区的数量都与节点数无关。

Cassandra 和 Ketama 则采用了第三种方式，使分区数与集群节点数成正比关系。换句话说，每个节点具有固定数量的分区。此时，当节点数不变时，每个分区的大小与数据集大小保持正比的增长关系；当节点数增加时，分区则会调整变得更小。较大的数据量通常需要大量的节点来存储，因此这种方法也使每个分区大小保持稳定。

当一个新节点加入集群时，它随机选择固定数量的现有分区进行分裂，然后拿走这些分区的一半数据量，将另一半数据留在原节点。随机选择可能会带来不太公平的分区分裂，但是当平均分区数量较大时（Cassandra 默认情况下，每个节点有 256 个分区），新节点最终会从现有节点中拿走相当数量的负载。Cassandra 在 3.0 时推出了改进算洁，可以避免上述不公平的分裂。

随机选择分区边界的前提要求采用基于哈希分区（可以从哈希函数产生的数字范围里设置边界）。这种方法也最符合本章开头所定义一致性哈希。一些新设计的哈希函数也可以以较低的元数据开销达到类似的效果。

:::

【高级】如何确定读写请求发往哪个节点？

:::details 要点

当数据集分布到多个节点上，需要解决一个问题：当客户端发起请求时，如何知道应该连接哪个节点？如果发生了分区再平衡，分区与节点的对应关系随之还会变化。

这其实属于一类典型的服务发现问题，任何通过网络访问的系统都有这样的需求，尤其是当服务目标支持高可用时（在多台机器上有冗余配置）。

服务发现有以下处理策略：

允许客户端链接任意的节点（例如，采用循环式的负载均衡器）。如果某节点恰好拥有所请求的分区，则直接处理该请求：否则，将请求转发到下一个合适的节点，接收答复，并将答复返回给客户端。
将所有客户端的请求都发送到一个路由层，由后者负责将请求转发到对应的分区节点上。路由层本身不处理任何请求，它仅充一个分区感知的负载均衡器。
客户端感知分区和节点分配关系。此时，客户端可以直接连接到目标节点，而不需要任何中介。

许多分布式数据系统依靠独立的协调服务（如 ZooKeeper ）跟踪集群范围内的元数据。每个节点都向 ZooKeeper 中注册自己， ZooKeeper 维护了分区到节点的最终映射关系。其他参与者（如路由层或分区感知的客户端）可以向 ZooKeeper 订阅此信息。一旦分区发生了改变，或者添加、删除节点， ZooKeeper 就会主动通知路由层，这样使路由信息保持最新状态。

例如，HBase、SolrCloud 和 Kafka 也使用 ZooKeeper 来跟踪分区分配情况。MongoDB 有类似的设计，但它依赖于自己的配置服务器和 mongos 守护进程来充当路由层。

Cassandra 和 Redis 则采用了不同的方法，它们在节点之间使用 gossip 协议来同步群集状态的变化。请求可以发送到任何节点，由该节点负责将其转发到目标分区节点。这种方式增加了数据库节点的复杂性，但是避免了对 ZooKeeper 之类的外部协调服务的依赖。

:::

共识

分布式事务

扩展：

理解分布式事务

分布式事务

【基础】什么是事务？什么是分布式事务？

:::details 要点

事务将多个读、写操作捆绑在一起成为一个逻辑操作单元。事务中的所有读写是一个执行的整体，整个事务要么成功（提交）、要么失败（中止或回滚）。

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。

分布式事务指的是事务操作跨越多个节点，并且要求满足事务的 ACID 特性。

:::

【基础】什么是 ACID？什么是 BASE？二者有何区别？

:::details 要点

ACID

ACID 是数据库事务正确执行的四个基本要素的单词缩写：

原子性（Atomicity）
- 原子是指不可分解为更小粒度的东西。事务的原子性意味着：事务中的所有操作要么全部成功，要么全部失败。
- 回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
- ACID 中的原子性并不关乎多个操作的并发性，它并没有描述多个线程试图访问相同的数据会发生什么情况，后者其实是由 ACID 的隔离性所定义。
一致性（Consistency）
- 数据库在事务执行前后都保持一致性状态。
- 在一致性状态下，所有事务对一个数据的读取结果都是相同的。
- 一致性本质上要求应用层来维护状态一致（或者恒等），应用程序有责任正确地定义事务来保持一致性。这不是数据库可以保证的事情。
隔离性（Isolation）
- 同时运行的事务互不干扰。换句话说，一个事务所做的修改在最终提交以前，对其它事务是不可见的。
持久性（Durability）
- 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
- 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。

BASE

BASE 是 基本可用（Basically Available）、软状态（Soft State） 和 最终一致性（Eventually Consistent） 三个短语的缩写。

BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

基本可用（Basically Available）分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。例如，电商在做促销时，为了保证购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。
软状态（Soft State）指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在延时。
最终一致性（Eventually Consistent）强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能达到一致的状态。

BASE vs. ACID

ACID 要求强一致性，通常运用在传统的数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。BASE 唯一可以确定的是“它不是 ACID”，此外它几乎没有承诺任何东西。

:::

【基础】什么是一致性？什么是最终一致性？

:::details 要点

一致性（Consistency）指的是多个数据副本是否能保持一致的特性。

数据一致性又可以分为以下几点：

强一致性 - 数据更新操作结果和操作响应总是一致的，即操作响应通知更新失败，那么数据一定没有被更新，而不是处于不确定状态。
最终一致性 - 即物理存储的数据可能是不一致的，终端用户访问到的数据可能也是不一致的，但系统经过一段时间的自我修复和修正，数据最终会达到一致。

在分布式领域，要实现强一致性，代价非常高昂。因此，有人基于 CAP 理论以及 BASE 理论，有人就提出了柔性事务的概念。柔性事务是指：在不影响系统整体可用性的情况下 (Basically Available 基本可用），允许系统存在数据不一致的中间状态 (Soft State 软状态），在经过数据同步的延时之后，达到最终一致性。并不是完全放弃了 ACID，而是通过放宽一致性要求，借助本地事务来实现最终分布式事务一致性的同时也保证系统的吞吐。

:::

【中级】有哪些分布式事务解决方案？各有什么利弊？

:::details 要点

分布式事务的常见方案如下：

两阶段提交（2PC） - 将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
三阶段提交（3PC） - 与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制。将二阶段的准备阶段拆分为 2 个阶段，插入了一个 preCommit 阶段，使得原先在二阶段提交中，参与者在准备之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
补偿事务（TCC）
- Try - 操作作为一阶段，负责资源的检查和预留。
- Confirm - 操作作为二阶段提交操作，执行真正的业务。
- Cancel - 是预留资源的取消。
本地消息表 - 在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。
消息事务 - 基于 MQ 的分布式事务方案其实是对本地消息表的封装。
SAGA - Saga 事务核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

分布式事务方案对比：

2PC/3PC 依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
TCC 适用于执行时间确定且较短，实时性要求高，对数据一致性要求高，比如互联网金融企业最核心的三个服务：交易、支付、账务。
本地消息表/消息事务都适用于事务中参与方支持操作幂等，对一致性要求不高，业务上能容忍数据不一致到一个人工检查周期，事务涉及的参与方、参与环节较少，业务上有对账/校验系统兜底。
Saga 事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。Saga 相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。Saga 事务较适用于补偿动作容易处理的场景。

	2PC	3PC	TCC	本地消息表	MQ 事务	SAGA
数据一致性	强	强	若	弱	弱	弱
容错性	低	低	高	高	高	高
复杂性	中	高	高	低	低	高
性能	低	低	中	中	高	中
维护成本	低	中	高	中	中	高

:::

【中级】2PC 是如何工作的？

:::details 要点

二阶段提交协议（Two-phase Commit，即 2PC）将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。二阶段提交的思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈，决定提交或回滚。

阶段 1：准备阶段

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
如参与者执行成功，给协调者反馈 yes，即可以提交；如执行失败，给协调者反馈 no，即不可提交。

阶段 2：提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚 (rollback) 消息；否则，发送提交 (commit) 消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。（注意：必须在最后阶段释放锁资源）接下来分两种情况分别讨论提交阶段的过程。

情况 1，当所有参与者均反馈 yes，提交事务。

协调者向所有参与者发出正式提交事务的请求（即 commit 请求）。

参与者执行 commit 请求，并释放整个事务期间占用的资源。

各参与者向协调者反馈 ack（应答）完成的消息。

协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况 2，当任何阶段 1 一个参与者反馈 no，中断事务。

协调者向所有参与者发出回滚请求（即 rollback 请求）。

参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。

各参与者向协调者反馈 ack 完成的消息。

协调者收到所有参与者反馈的 ack 消息后，即完成事务中断。

方案总结：

2PC 方案实现起来简单，实际项目中使用比较少，主要因为以下问题：

性能问题 - 所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
可靠性问题 - 如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。
数据一致性问题 - 在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

:::

【中级】3PC 是如何工作的？

:::details 要点

三阶段提交协议（Three-phase Commit，3PC），是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制。

阶段 1：canCommit

协调者向参与者发送 commit 请求，参与者如果可以提交就返回 yes 响应（参与者不执行事务操作），否则返回 no 响应：

协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段 2：preCommit

协调者根据阶段 1 canCommit 参与者的反应情况来决定是否可以基于事务的 preCommit 操作。根据响应情况，有以下两种可能。

情况 1：阶段 1 所有参与者均反馈 yes，参与者预执行事务。

协调者向所有参与者发出 preCommit 请求，进入准备阶段。

参与者收到 preCommit 请求后，执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。

各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。

情况 2：阶段 1 任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。

协调者向所有参与者发出 abort 请求。

无论收到协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段 3：doCommit

该阶段进行真正的事务提交，也可以分为以下两种情况：

情况 1：阶段 2 所有参与者均反馈 ack 响应，执行真正的事务提交。

如果协调者处于工作状态，则向所有参与者发出 doCommit 请求。

参与者收到 doCommit 请求后，会正式执行事务提交，并释放整个事务期间占用的资源。

各参与者向协调者反馈 ack 完成的消息。

协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况 2：任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。

如果协调者处于工作状态，向所有参与者发出 abort 请求。

参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。

各参与者向协调者反馈 ack 完成的消息。

协调者收到所有参与者反馈的 ack 消息后，即完成事务中断。

注意：进入阶段 3 后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的 doCommit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。

方案总结：

优点：相比二阶段提交，三阶段降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段 3 中协调者出现问题时，参与者会继续提交事务。
缺点：数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

:::

【中级】TCC 是如何工作的？

:::details 要点

TCC 是服务化的二阶段编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现；

Try - 操作作为一阶段，负责资源的检查和预留。
Confirm - 操作作为二阶段提交操作，执行真正的业务。
Cancel - 是预留资源的取消。

TCC 事务的 Try、Confirm、Cancel 可以理解为 SQL 事务中的 Lock、Commit、Rollback。

Try 阶段

从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC 机制中的 Try 仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：

完成所有业务检查（一致性）
预留必须业务资源（准隔离性）
Try 尝试执行业务 TCC 事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try 阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。

假设商品库存为 100，购买数量为 2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。

Confirm / Cancel 阶段

根据 Try 阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。 Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成。

Confirm：当 Try 阶段服务全部正常执行，执行确认业务逻辑操作

这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为，如果在 Try 阶段能正常的预留资源，那 Confirm 一定能完整正确的提交。Confirm 阶段也可以看成是对 Try 阶段的一个补充，Try+Confirm 一起组成了一个完整的业务逻辑。

Cancel：当 Try 阶段存在服务执行失败，进入 Cancel 阶段

Cancel 取消执行，释放 Try 阶段预留的业务资源，上面的例子中，Cancel 操作会把冻结的库存释放，并更新订单状态为取消。

方案总结

TCC 事务机制相比于上面介绍的 XA 事务机制，有以下优点：

性能提升 - 具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
数据最终一致性 - 基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
可靠性 - 解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

缺点： TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。

:::

【高级】本地消息表是如何工作的？

:::details 要点

本地消息表的核心思路是将分布式事务拆分成本地事务进行处理。

方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。

这样设计可以避免”业务处理成功 + 事务消息发送失败“，或”业务处理失败 + 事务消息发送成功“的棘手情况出现，保证 2 个系统事务的数据一致性。

事务的主动方需要额外新建事务消息表，用于记录分布式事务的消息的发生、处理状态。

整个业务处理流程如下：

步骤 1、事务主动方处理本地事务。 事务主动发在本地事务中处理业务更新操作和写消息表操作。上面例子中库存服务阶段再本地事务中完成扣减库存和写消息表（图中 1、2)。

步骤 2、事务主动方通过 MQ 通知事务被动方处理事务。消息中间件可以基于 Kafka、RocketMQ 消息队列，事务主动方法主动写消息到消息队列，事务消费方消费并处理消息队列中的消息。上面例子中，库存服务把事务待处理消息写到消息中间件，订单服务消费消息中间件的消息，完成新增订单（图中 3 - 5）。

步骤 3、事务被动方通过 MQ 返回处理结果。 上面例子中，订单服务把事务已处理消息写到消息中间件，库存服务消费中间件的消息，并将事务消息的状态更新为已完成（图中 6 - 8)

为了数据的一致性，当处理错误需要重试，事务发送方和事务接收方相关业务处理需要支持幂等。具体保存一致性的容错处理如下：

当步骤 1 处理出错，事务回滚，相当于什么都没发生。

当步骤 2、步骤 3 处理出错，由于未处理的事务消息还是保存在事务发送方，事务发送方可以定时轮询超时 d 的消息数据，再次发送消息到 MQ 进行处理。事务被动方消费事务消息重试处理。

如果是业务上的失败，事务被动方可以发消息给事务主动方进行回滚。

如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚。

方案总结

方案的优点如下：

从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖。
方案简单，容易实现。

缺点如下：

与具体的业务场景绑定，耦合性高，不可复用。
需要额外维护消息数据的传输，占用业务系统资源。
业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。

:::

【高级】消息事务是如何工作的？

:::details 要点

MQ 事务方案本质是利用 MQ 功能实现的本地消息表。事务消息需要消息队列提供相应的功能才能实现，Kafka 和 RocketMQ 都提供了事务相关功能。

Kafka 的解决方案是：直接抛出异常，让用户自行处理。用户可以在业务代码中反复重试提交，直到提交成功，或者删除之前修改的数据记录进行事务补偿。
RocketMQ 的解决方案是：通过事务反查机制来解决事务消息提交失败的问题。如果 Producer 在提交或者回滚事务消息时发生网络异常，RocketMQ 的 Broker 没有收到提交或者回滚的请求，Broker 会定期去 Producer 上反查这个事务对应的本地事务的状态，然后根据反查结果决定提交或者回滚这个事务。为了支撑这个事务反查机制，业务代码需要实现一个反查本地事务状态的接口，告知 RocketMQ 本地事务是成功还是失败。

RocketMQ 事务消息实现

事务消息是 Apache RocketMQ 提供的一种高级消息类型，支持在分布式场景下保障消息生产和本地事务的最终一致性。

事务消息处理流程

事务消息交互流程如下图所示。

生产者将消息发送至 Apache RocketMQ 服务端。
Apache RocketMQ 服务端将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息被标记为”暂不能投递”，这种状态下的消息即为半事务消息。
生产者开始执行本地事务逻辑。
生产者根据本地事务执行结果向服务端提交二次确认结果（Commit 或是 Rollback），服务端收到确认结果后处理逻辑如下：
- 二次确认结果为 Commit：服务端将半事务消息标记为可投递，并投递给消费者。
- 二次确认结果为 Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为 Unknown 未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。说明服务端回查的间隔时间和最大回查次数，请参见参数限制。
生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行处理。

MQ 事务方案总结

相比本地消息表方案，MQ 事务方案优点是：

业务解耦 - 消息数据独立存储，降低业务系统与消息系统之间的耦合。
吞吐量优于本地消息表方案。

缺点是：

一次消息发送需要两次网络请求 (half 消息 + commit/rollback 消息）
业务处理服务需要实现消息状态回查接口

:::

【高级】SAGA 事务是如何工作的？

:::details 要点

Saga 事务的核心思想是：将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序依次调用补偿操作。

Saga 事务基本协议如下：

将长事务拆分为多个有序子事务 - 每个 Saga 事务由一系列幂等的有序子事务 (sub-transaction) Ti 组成。
每个子事务 Ti 都有对应的幂等补偿动作 Ci，补偿动作用于撤销 Ti 造成的结果。

可以看到，和 TCC 相比，Saga 没有“预留”动作，它的 Ti 就是直接提交到库。

下面以下单流程为例，整个操作包括：创建订单、扣减库存、支付、增加积分 Saga 的执行顺序有两种：

事务正常执行完成 T1, T2, T3, …, Tn，例如：扣减库存 (T1)，创建订单 (T2)，支付 (T3)，依次有序完成整个事务。
事务回滚 T1, T2, …, Tj, Cj,…, C2, C1，其中 0 < j < n，例如：扣减库存 (T1)，创建订单 (T2)，支付 (T3，支付失败），支付回滚 (C3)，订单回滚 (C2)，恢复库存 (C1)。

恢复策略

Saga 定义了两种恢复策略：

向前恢复 (forward recovery)

对应于上面第一种执行顺序，适用于必须要成功的场景，失败需要进行重试，执行顺序是类似于这样的：T1, T2, …, Tj（失败）, Tj（重试）,…, Tn，其中 j 是发生错误的子事务 (sub-transaction)。该情况下不需要 Ci。

向后恢复 (backward recovery)

对应于上面提到的第二种执行顺序，其中 j 是发生错误的子事务 (sub-transaction)，这种做法的效果是撤销掉之前所有成功的子事务，使得整个 Saga 的执行结果撤销。

Saga 事务常见的有两种不同的实现方式：命令协调和事件编排。

命令协调

命令协调 (Order Orchestrator)：中央协调器负责集中处理事件的决策和业务逻辑排序。

中央协调器（Orchestrator，简称 OSO）以命令/回复的方式与每项服务进行通信，全权负责告诉每个参与者该做什么以及什么时候该做什么。

以电商订单的例子为例：

事务发起方的主业务逻辑请求 OSO 服务开启订单事务。

OSO 向库存服务请求扣减库存，库存服务回复处理结果。

OSO 向订单服务请求创建订单，订单服务回复创建结果。

OSO 向支付服务请求支付，支付服务回复处理结果。

主业务逻辑接收并处理 OSO 事务处理结果回复。

中央协调器必须事先知道执行整个订单事务所需的流程（例如通过读取配置）。如果有任何失败，它还负责通过向每个参与者发送命令来撤销之前的操作来协调分布式的回滚。基于中央协调器协调一切时，回滚要容易得多，因为协调器默认是执行正向流程，回滚时只要执行反向流程即可。

事件编排

事件编排 (Event Choreography0：没有中央协调器（没有单点风险）时，每个服务产生并观察其他服务的事件，并决定是否应采取行动。

在事件编排方法中，第一个服务执行一个事务，然后发布一个事件。该事件被一个或多个服务进行监听，这些服务再执行本地事务并发布（或不发布）新的事件。

当最后一个服务执行本地事务并且不发布任何事件时，意味着分布式事务结束，或者它发布的事件没有被任何 Saga 参与者听到都意味着事务结束。

以电商订单的例子为例：

事务发起方的主业务逻辑发布开始订单事件

库存服务监听开始订单事件，扣减库存，并发布库存已扣减事件

订单服务监听库存已扣减事件，创建订单，并发布订单已创建事件

支付服务监听订单已创建事件，进行支付，并发布订单已支付事件

主业务逻辑监听订单已支付事件并处理。

事件编排是实现 Saga 模式的自然方式，它很简单，容易理解，不需要太多的代码来构建。如果事务涉及 2 至 4 个步骤，则可能是非常合适的。

方案总结

命令协调设计的优点和缺点：

优点如下：

服务之间关系简单，避免服务之间的循环依赖关系，因为 Saga 协调器会调用 Saga 参与者，但参与者不会调用协调器
程序开发简单，只需要执行命令/回复（其实回复消息也是一种事件消息），降低参与者的复杂性。
易维护扩展，在添加新步骤时，事务复杂性保持线性，回滚更容易管理，更容易实施和测试

缺点如下：

中央协调器容易处理逻辑容易过于复杂，导致难以维护。
存在协调器单点故障风险。

事件/编排设计的优点和缺点

优点如下：

避免中央协调器单点故障风险。
当涉及的步骤较少服务开发简单，容易实现。

缺点如下：

服务之间存在循环依赖的风险。
当涉及的步骤较多，服务间关系混乱，难以追踪调测。

值得补充的是，由于 Saga 模型中没有 Prepare 阶段，因此事务间不能保证隔离性，当多个 Saga 事务操作同一资源时，就会产生更新丢失、脏数据读取等问题，这时需要在业务层控制并发，例如：在应用层面加锁，或者应用层面预先冻结资源。

:::

分布式锁

扩展：

分布式锁实现汇总

分布式锁实现原理与最佳实践 - 阿里云开发者

聊聊分布式锁 - 字节跳动技术团队

Redis、ZooKeeper、Etcd，谁有最好用的分布式锁？ - 腾讯云开发者

【初级】什么是分布式锁？为什么需要分布式锁？

:::details 要点

在计算机科学中，锁是在并发场景下用于强行限制资源访问的一种同步机制，即用于在并发控制中通过互斥手段来保证数据同步安全。

在 Java 进程中，可以使用 Lock、synchronized 等来支持并发锁。如果是同一台机器的不同进程，想要同时操作一个共享资源（例如修改同一个文件），可以使用操作系统提供的「文件锁」或「信号量」来做互斥。这些发生在同一台机器上的互斥操作，可以称为本地锁。

本地锁无法协同不同机器间的互斥操作。为了解决这个问题，需要引入分布式锁。

分布式锁，顾名思义，应用于分布式场景下，它和单进程中的锁并没有本质上的不同，只是控制对象由一个进程中的多个线程变成了多个进程中的多个线程。此外，临界区的资源也由进程内共享资源变成了分布式系统内部共享资源。

:::

【高级】实现分布式锁有哪些要点？

:::details 要点

分布式锁的实现要点如下：

互斥 - 分布式锁必须是独一无二的，表现形式为：向数据存储插入一个唯一的 key，一旦有一个线程插入这个 key，其他线程就不能再插入了。
- 保证 key 唯一性的最简单的方式是使用 UUID。
- 此外，可以参考 Snowflake ID（雪花算法），将机器地址（IP 地址、机器 ID、MAC 地址）、Jvm 进程 ID（应用 ID、服务 ID）、时间戳等关键信息拼接起来作为唯一标识。
避免死锁 - 在分布式锁的场景中，部分失败和异步网络这两个问题是同时存在的。如果一个进程获得了锁，但是这个进程与锁服务之间的网络出现了问题，导致无法通信，那么这个情况下，如果锁服务让它一直持有锁，就会导致死锁的发生。常见的解决思路都是引入超时机制，即成功申请锁后，超过一定时间，锁失效（删除 key），原因在于它们无法感知申请锁的客户端节点状态。而 ZooKeeper 由于其 znode 以目录、文件形式组织，天然就存在物理空间隔离，只要 znode 存在，即表示客户端节点还在工作，所以不存在这种问题。
可重入 - 可重入指的是：同一个线程在没有释放锁之前，能否再次获得该锁。其实现方案是：只需在加锁的时候，记录好当前获取锁的节点 + 线程组合的唯一标识，然后在后续的加锁请求时，如果当前请求的节点 + 线程的唯一标识和当前持有锁的相同，那么就直接返回加锁成功；如果不相同，则按正常加锁流程处理。
公平性 - 当多个线程请求同一锁时，它们必须按照请求的顺序来获取锁，即先来先得的原则。锁的公平性的实现也非常简单，对于被阻塞的加锁请求，我们只要先记录好它们的顺序，在锁被释放后，按顺序颁发就可以了。
重试 - 有时候，加锁失败可能只是由于网络波动、请求超时等原因，稍候就可以成功获取锁。为了应对这种情况，加锁操作需要支持重试机制。常见的做法是，设置一个加锁超时时间，在该时间范围内，不断自旋重试加锁操作，超时后再判定加锁失败。
容错 - 分布式锁若存储在单一节点，一旦该节点宕机或失联，就会导致锁失效。将分布式锁存储在多数据库实例中，加锁时并发写入 N 个节点，只要 N / 2 + 1 个节点写入成功即视为加锁成功。

:::

【中级】数据库分布式锁如何实现？

:::details 要点

数据库分布式锁原理

（1）创建锁表

CREATE TABLE `distributed_lock` (
	`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
	`resource` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '资源',
	`count` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT '锁次数，统计可重入锁',
	`desc` TEXT DEFAULT NULL COMMENT '备注',
	`create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
	`update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
	PRIMARY KEY (`id`),
	UNIQUE KEY `uniq_resource`(`resource`)
)
	ENGINE = InnoDB DEFAULT CHARSET = `utf8mb4`;

（2）获取锁

想要锁住某个方法时，执行以下 SQL：

1	insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

因为我们对 method_name 做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

成功插入则获取锁。

（3）释放锁

当方法执行完毕之后，想要释放锁的话，需要执行以下 Sql:

1	delete from methodLock where method_name ='method_name'

数据库分布式锁小结

数据库分布式锁的问题：

死锁：一旦释放锁操作失败，或持有锁的机器宕机、断连，就会导致锁记录一直存在，其他线程无法再获得锁。解决办法：为锁增加失效时间字段，启动一个定时任务，隔一段时间清除一次过期的数据。
非阻塞：因为 insert 操作一旦失败就会报错，因此未获得锁的线程并不会进入排队队列，要想获得锁就要再次触发加锁操作。解决办法：循环重试，直到插入成功，这么做会产生一定额外开销。
非重入：同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。解决办法：在数据库表中加个字段，记录当前获得锁的节点信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
单点问题：如果数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。解决办法：单点问题可以用多数据库实例，同时写入 N 个节点，N / 2 + 1 个成功就加锁成功。

数据库分布式锁的利弊：

优点：直接借助数据库，简单易懂。
缺点：会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。此外，数据库性能易成为瓶颈。

:::

【高级】ZooKeeper 分布式锁如何实现？

:::details 要点

ZooKeeper 分布式锁实现原理

ZooKeeper 分布式锁的实现基于 ZooKeeper 的两个重要特性：

顺序临时节点：ZooKeeper 的存储类似于 DNS 那样的具有层级的命名空间。ZooKeeper 节点类型可以分为持久节点（PERSISTENT）、临时节点（EPHEMERAL），每个节点还能被标记为有序性（SEQUENTIAL），一旦节点被标记为有序性，那么整个节点就具有顺序自增的特点。
Watch 机制：ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在特定事件触发的时候，ZooKeeper 服务端会将事件通知给用户。

下面是 ZooKeeper 分布式锁的工作流程：

创建一个目录节点，比如叫做 /locks；
线程 A 想获取锁，就在 /locks 目录下创建临时顺序 zk 节点；
获取 /locks目录下所有的子节点，检查是否存在比自己顺序更小的节点：若不存在，则说明当前线程创建的节点顺序最小，获取锁成功；
此时，线程 B 试图获取锁，发现自己的节点顺序不是最小，设置监听锁号在自己前一位的节点；
线程 A 处理完，删除自己的节点。线程 B 监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

ZooKeeper 分布式锁小结

ZooKeeper 分布式锁的优点是较为可靠：

避免死锁：ZooKeeper 通过临时节点 + 监听机制，可以保证：如果持有临时节点的线程主动解锁或断连，Zk 会自动删除临时节点，这意味着锁的释放。所以，不存在锁永久不释放从而导致死锁的问题。
单点问题：ZooKeeper 采用主从架构，并确保主从同步是强一致的，因此不会出现单点问题。

ZooKeeper 分布式锁的缺点是：加锁、解锁操作，本质上是对 ZooKeeper 的写操作，全部由 ZooKeeper 主节点负责。如果加锁、解锁的吞吐量很大，容易出现单点写入瓶颈。

:::

【高级】Redis 分布式锁如何实现？

:::details 要点

Redis 分布式锁实现原理

极简版本

我们先来看一下，如何实现一个极简版本的 Redis 分布式锁。

（1）加锁

Redis 中的 setnx 命令，表示当且仅当 key 不存在时，才会写入 key。由于其互斥性，所以可以基于此来实现分布式锁。

执行 setnx key val，若返回 1，表示写入成功，即加锁成功；若返回 0，表示该 key 已存在，写入失败，即加锁失败。

（2）解锁

Redis 分布式锁如何解锁呢？

很简单，删除 key 就意味着释放锁，即执行 del key 命令。

避免死锁

极简版本的解决方案有一个很大的问题：存在死锁的可能。持有锁的节点如果执行业务过程中出现异常或机器宕机，都可能导致无法释放锁。这种情况下，其他节点永远也无法再获取锁。

对于异常，在 Java 中，可以通过 try...catch...finally 来保证：最终一定会释放锁，其他编程语言也有相似的语法特性。

对于机器宕机这种情况，如何处理呢？通常的对策是：为锁加上超时机制，过期自动删除。

在 Redis 中，expire 命令可以为 key 设置一个超时时间，一旦过期，Redis 会自动删除 key。如此看来，setnx + expire 组合使用，就能解决死锁问题了。可惜，没那么简单。Redis 只能保证单一命令的原子性，不保证组合命令的原子性。

那么，Redis 中有没有一条命令可以实现 setnx + expire 的组合语义呢？还真有，可以通过下面的命令来实现：

1
2
3

# 下面两条命令是等价的
SET key val NX PX 30000
SET key val NX EX 30

参数说明：

NX：该参数表示当且仅当 key 不存在，才能写入成功
PX：超时时间，单位毫秒
EX：超时时间，单位秒

超时续期

为了避免死锁，我们为锁添加了超时时间。但这里有一个问题，如果应用加锁时，对于操作共享资源的时长估计不足，可能会出现：操作尚未执行完，但是锁没了的尴尬情况。为了解决这个问题，很自然会想到，时间不够，就续期呗。

具体来说，如何续期呢？一种方案是：加锁后，启动一个定时任务，周期性检测锁是否快要过期，如果快要过期并且操作尚未结束，就对锁进行自动续期。自行实现这个方案似乎有点繁琐，好在开源 Redis 客户端 Redisson 中已经为锁的超时续期提供了一个成熟的机制——WatchDog（看门狗）。我们可以直接拿来主义即可。

安全解锁

前文提到了，解锁的操作，实际上就是 del key。这里存在一个问题：因为没有任何判断，任何节点都可以随意删除 key，换句话说，锁可能会被其他节点释放。如何避免这个问题呢？解决方法就是：为锁添加唯一性标识来进行互斥。唯一性标识可以是 UUID，可以是雪花算法 ID 等。

在 Redis 分布式锁中，唯一性标识的具体实现就是在 set key val 时，将唯一性标识 id 作为 val 写入。解锁前，先判断 key 的 value，必须和 set 时写入的 id 值保持一致，以此确认锁归属于自己。解锁的伪代码如下：

1 2	if (redis.get("key") == id) redis.del("key");

这里依然存在一个问题，由于需要在 Redis 中，先 get，后 del 操作，所以无法保证操作的原子性。为了保证原子性，可以将这段伪代码用 lua 脚本来实现，这么做的理由是 Redis 中支持原子性的执行 lua 脚本。下面是安全解锁的 lua 脚本代码：

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

自旋重试

有时候，加锁失败可能只是由于网络波动、请求超时等原因，稍候就可以成功获取锁。为了应对这种情况，加锁操作需要支持重试机制。常见的做法是，设置一个加锁超时时间，在该时间范围内，不断自旋重试加锁操作，超时后再判定加锁失败。

下面是一个自旋重试获取锁的伪代码示例：

try {
    long begin = System.currentTimeMillis();
    while (true) {
        String result = jedis.set(lockKey, uniqId, "NX", "PX", expireTime);
        if ("OK".equals(result)) {
            // 加锁成功，执行业务操作
            return true;
        }

        long time = System.currentTimeMillis() - begin;
        if (time >= timeout) {
            return false;
        }
        try {
            Thread.sleep(50);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
} catch (Exception e) {
    // 异常处理
} finally {
    // 释放锁
}

Redis 分布式锁小结

在前文中，为了实现一个靠谱的 Redis 分布式锁，我们讨论了避免死锁、超时续期、安全解锁几个问题以及应对策略。但是，依然存在一些其他问题：

不可重入 - 同一个线程无法多次获取同一把锁。
单点问题 - Redis 主从同步存在延迟，有可能导致锁冲突。举例来说：线程一在主节点加锁，如果主节点尚未同步给从节点就发生宕机；此时，Redis 集群会选举一个从节点作为新的主节点。此时，新的主节点没有锁的数据，若有其他线程试图加锁，就可以成功获取锁，即出现同时有多个线程持有锁的情况。解决这个问题，可以使用 RedLock 算法。

Redisson 是一个流行的 Redis Java 客户端，它基于 Netty 开发，并提供了丰富的扩展功能，如：分布式计数器、分布式集合、分布式锁等。

Redisson 支持的分布式锁有多种：Lock, FairLock, MultiLock, RedLock, ReadWriteLock, Semaphore, PermitExpirableSemaphore, CountDownLatch，可以根据场景需要去选择，非常方面。一般而言，使用 Redis 分布式锁，推荐直接使用 Redisson 提供的 API，功能全面且较为可靠。

:::

【中级】RedLock 分布式锁如何实现？

:::details 要点

RedLock 分布式锁，是 Redis 的作者 Antirez 提出的一种解决方案。

扩展：RedLock 官方文档

RedLock 分布式锁原理

RedLock 分布式锁在普通 Redis 分布式锁的基础上，进行了扩展，其要点在于：

（1）加锁操作不是写入单一节点，而是同时写入多个主节点，官方推荐集群中至少有 5 个主节点。
（2）只要半数以上的主节点写入成功，即视为加锁成功。
（3）大多数节点加锁的总耗时，要小于锁设置的过期时间。
（4）解锁时，要向所有节点发起请求。

下面来逐一解释以上各要点的用意：

（1）RedLock 加锁时，为什么要同时写入多个主节点？

这是为了避免单点问题，即使有部分实例出现异常，依然可以正常提供加锁、解锁能力。

（2）为什么要半数以上的主节点写入成功，才视为加锁成功？

在分布式系统中，为了达成共识，常常采用“多数派”策略来进行决策：大多数节点认可的行为，就视为整体通过。

（3）为什么加锁成功后，还要计算加锁的累计耗时？

因为操作的是多个节点，所以耗时肯定会比操作单个实例耗时更久。而且，网络情况是复杂的，可能存在延迟、丢包、超时等情况。网络请求越多，异常发生的概率就越大。所以，即使大多数节点加锁成功，但如果加锁的累计耗时已经超过了锁的过期时间，那此时有些实例上的锁可能已经失效了，这个锁就没有意义了。

（4）解锁时，为什么要向所有节点发起请求？

因为网络环境的复杂性，可能会存在这种情况：向某主节点写入锁信息，实际写入成功，但是响应超时或丢包。

所以，释放锁时，不管之前有没有加锁成功，需要释放所有节点的锁，以保证清理节点上残留的锁。

RedLock 分布式锁小结

（1）RedLock 不能完全保证安全性

分布式系统会遇到三座大山：NPC

N：Network Delay，网络延迟；
P：Process Pause，进程暂停（GC）；
C：Clock Drift，时钟漂移。

RedLock 在遇到以上情况时，不能保证安全性。

（2）RedLock 加锁、解锁需要处理多个节点，代价太高

总结来说，已知的分布式锁，无论采用什么解决方案，在极端情况下，都无法保证百分百的安全。

:::

【高级】分布式锁如何进行技术选型？

:::details 要点

下面是主流分布式锁技术方案的对比，可以在技术选型时作为参考：

	数据库分布式锁	Redis 分布式锁	ZooKeeper 分布式锁
方案要点	1. 维护一张锁表，为锁的唯一标识字段添加唯一性约束。 2. 只要 insert 成功，即视为加锁成功。	`set lockKey randomValue NX PX/EX time` 当且仅当 key 不存在时才可以写入，并且设定超时时间，以避免死锁。	加锁本质上是在 zk 中指定目录创建顺序临时接节点，序号最小即加锁成功。节点删除时，有监听通知机制告知申请锁的线程。
方案难度	实现简单、易于理解	较为简单，但要使其更可靠，需要有一些完善策略	应用简单，但 zk 内部机制并不简单
性能	性能最差，易成为瓶颈	性能最高	性能弱于 Redis
可靠性	有锁表的风险	较为可靠（需要一些完善策略）	可靠性最高
适用场景	一般不采用	适用于高并发的场景	适用于要求可靠，但并发量不高的场景
开源实现	无	Redisson	Apache Curator

:::

分布式 ID

扩展：

如果再有人问你分布式 ID，这篇文章丢给他

理解分布式 id 生成算法 SnowFlake

Leaf——美团点评分布式 ID 生成系统

UUID 规范

百度分布式 ID

ShardingSphere 分布式主键

【初级】什么是分布式 ID？为什么需要分布式 ID？

:::details 要点

ID是Identity的缩写，用于唯一的标识一条数据。分布式 ID，顾名思义，是用于在分布式系统中唯一标识数据的ID。

传统数据库基本都支持针对单表生成唯一性的自增主键。随着数据的膨胀，单机成为了性能和容量的瓶颈。为了解决这个问题，有了分库分表技术。分库分表所要面临的第一个问题是：数据分布在不同机器上，数据库无法保证多个节点上产生的主键唯一。这就需要用到分布式 ID 了，它起到了分布式系统中全局 ID 的作用。

:::

【中级】有哪些生成分布式 ID 的方式？

:::details 要点

生成分布式 ID 主要有以下方式：

UUID - UUID 是通用唯一识别码（Universally Unique Identifier）的缩写，是一种 128 位的标识符，用 16 进制表示，需要 32 个字符。UUID 会根据运行应用的计算机网卡 MAC 地址、时间戳、命令空间等元素，通过一定的随机算法产生。
- UUID 存在 5 个版本。
- UUID 不保证全局唯一性，我们需要小心 ID 冲突（尽管这种可能性很小）。
- 优点：实现简单、生成速度较快（本地生成，不依赖其他服务）。
- 缺点：无序、长度过长、不安全（基于 MAC 地址生成 UUID 的算法，可能会造成 MAC 地址泄露）。
数据库自增主键 - 大多数数据库都支持自增主键。基于此特性，可以利用事务管理控制生成唯一 ID。
- 优点：实现简单、有序、长度较小
- 缺点：性能差、存在单点问题、不安全（可以通过 ID 递增规律推算出数据量）
数据库号段 - 一次批量生成一个 segment（号段），号段的大小由 step（步长）控制。用完之后再去数据库获取新的号段。
原子计数器 - 一些 NoSQL 数据库提供了原子性的计数器原子计数器 - 利用一些 NoSQL 数据库提供的原子性计数器，来实现分布式 ID。
- Redis incr / incrby - Redis 的 String 类型提供 INCR 和 INCRBY 命令将 key 中储存的数字原子递增。
  - 优点：高性能、有序
  - 缺点：和数据库自增序列方案的缺点类似
- ZooKeeper 顺序节点 - 利用 ZooKeeper 数据模型中的顺序节点作为分布式 ID。
  - 优点：简单、可靠性高
  - 缺点：性能不高
Snowflak（雪花算法） - Snowflake ID 生成过程包含多个组件：时间戳、机器 ID 和序列号。第一位未使用，以确保 ID 正确。此生成器不需要通过网络与 ID 生成器通信，因此速度快且可扩展。Snowflake 的实现各不相同。例如，可以将数据中心 ID 添加到“MachineID”组件中，以保证全局唯一性。

:::

分布式会话

:::details 要点

由于 Http 是一种无状态的协议，服务器单从网络连接上无从知道客户身份。

所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。

Cookie 实际上是存储在用户浏览器上的文本信息，并保留了各种跟踪的信息。生成 Cookie 后，用户后续每次请求都会携带 Cookie。

Cookie 通常有大小限制（4KB）。用户可以选择在浏览器中禁用 Cookie。

一个简单的 cookie 设置如下：

1	Set-Cookie: <cookie-name>=<cookie-value>

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

Session 是在服务器端创建和存储的。服务器上通常会生成一个唯一的会话 ID（sessionId），sessionId 附加到特定的用户会话。sessionId 以 Cookie 的形式返回到客户端。Session 可以容纳大量数据。由于 Session 数据不直接由客户端访问，因此 Session 提供了更高的安全性。

Cookie 和 Session 的主要区别可以参考以下表格：

	Cookie	Session
作用范围	保存在客户端（浏览器）	保存在服务器端
隐私策略	存储在客户端，比较容易遭到非法获取	存储在服务端，安全性相对 Cookie 要好一些
存储方式	只能保存 ASCII	可以保存任意数据类型。一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
存储大小	不能超过 4K	存储大小远高于 Cookie
生命周期	可设置为永久保存比如我们经常使用的默认登录（记住我）功能	一般失效时间较短客户端关闭或者 Session 超时都会失效。

:::

:::details 要点

既然服务端是根据 Cookie 中的信息判断用户是否登录，那么如果浏览器中禁止了 Cookie，如何保障整个机制的正常运转。

第一种方案，每次请求中都携带一个 SessionID 的参数，也可以 Post 的方式提交，也可以在请求的地址后面拼接 xxx?SessionID=123456...。
第二种方案，Token 机制。Token 机制多用于 App 客户端和服务器交互的模式，也可以用于 Web 端做用户状态管理。

Token 的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。Token 机制和 Cookie 和 Session 的使用机制比较类似。

当用户第一次登录后，服务器根据提交的用户信息生成一个 Token，响应时将 Token 返回给客户端，以后客户端只需带上这个 Token 前来请求数据即可，无需再次登录验证。

:::

【中级】分布式 Session 有几种实现方案？

:::details 要点

在分布式场景下，一个用户的 Session 如果只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另一个服务器上，该服务器没有用户的 Session，就可能导致用户需要重新进行登录等操作。

分布式 Session 的几种实现策略：

粘性 session
应用服务器间的 session 复制共享
基于缓存的 session 共享 ✅

推荐：基于缓存的 session 共享

粘性 Session

粘性 Session（Sticky Sessions）需要配置负载均衡器，使得一个用户的所有请求都路由到一个服务器节点上，这样就可以把用户的 Session 存放在该服务器节点中。

缺点：当服务器节点宕机时，将丢失该服务器节点上的所有 Session。

Session 复制共享

Session 复制共享（Session Replication）在服务器节点之间进行 Session 同步操作，这样的话用户可以访问任何一个服务器节点。

缺点：占用过多内存；同步过程占用网络带宽以及服务器处理器时间。

基于缓存的 session 共享

使用一个单独的存储服务器存储 Session 数据，可以存在 MySQL 数据库上，也可以存在 Redis 或者 Memcached 这种内存型数据库。

缺点：需要去实现存取 Session 的代码。

:::

参考资料

数据密集型应用系统设计 - 这可能是目前最好的分布式存储书籍，强力推荐【进阶】

Dubbo 面试

发表于 2024-12-12 更新于 2025-04-01 分类于分布式，分布式通信， RPC 本文字数： 25k 阅读时长 ≈ 22 分钟

Dubbo 面试

简介

【基础】Dubbo 是什么？为什么使用 Dubbo？

:::details 要点

Dubbo 是一款高性能、轻量级的开源 Java RPC 框架。

Dubbo 提供了三大核心能力：

面向接口的远程过程调用（RPC）：提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
智能容错和负载均衡：内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
服务自动注册和发现：支持多种注册中心服务，服务实例上下线实时感知。

:::

【基础】Dubbo3 有什么新特性？

:::details 要点

Dubbo3 的核心新特性：

新通信协议 - Triple - Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范。它完全兼容 gRPC 协议，支持 Request-Response、Streaming 流式等通信模型，可同时运行在 HTTP/1 和 HTTP/2 之上。
应用级服务发现
- 接口级服务发现，以接口为粒度将信息注册到注册中心。举例来说，如果有 10 个 RPC Provider，部署在 100 台机器实例上，就要注册 10 * 100 条数据。
- 应用级服务发现,，以应用为粒度将信息注册到注册中心。将信息进行了拆分：接口元数据信息、接口和应用的映射关系维护在元数据中心；应用信息维护在注册中心。这样的好处是，存储的数据量大大减少，则传输数据的 I/O 开销也随之显著减少。
Dubbo Mesh - 让 Dubbo 应用能够无缝接入 Istio 等业界主流服务网格产品。

扩展：技术创想66 | Dubbo3.0应用级服务注册原理

:::

架构

【基础】Dubbo 有哪些核心组件？

:::details 要点

节点角色：

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

调用关系：

服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

重要知识点总结：

注册中心负责服务地址的注册与查找，相当于元数据管理服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外.
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
服务提供者无状态，任意一台宕掉后，不影响使用。
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

:::

【高级】Dubbo 框架整体如何设计的？

:::details 要点

Dubbo 的整体设计原则如下：

采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。

整体设计

总设计图

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

各层说明

config 配置层：对外配置接口，以 ServiceConfig、ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 Spring 解析配置生成配置类
proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory。
registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、RegistryService。
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster、Directory、Router、LoadBalance。
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor、MonitorService。
protocol 远程调用层：封装 RPC 调用，以 Invocation、Result 为中心，扩展接口为 Protocol、Invoker、Exporter。
exchange 信息交换层：封装请求响应模式，同步转异步，以 Request、Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Server、Codec。
serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization、ObjectInput、ObjectOutput、ThreadPool。

关系说明

在 RPC 中，**Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用**，然后在 Invoker 的主过程上设置拦截点（Filter）。
图中的 Consumer 和 Provider 是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用 Client 和 Server 的原因是 Dubbo 在很多场景下都使用 Provider、Consumer、Registry、Monitor 划分逻辑拓普节点，保持统一概念。
而 Cluster 是外围概念，所以 Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。
Proxy 层封装了所有接口的透明化代理。在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
而 Remoting 实现是 Dubbo 协议的实现，如果你选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了 Request-Response 语义。
Registry 和 Monitor 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。

依赖关系

图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表层或模块，蓝色的表示与业务有交互，绿色的表示只对 Dubbo 内部交互。
图中背景方块 Consumer, Provider, Registry, Monitor 代表部署逻辑拓扑节点。
图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。
图中只包含 RPC 的层，不包含 Remoting 的层，Remoting 整体都隐含在 Protocol 中。

调用链

展开总设计图的红色调用链，如下：

总设计图的红色调用链

扩展阅读：Dubbo 框架设计

:::

【高级】Dubbo 架构是如何实现高度可扩展的？

:::details 要点

微内核+插件架构

Dubbo 的架构设计采用微内核+插件架构，高度支持可扩展。

基于扩展点，用户完全可以基于自身需求，替换 Dubbo 原生实现，来满足自身业务需求。

Admin 效果图

协议与编码扩展。通信协议、序列化编码协议等
流量管控扩展。集群容错策略、路由规则、负载均衡、限流降级、熔断策略等
服务治理扩展。注册中心、配置中心、元数据中心、分布式事务、全链路追踪、监控系统等
诊断与调优扩展。流量统计、线程池策略、日志、QoS 运维命令、健康检查、配置加载等

基于扩展的生态

Dubbo 调用链路中几乎所有核心节点都被定义为扩展点。

以上是按架构层次划分的 Dubbo 内的一些核心扩展点定义及实现，可以从三个层次来展开：

协议通信层
流量管控层
服务治理层

协议通信层

Protocol - Protocol 定义了 RPC 协议，利用这个扩展点可以实现灵活切换通信协议。Dubbo 官方提供了 Triple、gRPC、Dubbo2、REST 等 RPC 协议。
Serialization - Serialization 定义了序列化协议，利用这个扩展点可以实现灵活切换序列化协议。Dubbo 官方提供了 Fastjson、Protobuf、Hessian2、Kryo、FST 等序列化协议。

协议与编码原理图

流量管控层

Dubbo 在服务调用链路上预置了大量扩展点，通过这些扩展点用户可以控制运行态的流量走向、改变运行时调用行为等，包括 Dubbo 内置的一些负载均衡策略、流量路由策略、超时等很多流量管控能力都是通过这类扩展点实现的。

协议与编码原理图

Filter - Filter 流量拦截器是 Dubbo 服务调用之上的 AOP 设计模式，Filter 用来对每次服务调用做一些预处理、后处理动作，使用 Filter 可以完成访问日志、加解密、流量统计、参数验证等任务，Dubbo 中的很多生态适配如限流降级 Sentinel、全链路追踪 Tracing 等都是通过 Fitler 扩展实现的。Filter 以链式串联工作，彼此独立。
- 从消费端视角，它在请求发起前基于请求参数等做一些预处理工作，在接收到响应后，对响应结果做一些后置处理；
- 从提供者视角则，在接收到访问请求后，在返回响应结果前做一些预处理，
Router - Router 将符合一定条件的流量转发到特定分组的地址子集，是 Dubbo 中一些关键能力如按比例流量转发、流量隔离等的基础。每次服务调用请求都会流经一组路由器 (路由链)，每个路由器根据预先设定好的规则、全量地址列表以及当前请求上下文计算出一个地址子集，再传给下一个路由器，重复这一过程直到最后得出一个有效的地址子集。
Load Balance - 在 Dubbo 中，Load Balance 负载均衡工作在 Router 之后，对于每次服务调用，负载均衡负责在 Router 链输出的地址子集中选择一台机器实例进行访问，保证一段时间内的调用都均匀的分布在地址子集的所有机器上。Dubbo 官方提供了加权随机、加权轮询、一致性哈希、最小活跃度优先、最短响应时间优先等负载均衡策略，还提供了根据集群负载自适应调度的负载均衡算法。

服务治理层

Dubbo3 由注册中心 (服务发现)、配置中心和元数据中心构成了整个服务治理的核心。

服务治理架构图

Dubbo 很多服务治理的核心能力都是通过上图描述的几个关键组件实现的。用户通过控制面或者 Admin 下发的各种规则与配置、各类微服务集群状态的展示等都是直接与注册中心、配置中心和元数据中心交互。在具体实现或者部署上，注册中心、配置中心和元数据中心可以是同一组件，比如 Zookeeper 可同时作为注册、配置和元数据中心，Nacos 也是如此。因此，三个中心只是从架构职责上的划分，你甚至可以用同一个 Zookeeper 集群来承担所有三个职责，只需要在应用里将他们设置为同一个集群地址就可以了。

Registry - 注册中心是 Dubbo 实现服务发现能力的基础。Dubbo 官方支持 Zookeeper、Nacos、Etcd、Consul、Eureka 等注册中心。通过对 Consul、Eureka 的支持，Dubbo 也实现了与 Spring Cloud 体系在地址和通信层面的互通，让用户同时部署 Dubbo 与 Spring Cloud，或者从 Spring Cloud 迁移到 Dubbo 变得更容易。
Config Center - 配置中心是用户实现动态控制 Dubbo 行为的关键组件。Dubbo 所有的路由规则，都是先下发到配置中心保存起来，进而 Dubbo 实例通过监听配置中心的变化，收到路由规则并达到控制流量的行为。Dubbo 官方支持 Zookeeper、Nacos、Etcd、Redis、Apollo 等配置中心实现。
Metadata Center - 与配置中心相反，从用户视角来看元数据中心是只读的，元数据中心唯一的写入方是 Dubbo 进程实例，Dubbo 实例会在启动之后将一些内部状态（如服务列表、服务配置、服务定义格式等）上报到元数据中心，供一些治理能力作为数据来源，如服务测试、文档管理、服务状态展示等。Dubbo 官方支持 Zookeeper、Nacos、Etcd、Redis 等元数据中心实现。

扩展阅读：Dubbo 官方文档之扩展适配

:::

【高级】Dubbo 的 SPI 机制是如何设计的？

:::details 要点

Java SPI

SPI 全称 Service Provider Interface，旨在由第三方实现或扩展的 API，它是一种用于动态加载服务的机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。

Java 中 SPI 机制主要思想是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是解耦。

Java SPI 有四个要素：

SPI 接口：为服务提供者实现类约定的的接口或抽象类。
SPI 实现类：实际提供服务的实现类。
SPI 配置：Java SPI 机制约定的配置文件，提供查找服务实现类的逻辑。配置文件必须置于 META-INF/services 目录中，并且，文件名应与服务提供者接口的完全限定名保持一致。文件中的每一行都有一个实现服务类的详细信息，同样是服务提供者类的完全限定名称。
**ServiceLoader**：Java SPI 的核心类，用于加载 SPI 实现类。 ServiceLoader 中有各种实用方法来获取特定实现、迭代它们或重新加载服务。

Java SPI 存在一些不足：

不能按需加载，需要遍历所有的实现并实例化，然后在循环中才能找到我们需要的实现。如果不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。
并发多线程使用 ServiceLoader 类的实例是不安全的。

Dubbo SPI

正是有 Java SPI 存在以上不足点，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。

Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下。配置内容形式如下：

1 2	optimusPrime = org.apache.spi.OptimusPrime bumblebee = org.apache.spi.Bumblebee

与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样可以按需加载指定的实现类。Dubbo SPI 除了支持按需加载接口实现类，还增加了 IOC 和 AOP 等特性。

Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，可以加载指定的实现类。ExtensionLoader 的 getExtension 方法是其入口方法。

扩展阅读：

Dubbo SPI 概述

源码级深度理解 Java SPI

:::

【高级】Dubbo 中的时钟轮机制是如何设计的？

:::details 要点

JDK 中定时任务的实现

在很多开源框架中，都需要定时任务的管理功能，例如 ZooKeeper、Netty、Quartz、Kafka 以及 Linux 操作系统。

所以定时器的内部结构一般需要一个任务队列和一个异步轮询线程，并且能够提供三种基本操作：

Schedule 新增任务至任务集合；
Cancel 取消某个任务；
Run 执行到期的任务。

JDK 原生提供了三种常用的定时器实现方式，分别为 Timer、DelayedQueue 和 ScheduledThreadPoolExecutor。

时间轮的基本原理

图片 22.png

时间轮定时器最大的优势就是，任务的新增和取消都是 O(1) 时间复杂度，而且只需要一个线程就可以驱动时间轮进行工作。

Dubbo 中的时间轮

org.apache.dubbo.common.timer.HashedWheelTimer 是 Dubbo 中时间轮的算法实现。它主要应用于以下方面：

失败重试， 例如，Provider 向注册中心进行注册失败时的重试操作，或是 Consumer 向注册中心订阅时的失败重试等。
周期性定时任务， 例如，定期发送心跳请求，请求超时的处理，或是网络连接断开后的重连机制。

:::

【高级】Dubbo 中的线程模型是如何设计的？

:::details 要点

Consumer 线程模型

对 2.7.5 版本之前的 Dubbo 应用，尤其是一些消费端应用，当面临需要消费大量服务且并发数比较大的大流量场景时（典型如网关类场景），经常会出现消费端线程数分配过多的问题，具体问题讨论可参见 Need a limited Threadpool in consumer side #2013

改进后的消费端线程池模型，通过复用业务端被阻塞的线程，很好的解决了这个问题。

老的线程池模型

消费端线程池.png

我们重点关注 Consumer 部分：

业务线程发出请求，拿到一个 Future 实例。
业务线程紧接着调用 future.get 阻塞等待业务结果返回。
当业务数据返回后，交由独立的 Consumer 端线程池进行反序列化等处理，并调用 future.set 将反序列化后的业务结果置回。
业务线程拿到结果直接返回

当前线程池模型

消费端线程池新.png

业务线程发出请求，拿到一个 Future 实例。
在调用 future.get() 之前，先调用 ThreadlessExecutor.wait()，wait 会使业务线程在一个阻塞队列上等待，直到队列中被加入元素。
当业务数据返回后，生成一个 Runnable Task 并放入 ThreadlessExecutor 队列
业务线程将 Task 取出并在本线程中执行：反序列化业务数据并 set 到 Future。
业务线程拿到结果直接返回

这样，相比于老的线程池模型，由业务线程自己负责监测并解析返回结果，免去了额外的消费端线程池开销。

Provider 线程模型

Dubbo 协议的和 Triple 协议目前的线程模型还并没有对齐。

Dubbo 对 channel 上的操作抽象成了五种行为：

建立连接（connected） - 主要是的职责是在 channel 记录 read、write 的时间，以及处理建立连接后的回调逻辑，比如 dubbo 支持在断开后自定义回调的 hook（onconnect），即在该操作中执行。
断开连接（disconnected） - 主要是的职责是在 channel 移除 read、write 的时间，以及处理端开连接后的回调逻辑，比如 dubbo 支持在断开后自定义回调的 hook（ondisconnect），即在该操作中执行。
发送消息（sent） - 包括发送请求和发送响应。记录 write 的时间。
接收消息（received） - 包括接收请求和接收响应。记录 read 的时间。
异常捕获（caught） - 用于处理在 channel 上发生的各类异常。

Dubbo 框架的线程模型与以上这五种行为息息相关，Dubbo 协议 Provider 线程模型可以分为五类，也就是 AllDispatcher、DirectDispatcher、MessageOnlyDispatcher、ExecutionDispatcher、ConnectionOrderedDispatcher。

All Dispatcher

所有消息都派发到 Dubbo 线程池。

dubbo-provider-alldispatcher

在 IO 线程中执行的操作有：

sent 操作在 IO 线程上执行。
序列化响应在 IO 线程上执行。

在 Dubbo 线程中执行的操作有：

received、connected、disconnected、caught 都是在 Dubbo 线程上执行的。
反序列化请求的行为在 Dubbo 中做的。

Direct Dispatcher

所有消息都不派发到 Dubbo 线程池，全部在 IO 线程上直接执行。

dubbo-provider-directDispatcher

在 IO 线程中执行的操作有：

received、connected、disconnected、caught、sent 操作在 IO 线程上执行。
反序列化请求和序列化响应在 IO 线程上执行。

并没有在 Dubbo 线程操作的行为。

Execution Dispatcher

只有请求消息派发到 Dubbo 线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。

dubbo-provider-ExecutionDispatcher

在 IO 线程中执行的操作有：

sent、connected、disconnected、caught 操作在 IO 线程上执行。
序列化响应在 IO 线程上执行。

在 Dubbo 线程中执行的操作有：

received 都是在 Dubbo 线程上执行的。
反序列化请求的行为在 Dubbo 中做的。

Message Only Dispatcher

在 Provider 端，Message Only Dispatcher 和 Execution Dispatcher 的线程模型是一致的，所以下图和 Execution Dispatcher 的图一致，区别在 Consumer 端。见下方 Consumer 端的线程模型。

dubbo-provider-ExecutionDispatcher

在 IO 线程中执行的操作有：

sent、connected、disconnected、caught 操作在 IO 线程上执行。
序列化响应在 IO 线程上执行。

在 Dubbo 线程中执行的操作有：

received 都是在 Dubbo 线程上执行的。
反序列化请求的行为在 Dubbo 中做的。

Connection Ordered Dispatcher

dubbbo-provider-connectionOrderedDispatcher

在 IO 线程中执行的操作有：

sent 操作在 IO 线程上执行。
序列化响应在 IO 线程上执行。

在 Dubbo 线程中执行的操作有：

received、connected、disconnected、caught 都是在 Dubbo 线程上执行的。但是 connected 和 disconnected 两个行为是与其他两个行为通过线程池隔离开的。并且在 Dubbo connected thread pool 中提供了链接限制、告警灯能力。
反序列化请求的行为在 Dubbo 中做的。

:::

【中级】Dubbo 中用到哪些设计模式？

:::details 要点

单例模式

Dubbo 中大量使用单例模式来确保一些特定类在整个应用中只有一个实例。举例来说，ExtensionLoader 是 Dubbo SPI 加载器，负责管理 Dubbo 中的扩展点。ExtensionLoader 使用了单例模式来确保 ExtensionLoader 在整个应用中只有一个实例。

public class ExtensionLoader<T> {
    private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<>();

    public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
        ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
        if (loader == null) {
            EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
            loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
        }
        return loader;
    }
}

责任链模式

Dubbo 的调用链是基于责任链模式组织起来的。责任链中的每个节点实现 Filter 接口，然后由 ProtocolFilterWrapper 将所有 Filter 串连起来。Dubbo 的许多功能都是通过 Filter 扩展实现的，比如监控、日志、缓存、安全等。

装饰器模式

Dubbo 中大量用到了修饰器模式。比如 ProtocolFilterWrapper 类是对 Protocol 类的修饰。在 export 和 refer 方法中，配合责任链模式，把 Filter 组装成责任链，实现对 Protocol 功能的修饰。其他还有 ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper 等。

策略模式

Dubbo 中的负载均衡器采用了策略模式，以便灵活的替换算法。在 Dubbo 中，LoadBalance 接口定义了负载均衡的策略接口，它有以下具体实现：AdaptiveLoadBalance、ConsistentHashLoadBalance、LeastActiveLoadBalance、RandomLoadBalance、RoundRobinLoadBalance、ServerCpuLoadBalance2、ShortestResponseLoadBalance。

1
2
3

public interface LoadBalance {
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
}

抽象工厂模式

Dubbo 中的 ProxyFactory 采用了抽象工厂模式。AbstractProxyFactory 实现了 ProxyFactory 接口，并且有 JdkProxyFactory 和 JavassistProxyFactory 两个子类，可以分别生产不同序列化方式的 Proxy 和 Invoke。

代理模式

Dubbo 使用代理模式隐藏远程调用的细节。ProxyFactory 接口及其实现类负责为服务创建代理对象，使得调用者无需关心实际的服务调用过程。

适配器模式

Dubbo 中 RegistryProtocol 类负责将不同的注册中心协议适配到统一的接口 Protocol 中，以便在不同的注册中心下工作。RegistryProtocol 通过适配不同的注册中心实现，使得 Dubbo 能够在多种注册中心协议下工作，而不必修改客户端代码。

扩展：长文详解：DUBBO源码使用了哪些设计模式

:::

服务注册和发现

【基础】服务注册和发现的流程是怎样的？

:::details 要点

服务提供者注册服务的过程：

Dubbo 配置项 dubbo://registry 声明了注册中心的地址，Dubbo 会把以上配置项解析成类似下面的 URL 格式：

1	registry://multicast://224.5.6.7:1234/com.alibaba.dubbo.registry.RegistryService?export=URL.encode("dubbo://host-ip:20880/com.alibaba.dubbo.demo.DemoService")

然后基于扩展点自适应机制，通过 URL 的 registry:// 协议头识别，就会调用 RegistryProtocol 的 export 方法，将 export 参数中的提供者 URL，注册到注册中心。

服务消费者发现服务的过程：

Dubbo 配置项 dubbo://registry 声明了注册中心的地址，跟服务注册的原理类似，Dubbo 也会把以上配置项解析成下面的 URL 格式：

1	registry://multicast://224.5.6.7:1234/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode("consummer://host-ip/com.alibaba.dubbo.demo.DemoService")

然后基于扩展点自适应机制，通过 URL 的 registry:// 协议头识别，就会调用 RegistryProtocol 的 refer 方法，基于 refer 参数中的条件，查询服务 demoService 的地址。

:::

【基础】Dubbo 支持哪些注册中心？

:::details 要点

不同于传统的 Dubbo2，Dubbo3 中定义了三种中心：注册中心、配置中心、元数据中心。配置中心、元数据中心是实现 Dubbo 高阶服务治理能力会依赖的组件，如流量管控规则等，相比于注册中心通常这两个组件的配置是可选的。

配置方式如下：

dubbo
 registry
  address: nacos://localhost:8848
 config-center
  address: nacos://localhost:8848
 metadata-report
  address: nacos://localhost:8848

需要注意的是，对于部分注册中心类型（如 Zookeeper、Nacos 等），Dubbo 会默认同时将其用作元数据中心和配置中心（建议保持默认开启状态）。

Dubbo 目前支持的主流注册中心实现包括：

Zookeeper
Nacos
Redis
Consul
Etcd
更多实现

同时也支持 Kubernetes、Mesh 体系的服务发现，具体请参考使用教程 - kubernetes部署

:::

【中级】注册中心是选择 CP 还是 AP？

:::details 要点

什么是 CAP

在分布式系统领域，有一个著名的 CAP 理论。CAP 定理提出：分布式系统有三个指标，这三个指标不能同时做到：

一致性（Consistency） - 在任何给定时间，网络中的所有节点都具有完全相同（最近）的值。
可用性（Availability） - 对网络的每个请求都会返回响应，但不能保证返回的数据是最新的。
分区容错性（Partition Tolerance） - 即使任意数量的节点出现故障，网络仍会继续运行。

CAP 就是取 Consistency、Availability、Partition Tolerance 的首字母而命名。

在分布式系统中，分区容错性是一个既定的事实：因为分布式系统总会出现各种各样的问题，如由于网络原因而导致节点失联；发生机器故障；机器重启或升级等等。因此，CAP 定理实际上是要在可用性（A）和一致性（C）之间做权衡。

注册中心选 AP 还是 CP

注册中心作为服务提供者和服务消费者之间沟通的桥梁，它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。

根据 CAP 理论，三种特性无法同时达成，必须在可用性和一致性之间做取舍。于是，根据不同侧重点，注册中心可以分为 CP 和 AP 两个阵营：

CP 型注册中心 - 牺牲可用性来换取数据强一致性，最典型的例子就是 ZooKeeper，etcd，Consul 了。ZooKeeper 集群内只有一个 Leader，而且在 Leader 无法使用的时候通过算法选举出一个新的 Leader。这个 Leader 的目的就是保证写信息的时候只向这个 Leader 写入，Leader 会同步信息到 Followers，这个过程就可以保证数据的强一致性。但如果多个 ZooKeeper 之间网络出现问题，造成出现多个 Leader，发生脑裂的话，注册中心就不可用了。而 etcd 和 Consul 集群内都是通过 Raft 协议来保证强一致性，如果出现脑裂的话，注册中心也不可用。
AP 型注册中心 - 牺牲一致性（只保证最终一致性）来换取可用性，最典型的例子就是 Eureka 了。Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
CP & AP 都支持型注册中心 - Nacos的内在设计偏向于 CP，即在发生网络分区的情况下优先保证数据的一致性和分区容错性，牺牲一定的可用性。虽然 Nacos 的内在设计偏向于CP，但通过合理的配置与实践，可以在一定程度上优化其可用性。例如：调整副本数、配置同步策略。更多详情可以参考：Nacos CAP

选择 CP 还是 AP，根据实际需要来定：如果业务场景要求强一致，优先选择 CP 型注册中心；如果业务场景强调可用性，优先选择 AP 型注册中心。

:::

【基础】注册中心挂了可以继续通信吗？

可以。Dubbo 消费者在应用启动时会从注册中心拉取已注册的生产者的地址接口，并缓存在本地。每次调用时，按照本地存储的地址进行调用。

通信协议和序列化

【基础】Dubbo 支持哪些通信协议，各有什么利弊？

:::details 要点

Dubbo 框架提供了自定义的高性能 RPC 通信协议：基于 HTTP/2 的 Triple 协议和基于 TCP 的 Dubbo2 协议。除此之外，Dubbo 框架支持任意第三方通信协议，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多协议可以通过自定义扩展实现。这对于微服务实践中经常要处理的多协议通信场景非常有用。

Dubbo 框架不绑定任何通信协议，在实现上 Dubbo 对多协议的支持也非常灵活，它可以让你在一个应用内发布多个使用不同协议的服务，并且支持用同一个 port 端口对外发布所有协议。

protocols

Dubbo 官方支持的协议如下：

HTTP/2 (Triple) - Dubbo3 新增，基于 HTTP/2 并且完全兼容 gRPC 协议，原生支持 Streaming 通信语义，Triple 可同时运行在 HTTP/1 和 HTTP/2 传输协议之上，让你可以直接使用 curl、浏览器访问后端 Dubbo 服务。自 Triple 协议开始，Dubbo 还支持基于 Protocol Buffers 的服务定义与数据传输，但 Triple 实现并不绑定 IDL。Triple 具备更好的网关、代理穿透性，因此非常适合于跨网关、代理通信的部署架构，如服务网格等。更多详情见：Triple 协议详情见 Triple 协议开发任务、Triple 设计思路与协议规范。
Dubbo2 - Dubbo2 协议是基于 TCP 传输层协议之上构建的一套 RPC 通信协议，具有紧凑、灵活、高性能等特点。它是 Dubbo 的默认通信协议，采用单一长连接和 NIO 异步通信，基于 hessian 作为序列化协议。Dubbo2 协议适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。Dubbo 协议详情见 Dubbo2 协议开发任务、Dubbo2 设计思路与协议规范。
gRPC - gRPC 是谷歌开源的基于 HTTP/2 的通信协议。gRPC 的定位是通信协议与实现，是一款纯粹的 RPC 框架，而 Dubbo 定位是一款微服务框架，为微服务实践提供解决方案。在 Dubbo 体系下使用 gRPC 协议是一个非常高效和轻量的选择，它让你既能使用原生的 gRPC 协议通信，又避免了基于 gRPC 进行二次定制与开发的复杂度。gRPC 协议详情见 gRPC over Dubbo 示例。
REST - 微服务领域常用的一种通信模式是 HTTP + JSON，包括 Spring Cloud、Microprofile 等一些主流的微服务框架都默认使用的这种通信模式，Dubbo 同样提供了对基于 HTTP 的编程、通信模式的支持。REST 协议详情见 HTTP over Dubbo 示例、Dubbo 与 Spring Cloud 体系互通。
Hessian - hessian 协议用于集成 Hessian 的服务，Hessian 底层采用 Http 通讯，采用 Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 作为服务器实现。Dubbo 的 Hessian 协议可以和原生 Hessian 服务互操作，即：
- 提供者用 Dubbo 的 Hessian 协议暴露服务，消费者直接用标准 Hessian 接口调用
- 或者提供方用标准 Hessian 暴露服务，消费方用 Dubbo 的 Hessian 协议调用。
Thrift - dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展，在原生协议的基础上添加了一些额外的头信息，比如 service name，magic number 等。使用 dubbo thrift 协议同样需要使用 thrift 的 idl compiler 编译生成相应的 java 代码。

扩展：Dubbo 官方文档之通信协议

:::

负载均衡

【中级】Dubbo 支持哪些负载均衡方式？各有什么利弊？

:::details 要点

Dubbo 提供了多种均衡策略，缺省为 weighted random 基于权重的随机负载均衡策略。

具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。

目前 Dubbo 内置了如下负载均衡算法，可通过调整配置项启用。

算法	特性	备注
Weighted Random LoadBalance	加权随机	默认算法，默认权重相同
RoundRobin LoadBalance	加权轮询	借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，
LeastActive LoadBalance	最少活跃优先 + 加权随机	背后是能者多劳的思想
Shortest-Response LoadBalance	最短响应优先 + 加权随机	更加关注响应速度
ConsistentHash LoadBalance	一致性哈希	确定的入参，确定的提供者，适用于有状态请求
P2C LoadBalance	Power of Two Choice	随机选择两个节点后，继续选择“连接数”较小的那个节点。
Adaptive LoadBalance	自适应负载均衡	在 P2C 算法基础上，选择二者中 load 最小的那个节点

Dubbo 的负载均衡配置可以细粒度到服务、方法级别，且 dubbo:service 和 dubbo:reference 均可配置。

<!-- 服务端服务级别 -->
<dubbo:service interface="..." loadbalance="roundrobin" />
<!-- 客户端服务级别 -->
<dubbo:reference interface="..." loadbalance="roundrobin" />
<!-- 服务端方法级别 -->
<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
<!-- 客户端方法级别 -->
<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

Weighted Random

加权随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

RoundRobin

加权轮询，按公约后的权重设置轮询比率，循环调用节点
缺点：同样存在慢的提供者累积请求的问题。

LeastActive

加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。

ShortestResponse

加权最短响应优先，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。
使得响应时间越快的提供者，处理更多的请求。
缺点：可能会造成流量过于集中于高性能节点的问题。

这里的响应时间 = 某个提供者在窗口时间内的平均响应时间，窗口时间默认是 30s。

ConsistentHash

一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：Consistent Hashing | WIKIPEDIA
缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

P2C Load Balance

Power of Two Choice 算法简单但是经典，主要思路如下：

对于每次调用，从可用的 provider 列表中做两次随机选择，选出两个节点 providerA 和 providerB。
比较 providerA 和 providerB 两个节点，选择其“当前正在处理的连接数”较小的那个节点。

以下是 Dubbo P2C 算法实现提案

Adaptive Load Balance

Adaptive 即自适应负载均衡，是一种能根据后端实例负载自动调整流量分布的算法实现，它总是尝试将请求转发到负载最小的节点。

以下是 Dubbo Adaptive 算法实现提案

扩展：

Dubbo 官方文档之负载均衡

负载均衡

:::

路由

【中级】Dubbo 路由是怎样工作的？

:::details 要点

以下是 Dubbo 单个路由器的工作过程，路由器接收一个服务的实例地址集合作为输入，基于请求上下文 (Request Context) 和 (Router Rule) 实际的路由规则定义对输入地址进行匹配，所有匹配成功的实例组成一个地址子集，最终地址子集作为输出结果继续交给下一个路由器或者负载均衡组件处理。

Router

通常，在 Dubbo 中，多个路由器组成一条路由链共同协作，前一个路由器的输出作为另一个路由器的输入，经过层层路由规则筛选后，最终生成有效的地址集合。

Dubbo 中的每个服务都有一条完全独立的路由链，每个服务的路由链组成可能不通，处理的规则各异，各个服务间互不影响。
对单条路由链而言，即使每次输入的地址集合相同，根据每次请求上下文的不同，生成的地址子集结果也可能不同。

Router

:::

【中级】Dubbo 支持哪些路由方式？分别适用于什么场景？

:::details 要点

Dubbo 的路由规则可以基于应用、服务、方法、参数等粒度精准的控制请求分发，根据请求的目标服务、方法以及请求体中的其他附加参数进行匹配，符合匹配条件的请求会进一步的按照特定规则转发到一个地址子集。

Dubbo 支持以下路由规则：

标签路由规则
条件路由规则
脚本路由规则
动态配置规则

标签路由规则

标签路由通过将某一个服务的实例划分到不同的分组，约束具有特定标签的流量只能在指定分组中流转，不同分组为不同的流量场景服务，从而实现流量隔离的目的。标签路由可以作为蓝绿发布、灰度发布等场景能力的基础。

标签路由规则是一个非此即彼的流量隔离方案，也就是匹配标签的请求会 100% 转发到有相同标签的实例，没有匹配标签的请求会 100% 转发到其余未匹配的实例。如果您需要按比例的流量调度方案，请参考示例基于权重的按比例流量路由。

标签主要是指对 Provider 端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标。动态规则打标可以在运行时动态的圈住一组机器实例，而静态规则打标则需要实例重启后才能生效，其中，动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

条件路由规则

条件路由与标签路由的工作模式非常相似，也是首先对请求中的参数进行匹配，符合匹配条件的请求将被转发到包含特定实例地址列表的子集。相比于标签路由，条件路由的匹配方式更灵活：

在标签路由中，一旦给某一台或几台机器实例打了标签，则这部分实例就会被立马从通用流量集合中移除，不同标签之间不会再有交集。有点类似下图，地址集合在输入阶段就已经划分明确。

tag-condition-compare

而从条件路由的视角，所有的实例都是一致的，路由过程中不存在分组隔离的问题，每次路由过滤都是基于全量地址中执行

tag-condition-compare

条件路由规则的主体 conditions 主要包含两部分内容：

=> 之前的为请求参数匹配条件，指定的匹配条件指定的参数将与消费者的请求上下文 (URL)、甚至方法参数进行对比，当消费者满足匹配条件时，对该消费者执行后面的地址子集过滤规则。
=> 之后的为地址子集过滤条件，指定的过滤条件指定的参数将与**提供者实例地址 (URL)**进行对比，消费者最终只能拿到符合过滤条件的实例列表，从而确保流量只会发送到符合条件的地址子集。
- 如果匹配条件为空，表示对所有请求生效，如：=> status != staging
- 如果过滤条件为空，表示禁止来自相应请求的访问，如：application = product =>

动态配置规则

通过 Dubbo 提供的动态配置规则，可以动态的修改 Dubbo 服务进程的运行时行为，整个过程不需要重启，配置参数实时生效。基于这个强大的功能，基本上所有运行期参数都可以动态调整，比如超时时间、临时开启 Access Log、修改 Tracing 采样率、调整限流降级参数、负载均衡、线程池配置、日志等级、给机器实例动态打标签等。与上文讲到的流量管控规则类似，动态配置规则支持应用、服务两个粒度，也就是说一次可以选择只调整应用中的某一个或几个服务的参数配置。

当然，出于系统稳定性、安全性的考量，有些特定的参数是不允许动态修改的，但除此之外，基本上所有参数都允许动态修改，很多强大的运行态能力都可以通过这个规则实现。通常 URL 地址中的参数均可以修改，这在每个语言实现的参考手册里也记录了一些更详细的说明。

脚本路由规则

脚本路由是最直观的路由方式，同时它也是当前最灵活的路由规则，因为你可以在脚本中定义任意的地址筛选规则。如果我们为某个服务定义一条脚本规则，则后续所有请求都会先执行一遍这个脚本，脚本过滤出来的地址即为请求允许发送到的、有效的地址集合。

configVersion: v3.0
key: demo-provider
type: javascript
enabled: true
script: |
  (function route(invokers,invocation,context) {
      var result = new java.util.ArrayList(invokers.size());
      for (i = 0; i < invokers.size(); i ++) {
          if ("10.20.3.3".equals(invokers.get(i).getUrl().getHost())) {
              result.add(invokers.get(i));
          }
      }
      return result;
  } (invokers, invocation, context)); // 表示立即执行方法

:::

服务治理

【中级】Dubbo 有哪些集群容错策略？

:::details 要点

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

Dubbo 容错

图中节点关系说明：

这里的 Invoker 是 Provider 的一个可调用 Service 的抽象，Invoker 封装了 Provider 地址及 Service 接口信息
Directory 代表多个 Invoker，可以把它看成 List<Invoker> ，但与 List 不同的是，它的值可能是动态变化的，比如注册中心推送变更
Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个
Router 负责从多个 Invoker 中按路由规则选出子集，比如读写分离，应用隔离等
LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选

Dubbo 支持的容错策略：

Failover - 失败自动切换。当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast - 快速失败。只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe - 失败安全。出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback - 失败自动恢复。后台记录失败请求，定时重发。通常用于消息通知操作。
Forking - 并行调用多个服务器。只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast - 广播调用所有提供者。逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

集群容错配置示例：

1 2	<dubbo:service cluster="failsafe" /> <dubbo:reference cluster="failsafe" />

:::

【中级】Dubbo 提供了哪些监控能力？

:::details 要点

Dubbo 内部维护了多个纬度的可观测指标，并且支持多种方式的可视化监测。可观测性指标从总体上来说分为三个度量纬度：

Admin - Admin 控制台可视化展示了集群中的应用、服务、实例及依赖关系，支持流量治理规则下发，同时还提供如服务测试、mock、文档管理等提升研发测试效率的工具。
Metrics - Dubbo 统计了一系列的流量指标如 QPS、RT、成功请求数、失败请求数等，还包括一系列的内部组件状态如线程池数、服务健康状态等。
Tracing - Dubbo 与业界主流的链路追踪工作做了适配，包括 Skywalking、Zipkin、Jaeger 都支持 Dubbo 服务的链路追踪。
Logging - Dubbo 支持多种日志框架适配。以 Java 体系为例，支持包括 Slf4j、Log4j2、Log4j、Logback、Jcl 等，用户可以基于业务需要选择合适的框架；同时 Dubbo 还支持 Access Log 记录请求踪迹。

:::

应用

【基础】接口不同版本如何兼容？

:::details 要点

版本和分组

Dubbo服务中，接口并不能唯一确定一个服务，只有 接口+分组+版本号 的三元组才能唯一确定一个服务。

当同一个接口针对不同的业务场景、不同的使用需求或者不同的功能模块等场景，可使用服务分组来区分不同的实现方式。同时，这些不同实现所提供的服务是可并存的，也支持互相调用。
当接口实现需要升级又要保留原有实现的情况下，即出现不兼容升级时，我们可以使用不同版本号进行区分。

下面以官方示例来解释一下如何指定版本。

假设，接口定义如下：

1
2
3

public interface DevelopService {
    String invoke(String param);
}

版本 1 实现：

@DubboService(group = "group1", version = "1.0")
public class DevelopProviderServiceV1 implements DevelopService{
    @Override
    public String invoke(String param) {
        StringBuilder s = new StringBuilder();
        s.append("ServiceV1 param:").append(param);
        return s.toString();
    }
}

版本 2 实现：

@DubboService(group = "group2", version = "2.0")
public class DevelopProviderServiceV2 implements DevelopService{
    @Override
    public String invoke(String param) {
        StringBuilder s = new StringBuilder();
        s.append("ServiceV2 param:").append(param);
        return s.toString();
    }
}

跨版本升级

可以按照以下的步骤进行版本迁移：

在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

参考用例 https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-version

服务提供者

老版本服务提供者配置：

1	<dubbo:service interface="com.foo.BarService" version="1.0.0" />

新版本服务提供者配置：

1	<dubbo:service interface="com.foo.BarService" version="2.0.0" />

服务消费者

老版本服务消费者配置：

1	<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

新版本服务消费者配置：

1	<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

不区分版本

如果不需要区分版本，可以按照以下的方式配置：

1	<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

通过以上描述，可以看到，通过版本号来进行 Dubbo 接口升级实际上较为麻烦。如果接口提供方和消费方分属不同的业务团队，同步发版就更加麻烦了。因此，在实际应用中，更常见的操作是应该尽量充分考虑接口的后向兼容性，确保不会影响旧版本的调用。需要考虑的点如下：

如果方法签名无任何变化，不会影响旧版本的调用。服务提供方可以直接先全量上线。
如果入参、出参上新增属性，不会影响旧版本的调用（当然，对于新增属性的逻辑处理要充分考虑兼容性）。服务提供方可以直接先全量上线，消费方根据需要选择是否后续安排对接。
如果入参、出参上删除或修改属性，老接口无法正常调用，会出现序列化问题。这种情况，可以添加新的方法来实现。

扩展阅读：Dubbo 官方文档之版本与分组

:::

参考资料

Elasticsearch 架构

发表于 2024-11-25 更新于 2025-04-01 分类于数据库，搜索引擎数据库， elasticsearch 本文字数： 6.5k 阅读时长 ≈ 6 分钟

Elasticsearch 架构

存储流程

ES 存储数据的流程可以从三个角度来阐述：

从集群的角度来看，数据写入会先路由到主分片，在主分片上写入成功后，会并发写副本分片，最后响应给客户端。
从分片的角度来看，数据到达分片后需要对内容进行格式校验、分词处理然后再索引数据。
从节点的角度来看，ES 数据持久化的步骤可归纳为：Refresh、写 Translog、Flush、Merge。

文档分布式存储流程

ES 的索引有一个或者多个分片，而分片又分为主分片和副本分片两种。将要写入的数据存储在哪个分片是第一个要考虑的问题。

首先需要找到存储文档的主分片，并在主分片的节点上写入对应数据，数据在主分片写入成功后再将数据分发到副分片进行存储。文档的新增、更新、删除等操作都属于写入操作。

从集群层面来看，存储数据的流程如下：

请求 - 客户端选择一个 node（示例中是 node1）发送请求过去，这个 node 就是 coordinating node（协调节点）。
路由转发 - coordinating node 根据文档 ID 或 routing key 计算出文档应该被保存到哪个分片（这里是分片 3），并且从集群状态的路由表信息中获取分片 3 的主分片所在的节点为 node3。coordinating node 将请求转发给 node3。
复制 - node3 存储数据后，将请求并发转发到分片 3 的所有副本分片，即数据复制。
响应 - 当所有副分片都写入成功后，node3 会向 coordinating node 返回写入成功的消息，coordinating node 再将响应返回给客户端。

数据索引流程

文档分布式存储流程中的描述，隐藏了一个细节：如果是全文本数据，ES 需要使用 analyzer（分析器） 先对内容进行分析（如果数据是精确值，如实体 ID、日期等，则无需处理）。

在 Elasticsearch 中，分析器是用于对文本进行分词的组件。分析器用于将文本分解为更小的单元，称为分词。然后，这些分词用于索引和搜索文本。分析器的主要目标是将原始文本转换为可以有效搜索和分析的结构化格式（分词）。

analyzer（分析器） 由三个组件组成：零个或多个 Character Filters（字符过滤器）、有且仅有一个 Tokenizer（分词器）、零个或多个 Token Filters（分词过滤器）。分析的执行顺序为：character filters -> tokenizer -> token filters。

对全文本数据来说，数据索引时会对文本内容进行分析处理，分析器的处理流程如下：

character flters 先对字符进行过滤，例如：把一些 HTML 元素、转义标签清除；
tokenizer 会将字符串按不同的策略进行切分，分割得到的单词称为 token（词条）；
token filters 对 token 再进行过滤，例如：删除停用词（and、is 等），转换近义词等；

经过以上一系列处理后，ES 会将数据存储到名为倒排索引的结构中。

当需要全文检索存储数据时，需要先使用搜索分析器对搜索内容进行分析，这个处理过程和存储时使用的分析器相似。通过分析得到的分词列表，再去和倒排索引中的数据去进行匹配，最后返回匹配度最高的数据。

数据持久化流程

ES 的数据持久化流程主要有以下几个过程：Refresh、写 Translog、Flush、Merge。

Refresh

在文档写入的时候，ES 会将文档先写入到 Index Buffer 中。

当 Index Buffer 大小达到阈值（默认为 JVM 的 10%），或间隔一段时间（默认每秒执行一次，可以通过 index.refresh_interval 进行设置），ES 会将 Index Buffer 中的数据写入到一个新的 Segment 文件中。此时的 Segment 文件存在于 OS Cache 中。这个过程称为 Refresh。

refresh 写完 segment 后，会更新 shard 的 commit point。commit point 在 shard 中以 segments_xxx 形式名字的文件存在，用来记录每个 shard 中 segment 相关的信息。

此外，ES 也支持通过 API 手动触发 Refresh 操作。

Refresh 过程有几点需要注意：

在 Index Buffer 中的数据是搜索不到的；Refresh 后，数据进入 OS Cache，这时数据就可以搜索了。由于，刷新默认间隔一秒，写入的数据需要一秒后才可见，因此，ES 被称为近实时搜索数据库。
Index Buffer 的设计是为了通过批量写入，提高写入效率。但是，这种设计也带来了新的问题：一旦 ES 节点发生断点，Index Buffer 中的数据就丢失了。为了避免数据丢失，ES 的解决方案就是下文要提到的 Translog。
Index Buffer 每次 Refresh 时，都会创建一个新的 Segment 文件。随着时间推移，Segment 文件会越来越多。这些 Segment 都要消耗文件句柄和内存，每次搜索都要检查每个 Segment 然后再合并结果。因此，Segment 越多、搜索也越慢。为了减少 Segment 文件数，ES 的解决方案就是下文要提到的 Merge 操作。

写 Translog

ES 通过 Translog（事务日志）来保证数据不丢失。

数据写入 Index Buffer 后，ES 会将数据也写入 Translog，写入完毕后即可以返回客户端写入成功。Translog 只允许追加写入，并且默认是调用 fsync 进行刷盘的。每个分片都会有自己的 Translog，在 Refresh 的时候系统会清空 Index Buffer，但不会清空 Translog。一旦机器宕机，再次重启的时候， ES 会自动读取 Translog 中的数据，恢复到 Index Buffer 和 OS Cache 中。

Translog 其实也是先写入 OS Cache 的，默认每 5 秒刷一次到磁盘中去（由 index.translog.interval 控制）。所以，如果机器宕机，可能会丢失 5 秒的数据。这样设计的目的，还是基于写入效率的考虑。如果每条数据都直接写入磁盘，开销是比较高的，所以这里设计为延时批量写入。

通过 Refresh 和写 Translog 两节的内容，我们可以总结为：

ES 之所以被称为近实时查询，是由于数据写入后，需要刷新（默认间隔 1 秒）后，才可以搜索到；

ES 虽然有 Translog 机制，但依然有丢失数据的风险——有 5 秒的数据，是暂存在 index buffer、translog(os cache)、segment file(os cache) 中，此时尚未保存到磁盘。如果此时发生宕机或断电，会丢失 5 秒的数据。

Flush

Flush 操作本质上就是 commit 操作，即 ES 的数据持久化操作。

Flush 操作的第一步，就是将 index buffer 中现有数据 refresh 到 OS Cache 中去，清空 buffer。
然后，将一个 commit point 写入磁盘文件，里面标识着这个 commit point 对应的所有 Segment 文件。同时，强行将 OS Cache 中目前所有的数据都 fsync 到磁盘中去。
最后，删除当前的 translog，新建一个 translog，此时 commit 操作完成。

以下两个条件满足任意一个，就会触发 Flush 操作：

默认每 30 分钟触发执行一次（由 index.translog.flush_threshold_period 控制）
Translog 写满时触发执行，默认容量为 512M（由 index.translog.flush_threshold_size 控制）。

Merge

Elasticsearch 的 document 的物理存储是 Luncene segment，而 segment 不允许变更。那么，如何处理删除和更新呢？

如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。
如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。

Index Buffer 每次 Refresh 时，都会创建一个新的 Segment 文件。随着时间推移，Segment 文件会越来越多。这些 Segment 都要消耗文件句柄和内存，每次搜索都要检查每个 Segment 然后再合并结果。因此，Segment 越多、搜索也越慢。

Elasticsearch 会定期执行 merge 操作，将多个 segment file 合并成一个。合并时会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘，这里会写一个 commit point，标识所有新的 segment file，然后打开 segment file 供搜索使用，同时删除旧的 segment file。

搜索流程

在 Elasticsearch 中，搜索一般分为两个阶段，query 和 fetch 阶段。可以简单的理解，query 阶段确定要取哪些 doc，fetch 阶段取出具体的 doc。

Query 阶段

Query 阶段会根据搜索条件遍历每个分片（主分片或者副分片中的其一）中的数据，返回符合条件的前 N 条数据的 ID 和排序值，然后在协调节点中对所有分片的数据进行排序，获取前 N 条数据的 ID。

Query 阶段的流程如下：

客户端选择一个节点发送请求，这个 node 成为 coordinate node（协调节点）。coordinate node 创建一个大小为 from + size 的优先级队列用来存放结果。
coordinate node 将请求转发到索引的每个主分片或者副分片中。
每个分片在本地执行搜索请求，并将查询结果打分排序，然后将结果保存到 from + size 大小的有序队列中。
接着，每个分片将结果返回给 coordinate node，coordinate node 对数据进行汇总处理：合并、排序、分页，将汇总数据存到一个大小为 from + size 的全局有序队列。

需要注意的是，在协调节点转发搜索请求的时候，如果有 N 个 Shard 位于同一个节点时，并不会合并这些请求，而是发生 N 次请求！

Fetch 阶段

在 Fetch 阶段，协调节点会从 Query 阶段产生的全局排序列表中确定需要取回的文档 ID 列表，然后通过路由算法计算出各个文档对应的分片，并且用 multi get 的方式到对应的分片上获取文档数据。

Fetch 阶段的流程如下：

coordinate node 确定需要获取哪些文档，然后向相关节点发起 multi get 请求；
分片所在节点读取文档数据，并且进行 _source 字段过滤、处理高亮参数等，然后把处理后的文档数据返回给协调节点；
coordinate node 汇总所有数据后，返回给客户端。

深度分页问题

在 Elasticsearch 中，支持三种分页查询方式：

from + size - 可以使用 from 和 size 参数分别指定查询的起始页和每页记录数。
search_after - 不支持指定页数，只能向下翻页；并且需要指定 sort，并保证值是唯一的。然后，可以反复使用上次结果中最后一个文档的 sort 值进行查询。
scroll - 类似于 RDBMS 中的游标，只允许向下翻页。每次下一页查询后，使用返回结果的 scroll id 来作为下一次翻页的标记。scroll 查询会在搜索初始化阶段会生成快照，后续数据的变化无法及时体现在查询结果，因此更加适合一次性批量查询或非实时数据的分页查询。

前文中，我们已经了解了 ES 两阶段搜索流程（Query 和 Fetch）。从中不难发现，这种搜索方式在分页查询时会出现以下情况：

每个 shard 要扫描 from + size 条数据；
coordinate node 需要接收并处理 (from + size) * primary_shard_num 条数据。

如果 from 或 size 很大，需要处理的数据量也会很大，代价很高，这就是深分页产生的原因。为了避免深分页，ES 默认限制 from + size 不能超过 10000，可以通过 index.max_result_window 设置。

如何解决 Elasticsearch 深分页问题？

ES 官方提供了另外两种分页查询方式 search_after + PIT 和 scroll（注意：官方已不再推荐）来避免深分页问题。

计算偏差

在 ES 中，不仅仅是普通搜索，相关性计算（评分）和聚合计算也是先在每个 shard 的本地进行计算，再由 coordinate node 进行汇总。由于分片的本地计算是独立的，只能基于数据子集来进行计算，所以难免出现数据偏差。

解决这个问题的方式也有多种：

当数据量不大的情况下，设置主分片数为 1，这意味着在数据全集上进行聚合。但这种方案不太现实。
设置 shard_size 参数，将计算数据范围变大，牺牲整体性能，提高精准度。shard_size 的默认值是 size * 1.5 + 10。
使用 DFS Query Then Fetch，在 URL 参数中指定：_search?search_type=dfs_query_then_fetch。这样设定之后，系统先会把每个分片的词频和文档频率的数据汇总到协调节点进行处理，然后再进行相关性算分。这样的话会消耗更多的 CPU 和内存资源，效率低下！
尽量保证数据均匀地分布在各个分片中。

数据路由

为了避免出现数据倾斜，系统需要一种高效的方式把数据均匀分散到各个节点上存储，并且在检索的时候可以快速找到文档所在的节点与分片。这就需要确立路由算法，使得数据可以映射到指定的节点上。

常见的路由方式如下：

算法	描述
随机算法	写数据时，随机写入到一个节点中；读数据时，由于不知道查询数据存在于哪个节点，所以需要遍历所有节点。
路由表	由中心节点统一维护数据的路由表，以保证唯一性；但是，中心化产生了新的问题：单点故障、数据越大，路由表越大、单点容易称为性能瓶颈、数据迁移复杂等。
哈希取模	对 key 值进行哈希计算，然后根据节点数取模，以确定节点。

ES 的数据路由算法是根据文档 ID 和 routing key 来确定 Shard ID 的过程。默认的情况下 routing key 为文档 ID，路由算法一般情况下的计算公式如下：

1	shard_number = hash(_routing) % numer_of_primary_shards

也可以在请求中指定 routing key，下面是新增数据的时候指定 routing 的方式：

PUT <index>/_doc/<id>?routing=routing_key
{
    "field1": "xxx",
    "field2": "xxx"
}

添加数据时，如果不指定文档 ID，ES 会自动分片一个随机 ID。这种情况下，结合 Hash 算法，可以保证数据被均匀分布到各个分片中。如果指定文档 ID，或指定 routing key，Hash 计算得出的值可能会不够随机，从而导致数据倾斜。

index 一旦设置了主分片数就不能修改，如果要修改就需要 reindex（即数据迁移）。之所以如此，就是因为：一旦修改了主分片数，即等于修改了原 Hash 计算中的变量，无法再通过 Hash 计算正确路由到数据存储的分片。

参考资料

Elasticsearch 搜索（上）

发表于 2024-11-22 更新于 2025-04-01 分类于数据库，搜索引擎数据库， elasticsearch 本文字数： 8.8k 阅读时长 ≈ 8 分钟

Elasticsearch 搜索（上）

搜索简介

Elasticsearch 支持多种搜索：

精确搜索（词项搜索）：搜索数值、日期、IP 或字符串的精确值或范围。
全文搜索：搜索非结构化文本数据并查找与查询项最匹配的文档。
向量搜索：存储向量，并使用 ANN 或 KNN 搜索来查找相似的向量，从而支持语义搜索等场景。

可以使用 _search API 来搜索和聚合 Elasticsearch 数据流或索引中的数据。API 的 query 请求采用 DSL 语义来进行查询。

Elasticsearch 支持两种搜索方式：URI Query 和 Request Body Query（DSL）

::: details URI Query 示例

1
2
3

GET /kibana_sample_data_ecommerce/_search?q=customer_first_name:Eddie
GET /kibana*/_search?q=customer_first_name:Eddie
GET /_all/_search?q=customer_first_name:Eddie

:::

::: details Request Body Query（DSL）示例

POST /kibana_sample_data_ecommerce/_search
{
	"query": {
		"match_all": {}
	}
}

:::

当文档存储在 Elasticsearch 中时，它会在 1 秒内近乎实时地被索引和完全搜索。

Elasticsearch 基于 Lucene 开发，并引入了分段搜索的概念。分段类似于倒排索引，但 Lucene 中的单词 index 表示“段的集合加上提交点”。提交后，将向提交点添加新分段并清除缓冲区。

位于 Elasticsearch 和磁盘之间的是文件系统缓存。内存中索引缓冲区的文档会被写入新的分段，然后写入文件系统缓存，然后才刷新到磁盘。

Lucene 允许写入和打开新分段，使其包含的文档对搜索可见，而无需执行完全提交。这是一个比提交到磁盘要轻松得多的过程，并且可以频繁地完成而不会降低性能。

在 Elasticsearch 中，写入和打开新分段的这一过程称为刷新。刷新使自上次刷新以来对索引执行的所有操作都可用于搜索。

默认情况下，Elasticsearch 每秒定期刷新一次索引，但仅限于在过去 30 秒内收到一个或多个搜索请求的索引。这就是我们说 Elasticsearch 具有近实时搜索能力的原因：文档更改不会立即对搜索可见，但会在此时间范围内变得可见。

排序

在 Elasticsearch 中，默认排序是按照相关性的评分（_score）进行降序排序。_score 是浮点数类型，_score 评分越高，相关性越高。评分模型的选择可以通过 similarity 参数在映射中指定。

在 5.4 版本以前，默认的相关性算法是 TF-IDF。TF 是词频（term frequency），IDF 是逆文档频率（inverse document frequency）。一个简短的解释是，一个词条出现在某个文档中的次数越多，它就越相关；但是，如果该词条出现在不同的文档的次数越多，它就越不相关。5.4 版本以后，默认的相关性算法 BM25。

此外，也可以通过 sort 自定排序规则，如：按照字段的值排序、多级排序、多值字段排序、基于 geo（地理位置）排序以及自定义脚本排序。

::: details 排序示例

单字段排序

POST /kibana_sample_data_ecommerce/_search
{
  "size": 5,
  "query": {
    "match_all": {}
  },
  "sort": [
    {"order_date": {"order": "desc"}}
  ]
}

多字段排序

POST /kibana_sample_data_ecommerce/_search
{
  "size": 5,
  "query": {
    "match_all": {}
  },
  "sort": [
    {"order_date": {"order": "desc"}},
    {"_doc":{"order": "asc"}},
    {"_score":{ "order": "desc"}}
  ]
}

:::

详情参考：Sort search results

分页

默认情况下，Elasticsearch 搜索会返回前 10 个匹配的匹配项。

Elasticsearch 支持三种分页查询方式。

from + size
search after
scroll

from + size

可以使用 from 和 size 参数分别指定起始页和每页记录数。

当一个查询：from = 990, size = 10，会在每个分片上先获取 1000 个文档。然后，通过协调节点聚合所有结果。最后，再通过排序选取前 1000 个文档。

页数越深，占用内存越多。为了避免深分页问题，ES 默认限定最多搜索 10000 个文档，可以通过 index.max_result_window 进行设置。

::: details from + size 分页查询示例

POST /kibana_sample_data_ecommerce/_search
{
  "from": 2,
  "size": 5,
  "query": {
    "match_all": {}
  }
}

:::

scroll

scroll 搜索方式类似于 RDBMS 中的游标，只允许向下翻页。每次下一页查询后，使用返回结果的 scroll id 来作为下一次翻页的标记。

scroll 在搜索初始化阶段会生成快照，后续数据的变化无法及时体现在查询结果，因此更加适合一次性批量查询或非实时数据的分页查询。

启用游标查询时，需要注意设定期望的过期时间（scroll = 1m），以降低维持游标查询窗口所需消耗的资源。

注意：Elasticsearch 官方不再建议使用 scroll 查询方式进行深分页，而是推荐使用 search_after 和时间点（PIT）一起使用。

::: details scroll 分页查询示例

POST /kibana_sample_data_ecommerce/_search?scroll=1m
{
  "size": 3,
  "query": {
    "match": {
      "currency": "EUR"
    }
  }
}

响应结果

{
  "_scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAmTkWRTMzNmxBYmZUbUdsdFNqMnJoTl84Zw==",
  "took": 0,
  "timed_out": false,
  "_shards": {
    // 略
  },
  "hits": {
    "total": {
      "value": 4675,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [] // 略
  }
}

:::

详情参考：Paginate search results

search after

search after 搜索方式不支持指定页数，只能向下翻页；并且需要指定 sort，并保证值是唯一的。然后，可以反复使用上次结果中最后一个文档的 sort 值进行查询。

search after 实现的思路同 scroll 方式基本一致，通过记录上一次分页的位置标识，来进行下一次分页查询。相比于 scroll 方式，它的优点是可以实时获取数据的变化，解决了查询快照导致的查询结果延迟问题。

::: details search after 分页查询示例

第一次查询


POST /kibana_sample_data_ecommerce/_search
{
  "size": 5,
  "query": {
    "match_all": {}
  },
  "sort": [
    {"order_date": {"order": "desc"}}
  ]
}

响应结果

{
  "took": 2609,
  "timed_out": false,
  "_shards": {
    // 略
  },
  "hits": {
    "total": {
      "value": 4675,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      // 略多条记录
      // 最后一条记录
      {
        // 略
        "sort": [1642893235000]
      }
    ]
  }
}

从上次查询的响应中获取 sort 值，然后将 sort 值插入 search after 数组：

POST /kibana_sample_data_ecommerce/_search
{
  "size": 5,
  "query": {
    "match_all": {}
  },
  "search_after": [
    1642893235000
  ],
  "sort": [
    {
      "order_date": {
        "order": "desc"
      }
    }
  ]
}

:::

限定字段

默认情况下，搜索响应中的每个点击都包含 _source，该字段保存了原始文本的 JSON 对象。有两种推荐的方法可以从搜索查询中检索所选字段：

使用 fields 选项指定响应结果中返回的值。
如果需要在查询时返回原始文本数据，可以使用 _source 选项。

折叠搜索结果

Elasticsearch 中，可以通过 collapse 对搜索结果进行分组，且每个分组只显示该分组的一个代表文档。

::: details collapse 查询示例

POST /kibana_sample_data_ecommerce/_search
{
  "size": 10,
  "query": {
    "match_all": {}
  },
  "collapse": {
    "field": "day_of_week"
  }
}

响应结果：

{
  "took": 106,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 4675,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "yZUtBX4BU8KXl1YJRBrH",
        "_score": 1,
        "fields": {
          "day_of_week": ["Monday"]
        }
      },
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "ypUtBX4BU8KXl1YJRBrH",
        "_score": 1,
        "fields": {
          "day_of_week": ["Sunday"]
        }
      },
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "1JUtBX4BU8KXl1YJRBrH",
        "_score": 1,
        "fields": {
          "day_of_week": ["Tuesday"]
        }
      },
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "1ZUtBX4BU8KXl1YJRBrH",
        "_score": 1,
        "fields": {
          "day_of_week": ["Wednesday"]
        }
      },
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "2JUtBX4BU8KXl1YJRBrH",
        "_score": 1,
        "fields": {
          "day_of_week": ["Saturday"]
        }
      },
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "2ZUtBX4BU8KXl1YJRBrH",
        "_score": 1,
        "fields": {
          "day_of_week": ["Thursday"]
        }
      },
      {
        "_index": "kibana_sample_data_ecommerce",
        "_type": "_doc",
        "_id": "35UtBX4BU8KXl1YJRBrI",
        "_score": 1,
        "fields": {
          "day_of_week": ["Friday"]
        }
      }
    ]
  }
}

:::

过滤搜索结果

使用带有 filter 子句的布尔查询，可以过滤搜索和聚合的结果。

使用 post_filter 可以过滤搜索的结果，但不能过滤聚合结果。

:::details filter 示例

POST /kibana_sample_data_ecommerce/_search
{
  "size": 10,
  "query": {
    "bool": {
      "filter": {
        "range": {
          "taxful_total_price": {
            "gte": 0,
            "lte": 10
          }
        }
      }
    }
  }
}

:::

高亮

Elasticsearch 的高亮（highlight）可以从搜索结果中的一个或多个字段中获取突出显示的摘要，以便向用户显示查询匹配的位置。当请求突出显示（即高亮）时，响应结果的 highlight 字段中包括高亮的字段和高亮的片段。Elasticsearch 默认会用 <em></em> 标签标记关键字。

Elasticsearch 提供了三种高亮器，分别是默认的 highlighter 高亮器、postings-highlighter 高亮器 和 fast-vector-highlighter 高亮器。

::: details 高亮结果示例

POST /kibana_sample_data_ecommerce/_search
{
  "size": 10,
  "query": {
    "match_all": {}
  },
  "highlight": {
    "fields": {
      "user": {
        "pre_tags": [
          "<strong>"
        ],
        "post_tags": [
          "</strong>"
        ]
      }
    }
  }
}

:::

详情参考：Highlighting

分片路由搜索

Elasticsearch 可以在多个节点上的多个分片中存储索引数据的副本。在运行搜索请求时，Elasticsearch 会选择包含索引数据副本的节点，并将搜索请求转发到该节点的分片。此过程称为路由。

默认情况下，Elasticsearch 使用自适应副本选择来路由搜索请求。默认情况下，自适应副本选择从所有符合条件的节点和分片中进行选择。如果要限制符合搜索请求条件的节点和分片集，可以使用 preference 查询参数。

详情参考：Search shard routing

查询规则

Elasticsearch 允许自定义查询规则来进行搜索。

详情参考：Searching with query rules

搜索模板

搜索模板是可以使用不同变量运行的存储搜索。

详情参考：Search templates

《Kafka 核心技术与实战》笔记

开篇词 为什么要学习 Kafka？

消息引擎系统 ABC

一篇文章带你快速搞定 Kafka 术语

Kafka 只是消息引擎系统吗？

我应该选择哪种 Kafka？

聊聊 Kafka 的版本号

Kafka 线上集群部署方案怎么做？

最最最重要的集群参数配置（上）

最最最重要的集群参数配置（下）

生产者消息分区机制原理剖析

生产者压缩算法面面观

无消息丢失配置怎么实现？

客户端都有哪些不常见但是很高级的功能？

Java 生产者是如何管理 TCP 连接的？

幂等生产者和事务生产者是一回事吗？

消费者组到底是什么？

揭开神秘的“位移主题”面纱

消费者组重平衡能避免吗？

Kafka 中位移提交那些事儿

CommitFailedException 异常怎么处理？

多线程开发消费者实例

Java 消费者是如何管理 TCP 连接的

消费者组消费进度监控都怎么实现？

Kafka 副本机制详解

副本

In-sync Replicas（ISR）

Unclean 领导者选举（Unclean Leader Election）

请求是怎么被处理的？

消费者组重平衡全流程解析

你一定不能错过的 Kafka 控制器

关于高水位和 Leader Epoch 的讨论

高水位的作用

高水位更新机制

副本同步机制解析

Leader Epoch

主题管理知多少

Kafka 动态配置了解下？

怎么重设消费者组位移？

常见工具脚本大汇总

KafkaAdminClient：Kafka 的运维利器

Kafka 认证机制用哪家？

云环境下的授权该怎么做？

跨集群备份解决方案 MirrorMaker

你应该怎么监控 Kafka？

主流的 Kafka 监控框架

调优 Kafka，你做到了吗？

从 0 搭建基于 Kafka 的企业级实时日志流处理平台

Kafka Streams 与其他流处理平台的差异在哪里？

Kafka Streams DSL 开发实例

Kafka Streams 在金融领域的应用

参考资料

Kafka 面试

Kafka 简介

【基础】什么是 Kafka?

【基础】Kafka 有哪些核心术语？

Kafka 存储

【中级】Kafka 是如何存储数据的？

Kafka 逻辑存储

Kafka 物理存储

【高级】Kafka 文件格式是怎样的？

【高级】Kafka 如何检索数据？

【高级】Kafka 如何清理数据？

生产者

【中级】Kafka 发送消息的工作流程是怎样的？

消费者

【基础】Kafka 为什么要支持消费者群组？

消费者

消费者群组

【中级】如何消费 Kafka 消息？

分区

【中级】什么是分区？为什么要分区？

【中级】Kafka 的分区策略是怎样的？

【中级】如何自定义分区策略？

【高级】Kafka 如何实现分区再均衡？

什么是分区再均衡

何时生分区再均衡

分区再均衡的过程

如何判定消费者已经死亡

查找协调者

开篇词为什么要学习 Kafka？