小工匠

文章目录超高并发设计技术杂谈超高并发设计小工匠聊架构-超高并发秒杀系统设计 01_总体原则和架构演进小工匠聊架构-超高并发秒杀系统设计 02_数据的动静分离小工匠聊架构-超高并发秒杀系统设计 03_热点数据的处理小工匠聊架构-超高并发秒杀系统设计 04_流量削峰设计小工匠聊架构-超高并发秒杀系统设计 05_服务端性能优化小工匠聊架构-超高并发秒杀系统设计 06_数据一致性小工匠聊架构-超高并发秒杀系统设计 07_Plan B 的设计技术杂谈小工匠聊架构-写给研发工程师的全链路压测小

支付业务可以容忍的时间是分钟级别的；银行卡支付和余额转账的主要区别就是银行卡支付的相关信息可以重复，且可用性和数据一致性要求没有那么高，基于这两个区别，银行卡支付的高可用复杂度中，数据复制方式可以采用异步复制，由于银行卡信息可以新增、删除、修改，并不要求高可用和高一致性，因此可以不选用民主式决策。那么对于钱包业务来说，业务上可以分为余额转账、银行卡支付、运行后台等，对于余额转账、可以实时也可以不实时，银行卡支付，这种一般是用户向商家支付，这种是要求实时的，运营后台，内部人员使用，容忍度要低一些。

MQ - 02 基础篇_通讯协议我们知道了协议分为公有协议和私有协议。公有协议有 MQTT、AMQP、OpenMessaging 等等，主流消息队列一般会设计自己的私有协议，比如 Kafka 协议、Pulsar 协议、RocketMQ 的 Remoting 协议等。另外消息队列从使用场景的角度看，分为了消息和流两个方向。所以在业务架构中，一般会同时使用多种消息队列来满足不同的使用场景。但是同时使用多款消息队列，从业务视角来看会增加学习和使用成本，从公司视角看会增加运维和资源成本。

对于我们业务侧来说，我们需要保证业务在任何情况都能正常运行，即服务自身拥有容灾能力是基本要求。而消息队列作为基础组件，容灾是它的基本能力。我们将会详细讲一下消息队列集群在发生异常时如何做好容灾，以及异常时如何保证数据不丢失容灾是指当系统发生这些异常时，服务能够自动切换，并正常运行。我们是通过 RTO 和 RPO 来衡量容灾的质量。RTO 是指发生故障时业务系统所能容忍的最长停止服务时间，RPO 是指在故障期间能够容忍多少数据丢失。业务追求的是 RTO 和 RPO 都为 0，或者无限趋近于 0。

在消息队列中，连接器也称为 Connector，它的作用是把不同数据源中的数据导入到消息队列，或者把消息队列中的数据导出到下游的各种存储引擎。连接器对于用户的价值是，可以很方便地将数据导入、导出消息队列。听起来，它和MQ - 38 Serverless : 基于Serverless架构实现流式数据处理中讲的基于 Serverless 实现流式计算和事件驱动架构的作用很类似，从功能上看，Flink 或 Spark 也能实现。那为什么还有连接器这个概念呢？它的价值是什么？

为了更好地理解它，我们先来回顾两个知识点。MQ - 07 基础篇_消费者客户端SDK设计(上)消费数据时 Push 模型的实时性是最高的MQ - 38 Serverless : 基于Serverless架构实现流式数据处理事件源数据的触发方式有一种是事件触发。从技术上来看，这两个知识点都是事件驱动架构的一种实现。接下来我们就详细了解一下什么是事件驱动架构，它有什么用，以及它的架构和底层运行原理。事件驱动架构，英文是 Event Driven Architecture，简称 EDA。

为什么要搞明白上述问题？我们从一张架构图讲起。这是一张消息队列上下游生态的架构图，分为数据源、总线管道、数据目标三部分。可以看到消息队列在架构中处于缓存层，起到的是削峰填谷的缓冲作用。从技术上看，构建以消息队列为中心的数据流架构，有很多现成的技术方案和开源框架。比如分布式流计算框架 Spark/Flink，开源体系内自带的 Kafka Stream、SeaTunnel/DataX 等数据集成产品，或者 ELK 体系下的采集和数据处理的组件 Logstash，都具有处理数据的能力。

很多人对分层存储的概念比较模糊，经常会将它和存算分离混淆在一起。从功能上来看，两者是完全不一样的。存算分离架构主要解决的是集群架构的弹性问题，而分层存储架构解决的是低成本存储冷数据的问题。下图是两种形态的架构对比，存算分离是将计算层和存储层独立开来，分别负责计算相关逻辑和存储数据。分层存储在本地完成计算和存储逻辑，然后将 Broker 本地的冷数据上传到远程进行存储，需要时再拉下来处理。从技术上看，左边的存算分离架构也可以支持分层存储的特性，即把存储层中的冷数据再导入到另外一个存储系统存储。

结合云原生、Serverless、EDA（Event-driven Architectures）、存算分离、分层存储、数据集成等一些业界较新的技术架构理念，来看一下消息队列如何与这些架构理念结合，以及结合后会具备哪些实际价值。我们先看一下消息队列的存算分离架构。存算分离中的“存”是指存储层，“算”是指“计算层”。简单理解“计算”就是功能相关的实现，“存储”是指数据落地持久化存储。消息队列中的存储层是指包括存储结构设计、消息存储格式、数据分段等具体的数据存储功能。

4 款主流消息队列所支持的功能清单在上面的表格中，你会发现一个现象，Pulsar 支持的功能最多，RabbitMQ 和 RocketMQ 其次，Kafka 支持的功能最少。原因和它们自身的定位和发展历史有关。接下来我们从功能出发，来分析一下这 4 款主流消息队列的原理和使用方式。先来个说明，这节课中的每个部分都是独立的，你可以挑感兴趣的内容进行学习。总结下来，你会发现不同消息队列在功能方面的支持是很不一样的，侧重点各有不同。但是同一个功能的底层实现原理，大家的思路基本是一致的。

如何在消息队列内核中支持 WebSocket。我们就知道 WebSocket 是一个协议。我们在MQ - 03 基础篇_网络模块说过 消息队列在自身私有协议的基础上，还会支持像 HTTP 这样的公有协议。那为什么需要支持 WebSocket 协议呢？又是如何支持的？WebSocket 是一种实时协议，它在单个 TCP 连接上提供持久的全双工通信，即双向通信。双向通信非常适合需要实时更新的系统，简单说就是允许服务端主动推送数据给客户端的场景。比如金融行情、实时多人游戏、聊天应用程序和实时地理位置更新等等。

我们来看看消息队列中的 Schema 模块。看到 Schema 这个词， Schema 是什么？它有什么用？什么时候可以用到它？Schema 是数据结构定义的意思，即定义数据是什么格式的。消息队列中的 Schema 用来保证上下游数据在传递过程中，消息根据指定的格式和定义进行传递，从而解决上游的数据变更所导致的下游消费失败问题。消息队列 Schema 的核心是：客户端按照指定的数据格式发送数据，Broker 按照配置的数据格式进行校验，消费者根据指定的格式解析数据。

从功能上来看，消息队列的核心功能是生产和消费，查询并不是它的主要工作，但在一些场景中用户还是需要对消息进行查询。最常见的场景是：用户觉得某条消息丢了，需要查询这条消息是否保存在 Broker 中，此时你会怎么做呢？除此之外，还有哪些场景会用到消息查询的功能呢？查询是消息队列的辅助功能，使用的场景和频率不高。从功能上看，一般会支持按消息位点查询、按时间戳查询、按消息 ID 查询、按消息 Key 或消息内容模糊查询四种场景。查询的核心是索引的构建。

在很多业务场景中，我们会对客户进行分级，比如头部客户、中腰部客户、尾部客户等。此时有个需求是，在给这些客户发通知时，希望头部客户先收到通知，然后是腰部客户，最后是尾部客户。在这个场景中，我们就可以利用优先级队列的特性。如下图所示，只要我们发送通知的时候在每条消息上附带这个客户的优先级信息，比如头部客户的优先级是 10、中腰部是 5、尾部是 1，此时不管生产端发送数据的顺序是怎样的，消费端一定是先拿到优先级高的信息，然后进行推送。

在日常业务的消费数据过程中，如果遇到数据无法被正确处理，就需要先手动把消息保存下来然后 ACK 消息，这样才能顺利消费下一条数据。此时如果消息队列拥有死信队列的功能，就不需要这么繁琐的操作，直接开启死信队列就可以实现同样的效果。为了了解死信队列的特性的底层实现， 我们会详细分析它们的技术方案从本质上来看，死信队列不是一个队列，而是一个功能。为什么这么说呢？

我们来看看消息队列中的事务消息。作为一个研发人员，我们对于事务的概念可以说是如雷贯耳了，最熟悉的应该就是 MySQL 或 Redis 的事务事务有一个特点，它的概念很明确，也很常见，但是它在不同的存储引擎的作用以及实现都是不一样的。所以如果我们想使用某个引擎中的事务功能，就必须先理解一下引擎中实现的事务的功能是什么，能达到什么效果，再去理解和使用它，不能想当然地把经典的 MySQL 的事务的功能套入到新的引擎去使用。

在消息队列中，定时和延时消息的底层技术实现是一样的，我们后面统一用延时消息来称呼。下面我们从延时消息的使用场景和定义讲起。先来看一个延时消息典型的使用场景。在网上购买商品下单的过程中，有个功能是：下单完成后 30 分钟如果没有完成支付，则这个订单就自动被取消。如下图所示，从技术上来看，为了实现这个功能，最直观的思路是我们可以将订单数据存在 DB 的表中。然后通过定时程序每秒定时去扫描订单数据，判断如果超过 30 分钟则进行后续的处理。

在消息队列中，消息是否能有序是一个常常被问到的问题。因为在我们的业务中，比如在有序事件处理、数据实时增量同步等情况下，就需要消息队列支持顺序消息的机制。接下来我们就来看看消息队列中顺序消息的定义和实现。在消息队列中，消息的顺序性一般指的是时间的顺序性，排序的依据就是时间的先后。从功能来看，即生产端发送出来的消息的顺序和消费端接收到消息的顺序是一样的。牢记这个定义，对于我们后面理解顺序消息的实现很重要接下来我们来看看幂等的定义和实现机制，先来看看什么是幂等。

在基础篇和进阶篇，我们构建了一个分布式的消息队列集群。接下来我们就开始往这个集群里面添加各种功能。接下来分析消息队列的基本功能、顺序消息和幂等、延时和定时消息、事务消息、死信队列和优先级队列、消息查询、Schema、WebSocket 等功能的技术选型和设计思路。当我们将这些功能加入到集群之后，一个完整的消息队列基本就打造出来了。这里我们先聊4个静态 / 动态配置的实现：配置是集群的基础模块，看一下如何在集群中实现静态和动态配置。

在集群构建方面，RabbitMQ 通过 Erlang 自带的分布式数据库 Mnesia 来实现元数据信息的存储。通过插件的形式支持多种节点发现机制，主要包括固定配置发现、类广播机制发现、第三方组件发现、手动管理四种类型。集群构建完成后，RabbitMQ 通过副本机制、镜像队列或仲裁队列来实现数据的一致性和可靠存储。镜像队列因为本身的一些架构缺陷，会逐步被仲裁队列替换。仲裁队列是基于 Raft 算法来实现的，写入的可靠性遵循多数原则，即只要多数节点写入成功就可以。

从设计定位上来看，Pulsar 是作为 Kafka 的升级替代品出现的，它主要解决了 Kafka 在集群层面的弹性和规模限制问题。那么现在我们就从集群的角度来拆解一下 Pulsar 的架构设计和实现，先来看一下集群构建。Pulsar 社区发展非常快，可能没几天内容就会过期、失效或总结错误。所以如果需要了解最新的信息，建议你去看源码或官方的最新文档。但是万变不离其宗，当我们掌握了原理，无论如何变化，对我们来讲都不过是变化而已。

我们今天来看看消息方向的 RocketMQ 在集群构建、部署形态、数据可靠性、安全控制、可观测性等五个方面的设计实现在集群构建方面，节点发现是依赖 NameServer 完成的。元数据是存储在本地 Broker，在启动时上报到 NameServer 中的。在部署模式方面，RocketMQ 经历了 Master/Slave、Dledger、Controller 三种模式。其中 Controller 模式属于消息队列中常见的架构形式。在数据可靠性方面，RocketMQ 也是依赖副本来实现数据的高可靠。

MQ - 15 集群篇_如何构建分布式的消息队列集群（下）说了基于 ZooKeeper 和 KRaft 来构建集群的两种方式，在这里就不再重复。这里我们详细分析Kafka 副本之间的数据一致性、数据同步机制、Leader 切换、数据截断在集群构建方面，Kafka 支持依赖 ZooKeeper 和 KRaft 两种形态来存储元数据并完成集群构建，依赖 Controller 来完成集群的管理、Leader 切换等等。在数据可靠性方面，Kafka 依赖 ISR 协议来保证数据的高可靠。

今天我们讲可观测性的第三部分：跟踪（Traces），在消息队列领域，Traces 通常被称为消息轨迹，意思是消息在系统中的运行轨迹。消息轨迹在业务消息方向是刚需，因为业务消息如果出现丢失，大概率会导致流程异常比如订单的快递运送流程没有正确处理一条订单号的消息，后续就会出现无法跟踪这个订单派送的问题。如果你负责过消息队列基础服务的日常值班，一定会经常接到用户反馈说消息丢了，想让平台查清楚为什么丢了。这个问题，你会怎么排查呢？如果想排查清楚，我们首先要搞清楚有没有丢，如果丢了，还要搞清楚是哪一个环节丢的。

可观测性”是近几年技术圈很火的话题，特别是 OpenCensus 和 OpenTracing 合并成立 OpenTelemetry 后，可观测性的发展速度越来越快，越来越成熟。OpenTelemetry 主要是解决可观测性数据的获取规范问题，类似消息队列领域的 AMQP 和 OpenMessaging，目的都是打造一个标准化规范。它系统地将可观测性分为指标（Metrics）日志（Logs）跟踪（Traces）三个方面在消息队列领域，可观测性建设主要也是围绕着这三点展开。

数据维度的自我保护主要指如何保证服务端数据的安全，不被窃取。服务维度的自我保护主要指集群的限流机制，通过限制客户端的流量、请求、连接等保护自身不被击垮。我们先来看一下如何保证存储的数据不会被第三方窃取。集群在运行过程中，需要保证存储的数据安全，不会被第三方窃取，也需要能够保护好自身的服务，不会因为外力的原因而崩溃。即使在服务异常的情况下，也尽量保证自身的服务部分可用。数据保护的核心逻辑是通过加密保护数据。加密算法的选择需要兼顾安全性和加解密的速度。

近几年业界的安全问题频繁发生，系统数据的安全性也越来越受到重视。作为消息队列的主要使用者， 消息队列是如何保证数据安全的？网络隔离、传输安全、集群认证、资源授权、自我保护、数据加密今天我们先来聊一聊网络隔离、传输安全、集群认证、资源授权四个部分，整体了解一下集群的安全控制，思考如何在传输过程、访问控制两方面保证数据安全消息队列的安全性主要由四部分组成，分别是：网络间的隔离（网络隔离）、传输过程中的安全性（传输安全）、连接建立时的身份认证（集群认证）、连接建立后的访问控制（资源授权）。

这里总结了一些用 Java 开发存储系统时经常会用到的技巧。在我的经验中，我认为在大的设计框架差别不大的情况下，性能差异很多就是- 因为这些不起眼的细节。这里我们主要讲的是 IO 相关的优化操作，主要是因为消息队列本身就是一个重 IO 的存储系统，IO 模块的性能提升是整个系统性能提升的关键。Java IO 性能核心还是缓存、批量写和异步刷盘。从使用的角度，基本只要关注即可。在一些极限场景下，可以关注一下Direct IO的使用。同步刷盘并不是噩梦，可以通过一些代码上的优化，来提高同步刷盘的能力。

一般我们讲分布式系统一致性和可靠性时，都会用大量的篇幅去讲 CAP、Raft、Paxos 等一致性协议。其实是没问题的，不管是 ZooKeeper 的 Zab、Kafka 的 ISR 和 KRaft，还是 Pulsar 基于 BookKeeper 实现的一致性协议，都是 Paxos 和 Raft 的实现或简化。如果对分布式系统的设计感兴趣，建议深入研究一下 CAP、Raft 和 Paxos。在消息队列中，都会通过主从架构和控制分区、副本的分布来提升集群性能和数据可靠性。在分区副本模型中，需要注意的是。

我们先来看元数据存储服务的设计选型。在消息队列的集群架构中，元数据存储服务的选型和实现是整个架构设计的核心，其他模块的设计实现都是围绕着元数据存储服务来展开的目前，消息队列的主流实现方式都是依赖第三方组件来完成数据存储，常见的有 ZooKeeper、etcd 等。为了简化架构，我们还可以通过在集群内自建元数据存储服务来替代第三方组件，虽然需要研发投入，但从架构长期演进的合理性来看，我是推荐这种方式的，毕竟后期架构会很简洁。

从技术上看，设计实现集群化的消息队列主要包含节点发现、节点探活、元数据存储、集群管理四个方面。接下来我们将围绕着这四个方面，来看一下具体是怎么思考、怎么实现集群的。集群构建的思路分为有状态服务和无状态服务，两种类型服务的构建思路是不一样的。有状态服务需要解决元数据存储、节点发现、节点探活、主节点选举等四部分。元数据存储主要有依赖第三方组件实现和集群内自定义实现元数据存储两个思路。第三方组件主要有 ZooKeeper、etcd 等，依赖第三方组件是当前主流的选择，因为其实现较为简单，前期稳定性较高。

在基础篇的课程中，我们了解了最简单的消息队列的构建过程和底层原理。接下来进阶篇将从集群构建、性能、可靠性、数据安全、可观测性几个方面展开。总结来说，我们将把单机的消息队列架构扩展成为分布式的高可靠、高性能的完整集群。我们会先分析消息队列集群中哪些环节可能存在性能瓶颈和可靠性风险，以便对消息队列的集群有一个整体认识。从技术上看，消息队列的性能和可靠性由生产者、Broker 集群、消费者三方共同保障，而不只是服务端的工作。通常衡量集群性能的一个重要指标是全链路耗时。

近几年，作为消息队列后起之秀的 Pulsar，因为其存算分离、多租户、多协议、丰富的产品特性、支持百万 Topic 等特点，逐渐为大家所熟知。从定位来看，Pulsar 希望同时满足消息和流的场景。从技术上来看，它当前主要对标的是 Kafka，解决 Kafka 在流场景中的一些技术缺陷，比如计算层弹性、超大分区支持等等。从产品定位上来看，Pulsar 把自己定位为 Kafka 的升级版。

在学习的过程中，我们会发现 Kafka 和 RocketMQ 的架构是非常像的，那为什么还要单独来分析 Kafka 呢？因为它们俩面对的场景是不一样的，一个是消息场景、一个是流场景，所以它们在底层的协议设计、存储模型、消费方式的实现上也是不一样的。而实现的不同，又导致了它们在功能和性能上的表现不一样。接下来我们就从底层原理的角度来看一下，它们都有哪些异同点。最后，我们再来总结一下 Kafka。协议层只支持私有的 Kafka Protocol 协议。

RocketMQ 在功能、稳定性、性能层面都比 RabbitMQ 的表现更好总结一下 RocketMQ。协议层支持 Remoting 和 gRPC 两种协议。网络层是基于 Java NIO 框架 Netty 开发，底层也是通过多路复用、异步 IO、Reactor 模型等技术来提高网络模块的性能。存储层是基于多个 MessageQueue 的数据统一存储到一个文件的思路来设计的，同时也支持分段存储和基于时间的数据过期机制。

继续 消费分组（订阅）、消费确认、消费失败处理 的设计自定义分区分配算法，跟生产端数据的分区分配策略是一样的，内核会提供接口，用户可以根据自身需求实现自定义算法，然后指定配置生效即可。比如 Kafka 提供了接口来提供自定义分区分配策略。满足基本的消费需求，能消费到数据，确认数据。满足稳定性和性能的需求，能快速稳定地消费到数据。支持功能方面的需求，比如回溯消费、消费删除、广播消费等等。

消费端 SDK 和生产端 SDK 一样，主要包括客户端基础功能和消费相关功能两部分。客户端基础功能MQ - 06 基础篇_生产者客户端SDK设计，我们就不再重复。从实现来看，消费相关功能包括消费模型、分区消费模式、消费分组（订阅）、消费确认、消费失败处理五个部分。在消费端，为了提高消费速度和消息投递的及时性，需要选择合适的消费模型，目前主流有Pull、Push、Pop 三种模型。这三种模型的应用场景都不一样。目前业界主流消息队列使用的都是 Pull 模型。

在使用消息队列的 SDK 生产消费数据的时候，是否会有疑问，SDK 底层是怎么工作的，由哪些功能模块组成呢？消息队列的客户端主要包含生产、消费、集群管控三类功能。这里我们聚焦在生产和集群管控。从客户端 SDK 实现的角度来看，生产模块包含客户端基础功能和生产相关功能两部分，其中基础功能是客户端中所有功能共用的【生产模块的功能结构图】基础功能是蓝色部分，包括请求连接管理、心跳检测、内容构建、序列化、重试、容错处理等等。

MQ - 04 基础篇_存储_消息数据和元数据的存储设计我们讲了消息队列存储模块的功能实现，今天我们来讲存储模块的性能优化。存储模块的性能优化，核心要解决的其实就是两个问题：“写得快”和“读得快”。这两个问题如何解决呢？我们从四点和存储性能优化有关的基础理论讲起。内存读写的效率高于硬盘读写批量读写的效率高于单条读写顺序读写的效率高于随机读写数据复制次数越多，效率越低写入性能优化的核心是缓存写、批量写、顺序写。

消息数据和元数据的存储是如何设计的？存储模块作为消息队列高吞吐、低延时、高可靠特性的基础保证，可以说是最核心的模块。从技术架构的角度来看，存储模块包含功能实现和性能优化两个方面，我们今天先聊存储模块的功能设计和实现那对于消息队列这样有特殊需求的存储模块，我们在实现功能的时候要注意哪些事情呢？首先，一个前置信息，消息队列中的数据一般分为元数据和消息数据。元数据是指 Topic、Group、User、ACL、Config 等集群维度的资源数据信息消息数据指客户端写入的用户的业务数据。