Question

01 中间件生态（上）：有哪些类型的中间件？

中间件是游离于业务需求之外，专门为了处理项目中涉及高可用、高性能、高并发等技术需求而引入的一个个技术组件。它的一个重要作用就是能够实现业务代码与技术功能之间解耦合。

02 中间件生态（下）：同类型的中间件如何进行选型？

• 本地缓存中间件：Guava Cache 和 Caffeine
• 分布式缓存中间件： Redis, Memcache
• 全文索引中间件：Elasticsearch。场景：一个是宽表、解决跨库 Join，另一个就是全文搜索
  • 分库分表在面对多维度查询时将变得力不从心: 使用数据异构 + 宽表。引入 Canal 数据同步工具，订阅 MySQL 的 Binglog，将增量数据同步到 Elasticsearch 中，实现数据访问层面的读写分离。
• 分布式日志中间件：进行日志采集的机器上安装一个 filebeat 工具，用来采集服务器的日志，并将它们存储到消息中间件中。然后， 在需要采集的机器中安装 Logstash 进程，通过 Logstash 将日志数据存储到 Elasticsearch 服务器，用户可以通过 Kibana 查询存储在 Elasticsearch 中的日志数据

03 数组与链表：存储设计的基石有哪些？

• ArrayList
• LinkedList
• HashMap

04 红黑树：图解红黑树的构造过程与应用场景

• TreeMap: 红黑树。 可以用来实现一致性哈希
• LinkedhashMap: LinkedList 和 HashMap 的结合体。实现 lru
• PriorityQueue: 堆

05 多线程：多线程编程有哪些常见的设计模式？

如何复用线程：线程池。内部是 while + 阻塞队列的机制，确保线程的 run 方法不会结束。在有任务执行时运行任务，无任务运行时则通过阻塞队列阻塞线程。

• Future模式

它指的是主线程向另外一个线程提交任务时，无须等待任务执行完毕，而是立即返回一个凭证，也就是 Future。这时主线程还可以做其他的事情，不会阻塞。 等到需要异步执行结果时，主线程调用 Future 的 get 方法，如果异步任务已经执行完毕，则立即获取结果；如果任务还没执行完，则主线程阻塞，等待执行结果。

Future 模式的核心要领是将多个请求进行异步化处理，并且可以得到返回结果。常用线程池的方式实现。

• 生产者、消费者模式

06 锁：如何理解锁的同步阻塞队列与条件队列？

07 NIO：手撸一个简易的主从多Reactor线程模型

在等待数据阶段，如果发起网络调用后，在服务端数据没有准备好的情况下客户端会阻塞，我们称为阻塞 IO；如果数据没有准备好，但网络调用会立即返回，我们称之为非阻塞 IO。

在数据传输阶段，如果发起网络调用的线程还可以做其他事情，我们称之为异步，否则称之为同步。

BIO 的全称同步阻塞 IO，还有 NIO 的全称同步非阻塞 IO。NIO 模型更适合需要大量在线活跃连接的场景，常见于服务端；BIO 模型则适合只需要支持少量连接的场景。

主从多 Reactor 模型。它的核心设计理念是让线程分工明确，相互协作。Main Reactor 线程池主要负责连接建立，SubReactor 线程池主要负责网络的读写，而编码、解码和业务执行则需要具体情况具体分析。

08 Netty：如何优雅地处理网络读写，制定网络通信协议？

经典的协议设计方法是：协议头+ body 的设计理念

08 加餐 中间件底层的通用设计理念

数据结构、多线程编程（并发编程）、网络编程（NIO、Netty）、内存管理、文件编程、领域知识

09 技术选型：如何选择微服务框架和注册中心？

Dubbo vs Spring Cloud

注册中心： Zookeeper (CP); Eureka(AP) 模型

10 设计原理：Dubbo核心设计原理剖析

Dubbo 提供了下面五种策略：

• failover，失败后选择另外一台服务提供者进行重试，重试次数可配置，通常适合实现幂等服务的场景；
• failfast，快速失败，失败后立即返回错误；
• failsafe，调用失败后打印错误日志，返回成功，通常用于记录审计日志等场景；
• failback，调用失败后，返回成功，但会在后台定时无限次重试，重启后不再重试；
• forking，并发调用，收到第一个响应结果后返回给客户端。通常适合实时性要求比较高的场景。但这一策略浪费服务器资源，通常可以通过 forks 参数设置并发调用度。

11 案例：如何基于Dubbo进行网关设计？

网关设计至少包含三方面：签名验证；服务配置；限流

12 案例：如何进行蓝绿发布？

蓝绿发布的实现要点是对应用分别部署蓝、绿两套环境，在版本稳定后由一套环境对外提供服务，当需要发布新版本时，将新版本一次性部署到没有流量的环境， 待部署成功后再逐步将流量切换到新版本。如果新版本在验证阶段遇到严重的问题，可以直接将流量切回老版本，实现应用发布的快速回滚。

蓝绿发布的底层原理是借助 Dubbo 内置的标签路由功能，其核心思路是，当服务发起调用时，经过服务发现得到一个服务提供者列表， 但是并不直接使用这些服务提供者进行负载均衡，而是在进行负载均衡之前，先按照路由规则对这些提供者进行过滤，挑选符合路由规则的服务提供者列表进行服务调用，从而实现服务的动态分组。

13 技术选型：如何根据应用场景选择合适的消息中间件？

异步解耦与削峰填谷

14 性能之道：RocketMQ与Kafka高性能设计对比

Kafka 中文件的布局是以 Topic/partition 为主 ，每一个分区拥有一个物理文件夹，Kafka 在分区级别实现文件顺序写。如果一个 Kafka 集群中有成百上千个主题， 每一个主题又有上百个分区，消息在高并发写入时，IO 操作就会显得很零散，效果相当于随机 IO。 也就是说，Kafka 在消息写入时的 IO 性能，会随着 topic 、分区数量的增长先上升，后下降。

而 RocketMQ 在消息写入时追求极致的顺序写，所有的消息不分主题一律顺序写入 commitlog 文件， topic 和 分区数量的增加不会影响写入顺序。

根据我的实践经验，当磁盘是 SSD 时，采用同样的配置，Kafka 的吞吐量要超过 RocketMQ，我认为这里的主要原因是单文件顺序写入很难充分发挥磁盘 IO 的性能。

15 案例：消息中间件如何实现蓝绿？

• 基于消息主题。发送时候的时候将消息发送到不同的主题，消费端对各个消费组进行分工
• 基于消息属性。使用同一个主题，每个消息增加一个属性 color 存储消息颜色，消费端使用不同的消费组来消费消息

16 案例：如何提升RocketMQ顺序消费性能？

实现一个消费者至少需要涉及队列自动负载、消息拉取、消息消费、位点提交、消费重试等几个部分。

提升并发：降低锁的粒度。只有 key 不同的消息才必须保证顺序性。根据消息的 key 哈希到本地不同的消费队列。

17 运维：如何运维日均亿级的消息集群？

集群部署

核心业务要按业务域进行规划，并且通常采用 RocketMQ。例如我们可以划分出订单、运单、财金等业务域。业务域内尽量独占。

日志采集类通常采用 Kafka，并且也要搭建几套日志集群，做好拆分，控制好影响的范围。

集群扩容

中间件的运维必须遵循一个最基本的原则：中间件所做的变更要对业务无感知。即，中间件做的任何变更不需要业务方配合，也不会影响正在运行的业务，当然为了安全起见，还是需要将变更操作通知业务方，做一些必要的检查工作。

kafka涉及到分区重分配。

集群缩容

大促结束后，为了节省资源，通常需要对集群进行缩容处理。将节点从集群中移除的基本原则是，存储在这些节点上的消息必须完成消费，否则会造成消息消费丢失。

分区扩容

除了在集群维度扩容和缩容外，无论是 RocketMQ 还是 Kafka 都支持分区级别的扩容。

分区缩容

Kafka 目前不支持分区缩容，也就是说，一个主题的分区数量只能增加不能减少。而 RocketMQ 可以无缝实现缩容。

位点重置(回溯)

RocketMQ 不需要停止消费组就可以进行位点回溯。 kafka 中在进行位点重置之前，首先需要停止该消费组内所有的消费者

18 案例：如何排查RocketMQ消息发送超时故障？

解决方案

RocketMQ 中和 IO 相关的线程参数有两个，分别是 serverSelectorThreads（默认值为 3）和 serverWorkerThreads（默认值为 8）。

在 Netty 中，serverSelectorThreads 就是 WorkGroup，即所谓的 IO 线程池。每一个线程池会持有一个 NIO 中的 Selector 对象用来进行事件选择，所有的通道会轮流注册在这 3 个线程中，绑定在一个线程中的所有 Channel 会串行进行网络读写操作。

我们的 MQ 服务器的配置，CPU 的核数都在 48C 及以上，用 3 个线程来做这件事显然太“小家子气”，这个参数可以调优。

发送超时兜底策略

为了尽可能避免这样的问题出现，消息中间件领域解决超时的另一个思路是：增加快速失败的最大等待时长，并减少消息发送的超时时间，增加重试次数。

1. 增加 Broker 端快速失败的等待时长。这里建议为 1000。在 Broker 的配置文件中增加如下配置：maxWaitTimeMillsInQueue=1000
2. 减少超时时间，增加重试次数。

19 案例：如何排查RocketMQ消息消费积压问题？

通常情况下，RocketMQ 消息发送问题很可能与服务端有直接关系，而 RocketMQ 消费端遇到的一些性能问题通常与消费进程自身有关系。

另外，消费积压的时候，可以简单关注一下这个集群其他消费者的情况。如果其他消费者没有积压，只有你负责的消费组有积压，那就一定是消费端代码的问题了。

在这里最后再强调一遍，查看线程栈并不只是去查看线程状态为 BLOCKED、TIME_WRATING 的线程，RUNNABLE 的线程状态同样需要查看。因为在一些网络操作中（例如，HTTP 请求等待返回结果时、MySQL 写入 / 查询等待获取执行结果时），线程的状态也是 RUNNABLE。

20 技术选型：分布式定时调度框架的功能和未来

定时调度通常的功能需求，它们包括触发器、任务可视化管理、分布式部署、数据分片、故障转移、任务依赖等。

• Quartz
• ElasticJob (适合大数据量)
• XXL-JOB (扩展性强，调度和任务执行解耦)

21 设计理念：如何基于ZooKeeper设计准实时架构？

基于 ZooKeeper 实现元信息配置管理与实时感知。

基于 ZooKeeper 的事件通知机制

ElasticJob 利用了 ZooKeeper 的强一致性与事件监听机制。

事件注册的底层使用的是 ZooKeeper 的 watch，每一个监听器在一个特定的节点处监听，一旦节点信息发生变化，ZooKeeper 就会通知执行注册的事件监听器，执行对应的业务处理。

一个节点信息的变化包括：节点创建、节点值内容变更、节点删除、子节点新增、子节点删除、子节点内容变更等。

22 案例：使用分布式调度框架该考虑哪些问题？

在中间件应用领域，定时调度框架通常和 MQ 等中间件组合使用，联合完成分布式环境下事务的最终一致性。

设计方案(分布式事务)

如何保证数据库写入和消息发送这两个分布式操作的一致性: 本地消息表 + 定时任务。

我们首先需要在数据库创建一张本地消息表，表的结构大致如下：消息待发送表 msg_send_record (id, account_no, state, create_time)

创建了消息发送本地记录表之后，用户注册的流程将变成：

1. 开启数据库本地事务；
2. insert into user 表（用户注册表）；
3. insert into msg_send_record，并且存储账户的唯一编号、状态，其中状态的初始值为 0；
4. 提交本地事务。

这样做的目的是，保证 user 表和 msg_send_record 的事务一致性，如果用户信息成功存入 user 表，msg_send_record 表中必然存在一条对应的记录， 后续我们只需要根据 msg_send_record 表中的记录发送一条对应的 MQ 消息即可。

当然，为了保证 msg_send_record 的写入不至于带来太大的性能损耗，通常我们会采取下面几个措施。

• 如果在分库分表环境中，msg_send_record 采取的分库策略与 user 表一致，我们要保证这个过程是一个本地事务，不至于出现跨库 Join 的情况。
• 为 account_no、创建时间这两个字段添加索引。
• 定时清除 msg_send_record 表中的数据，这个表不需要保留太长时间，尽量控制单表数据量。

数据成功写入消息待发送表后，接下来我们需要引入定时调度程序，定时扫描 msg_send_record 中的记录，将消息发送到 MQ 中。

定时调度程序的数据处理策略主要有三步。首先，按照分页机制从数据库中拉取一批数据；然后，根据用户账户查询用户表，构建消息体（用户账户、用户注册时间）； 最后，将消息发送到消息服务器（这里必须提供重试机制）。

如何解决调度延迟：ElasticJob 可以通过支持流式任务解决这个问题。具体的思路是：将任务配置为按照分钟级进行调度，例如每分钟执行一次调度。 每次调度按照分页去查找数据，处理完一批数据，再查询下一批，如果查到待处理数据，就继续处理数据，直到没有待处理数据时，才结束本次业务处理。 如果本次处理时间超过了一个调度周期，那么利用 ElasticJob 的任务错过补偿执行机制会再触发一次调度。

假设我们的业务逻辑要根据不同的类型发送不到不同的 MQ 集群中，部分主题可能一直发送失败，最后影响到其他主题的正常发送。 如何解决？

消息待发送表 msg_send_record 增加两个字段：retry_count(当前重试次数); 下一次调度最小时间(next_select_time)。 在处理数据时，如果第一次处理数据失败了，我们需要将重试次数加一，并设置下一次调度的最小时间。例如，用当前时间加一分钟，意味着一分钟内流式处理任务将不再拉取该数据，这就给了其他数据执行机会。

23 案例：如何在生产环境进行全链路压测？

全链路压测就是在生产环境对我们的系统进行压测，压测流量的行进方向和真实用户的请求流量是一致的，也就是说压测流量会完全覆盖真实的业务请求链路。

压测前:主要任务是构建压测数据。全链路压测的核心目标是高保真模拟真实请求。但目前市面上的性能压测实践基本都是通过 JMeter 来人工模拟接口的数据最终生成测试请求的，这样无法反馈用户的真实行为。全链路压测最期望的结果是对真实用户请求日志进行脱敏和清洗，然后将其存入数据仓库中。在真正进行压测时，根据数据仓库中的数据模拟用户的真实行为。

压测运行时:主要包括请求打标、透传以及各主流中间件的数据隔离，这是全链路压测的基座。

压测后:压测结束后，我们需要生成压测报告并实时监控压测过程，一旦压测过程中系统扛不住，要立马提供熔断压测，避免对生产环境造成影响。

流量染色与透传机制

由于流量染色标记需要在整个调用链中传播，在进行数据存储或查询时，都需要根据该标记来路由。所以，为了不侵入代码，把流量染色标记存储在本地线程上下文中是最合适的。 (阿里巴巴开源了 transmittable-thread-local 类库)。

数据隔离机制

根据本地线程上下文中的流量标记，选择对应的数据源。

如何学习中间件

• 技术操作能力(多动手)。学习路径: 关系数据库；缓存和队列；redis和kafka；负载均衡；编程语言；操作系统
• 原理理解能力。看源码
• 综合判断能力。梳理技术栈，连接知识点
  • 消息积压：消费能力不行了？网络阻塞了？还是计算能力到头了

阅读源码的方法分享给你。

• 了解这款软件的使用场景、以及它在架构设计中将承担的责任。
• 寻找官方文档，从整体上把握这款软件的设计理念。
• 搭建自己的开发调试环境，运行官方提供的 Demo 示例，为后续深入研究打下基础。
• 先研究主干流程再专注分支流程，注意切割，逐个击破。