架构师的36项修炼

异步架构的主要组成部分：消息生产者、消息消费者、分布式消息队列。异步架构的两种主要模型：点对点模型和发布订阅模型。

分布式消息队列异步架构的优点

从请求的发起一直到最终的处理完成期间，请求的调用方一直在同步阻塞，等待调用的处理完成

客户端的调用，也就是应用程序的调用，和业务逻辑真正发送邮件的操作是不同步的

创建一个合法的消息，并把这个消息发送到消息队列中

消息队列是消息发送的目的地，也是发给消费者过程中的一个缓冲

从消息队列中接收并处理消息，也是由应用开发者实现的，但是一个异步处理的组件

生产者发送消息到消息队列中，而消息队列的另一端是多个消费者竞争消费消息，每个到达消息队列的消息只会被路由到一个消费者中去

生产者发送消息到一个主题，而不是队列中。消息被发布到主题后，就会被克隆给每一个订阅它的消费者，每个消费者接收一份消息复制到自己的私有队列

使用点对点模型

使用发布订阅模型

实现异步处理，提升处理性能。
不必阻塞客户端的程序，客户端的程序在得到处理结果之前就可以继续执行，从而提高客户端程序的处理性能

让系统获得更好的伸缩性。
很容易地添加更多的机器成为消费者

使用消息队列，即便是访问流量持续的增长，系统依然可以持续地接收请求。这种情况下，虽然生产者发布消息的速度比消费者消费消息的速度快，但是可以持续地将消息纳入到消息队列中，用消息队列作为消息的缓冲，因此短时间内，发布者不会受到消费处理能力的影响。

分布式消息队列可以将消费者系统产生的错误异常与生产者系统隔离开来，生产者不受消费者失败的影响

使生产者和消费者的代码实现解耦合，也就是说可以多个生产者发布消息，多个消费者处理消息，共同完成完整的业务处理逻辑

生产者会创建两个消息，一个是创建用户，另一个是欢迎邮件。消费者应该先消费创建用户，然后再消费欢迎邮件，业务逻辑有先后顺序。实际上并行处理时可能会倒序处理。

分布式消息队列产品支持将某个消费者处理失败的消息重新放入到消息队列中，被其它的消费者重新处理

消息队列可以在分布式的环境下实现架构层面的并发执行，并发执行就可能会导致对资源的争用。在编程中我们通常使用锁的机制进行并发的控制，以避免竞态、顺序执行

消息队列使系统的架构和处理流程更加复杂，带来了更多的复杂性问题，从而也对架构师的系统架构设计能力和架构把控能力提出了更高的挑战和要求

有些分布式消息队列产品允许生产者阻塞，也就是生产者发送消息以后，阻塞等待消息队列处理结果，等消费者处理完成返回处理结果以后，继续向下执行

在消息中包含处理逻辑，也就是说在消息中约定消费者应该如何进行处理。或者是说使用特定的序列化协议编码消息。那么消费者必须要按照特定的序列化格式，才能解码消息。这些情况都使得生产者和消费者产生了不必要的耦合。

使用消息队列的时候，不能总是假定消息永远正确。对于引发消费者崩溃的消息，应该丢弃而不是重新处理

实现数据库读写分离——写操作访问主数据库，读操作访问从数据库，从而使数据库具有更强大的访问负载能力，支撑更多的用户访问

复制原理

优点

主主复制方案是指两台服务器都当作主服务器，任何一台服务器上收到的写操作都会复制到另一台服务器上。
当客户端程序对主服务器 A 进行数据更新操作的时候，主服务器 A 会把更新操作写入到 Binlog 日志中，然后 Binlog 会将数据日志同步到主服务器 B，写入到主服务器的 Relay log 中，然后执行 Relay log，获得 Relay log 中的更新日志，执行 SQL 操作写入到数据库服务器 B 的本地数据库中

MySQL 复制的注意事项
不要对两个数据库同时进行数据写操作，因为这种情况会导致数据冲突。
复制只是增加了数据的读并发处理能力，并没有增加写并发的能力和系统存储能力。
更新数据表的结构会导致巨大的同步延迟。

将一张数据表切分成较小的片，不同的片存储到不同的服务器上面去，通过分片的方式使用多台服务器存储一张数据表

分片的主要特点是数据库服务器之间互相独立，不共享任何信息，即使有部分服务器故障，也不影响整个系统的可用性。
通过分片键进行路由分区算法计算，查询对应的服务器

用刚才提到的分片键的路由算法。通过分片键，根据某种路由算法进行计算，使每台服务器都只存储一部分数据

映射关系存储在外面
根据数据定位自己要连接哪个服务器

将数据库切分成 32 个逻辑数据库，但是开始的时候只有两个物理服务器，我们把 32 个数据库分别启动在两个物理服务器上面。那么，路由算法就还是按照 32 进行路由分区，数据分片也是 32 片。当两台服务器不能够满足数据存储和访问要求的时候，我们只需要简单地将这些逻辑数据库迁移到其他的物理服务器上就可以完成扩容。因为迁移后数据分片还是 32 片，数据分片的算法不需要改变。数据迁移也仅仅是将逻辑数据库迁移到新的服务器上面去，而这种迁移通过数据库的主从复制就可以完成。

通过主从复制，实现一主多从。应用服务器的写操作连接主数据库，读操作从从服务器上进行读取

数据的业务分库是一种逻辑上的，是基于功能的一种分割，将不同用途的数据表存储在不同的物理数据库上面去

更复杂的综合部署方案，则是根据不同数据的访问特点，使用不同的解决方案进行应对。比如类目数据库，也许通过主从复制就能够满足所有的访问要求，但是如果用户量特别大，进行主从复制或主主复制，还是不能够满足数据存储以及写操作的访问压力，这时候就可以对用户数据库进行数据分片存储了，同时每个分片数据库也使用主从复制的方式进行部署

对于一个分布式系统，它不能够同时满足一致性（C）、可用性（A）以及分区耐受性（P）这三个特点。
一致性是说，任何时候集群中所有的数据的备份都是一致的；
可用性是说，当分布式集群中某些服务器节点失效的时候，集群依然是可用的；
分区耐受性是说所当网络失效的时候，节点无法通信的时候，系统依然是可用的。
而 CAP 原理就是说这三者无法同时满足

解决一致性冲突的方案就是实现最终一致性。
不同服务器上存储的同一个数据可能是不一致的，但是它最终还是一致的，只要不一致的时间不影响应用程序的正确性，我们就是可以接受的，这种一致性叫作最终一致性。

优化必须了解系统。
系统的架构是什么样子的？系统的关键技术点、瓶颈点在哪里？为何会产生这样的瓶颈点？以及如何对它进行优化？必须要在了解系统的基础之上才能进行优化。所以性能测试以及了解系统，是性能优化的两个关键前提。

主观

客观

性能测试

负载测试

压力测试

稳定性测试

横轴是系统资源或者并发用户数，对于性能测试，系统资源和并发用户数本质上是一样的，因为随着并发用户数的增加，系统资源消耗是线性增加的。纵轴是它的吞吐量 TPS。

1. 性能测试：在性能测试阶段，随着并发访问逐渐的增加，系统资源的不断消耗，TPS 是在不断上升的。
2. 负载测试：到了负载测试阶段，这种上升的斜率会变小，直到达到了系统负载能力的最大点，也就是 c 点。
3. 压力测试：而过了 c 点以后继续施加压力，继续提高并发请求的数量，系统资源消耗进一步增加，TPS 吞吐量不增反降，会呈现下降趋势。直到到达了某个点，d 点，系统超过了它的最大承受能力，系统崩溃

随着并发用户数的增加，以及系统资源的不断消耗，系统的响应时间在不断增加。在性能测试阶段，系统的响应时间几乎没有太多的变化，但是到了负载测试的时候，系统的响应时间就开始增加，当超过了它最大负载点——c 点以后继续增加压力，系统的响应时间会急剧增加，系统的性能状况急剧恶化，最后到达了它的崩溃点——d 点

硬件优化

中间件优化

架构优化

代码优化

通过构造一个非法的浏览器脚本，让用户跨站点去执行，从而达到攻击的目的。

URL 钓鱼攻击

直接攻击

恶意的攻击者在提交的请求参数里面，包含有恶意的 SQL 脚本。

跨站点请求伪造 CSRF
用户先登录受信任的服务器，然后又访问了被攻击的服务器。被攻击了的服务器返回的响应里面包含着用户访问受信任的服务器的请求，用户在不知情的情况下执行了请求，从而达到了攻击者的目的。

消毒

HttpOnly

消毒

参数绑定

表单Token

验证码

对一串明文信息进行单向散列加密以后，得到的密文信息是不可以解密的

场景

使用一个加密算法和一个密钥，对一段明文进行加密以后得到密文，然后使用相同的密钥和对应的解密算法，对密文进行解密，就可以计算得到明文

场景

非对称加密是指在加密的时候使用一个加密算法和一个加密密钥进行加密，得到一个密文，在解密的时候，必须要使用解密算法和解密密钥进行解密才能够还原得到明文，加密密钥和解密密钥完全不同

场景

贝叶斯分类算法，贝叶斯分类算法可以解决概率论中的一个典型问题

首先它开辟一块巨大的连续存储空间，比如说开辟一个 16G 比特的连续存储空间，也就是 2G 大的一个内存空间，并将这个空间所有比特位都设置为 0。然后对每个邮箱地址使用多种哈希算法，比如使用 8 种哈希算法，分别计算 8 个哈希值，并保证每个哈希值是落在这个 16G 的空间里的，也就是，每个 Hash 值对应 16G 空间里的一个地址下标。然后根据计算出来的哈希值将对应的地址空间里的比特值设为 1，这样一个邮箱地址就可以将 8 个比特位设置为 1。当检查一个邮箱地址是否在黑名单里的时候，只需要将邮箱地址重复使用这 8 个哈希算法，计算出 8 个地址下标，然后检查这 8 个地址下标里面的二进制数是否全是 1，如果全是 1，那么表示它就是在黑名单里头。使用布隆过滤器，记录同样大小的邮箱黑名单，可以比使用哈希表节约更多的内存空间。

一分钟有千万用户访问网站，大规模的并发用户访问对系统的处理能力造成冲击，产生巨大的访问流量

7*24小时不间断提供服务，保证系统高可用，必须要进行特别的系统架构设计

用户多，会产生大量数据，需要对这些数据进行重组和管理。还要通过大数据技术对这些数据进行进一步分析，对用户进行更精准的营销和服务

为全球用户提供服务，各地网络情况不同，使用户得到统一的良好体验，需要对系统架构进行相关的设计

互联网开放，所以很容易受到攻击

互联网产品快速适应市场，发布频率高

提升单台服务器的处理能力，比如说用更快频率、更多核的 CPU，用更大的内存，用更快的网卡，用更多的磁盘组成一台服务器，使单台服务器的处理能力得到提升

垂直伸缩的局限

使用更多的服务器，将这些服务器构成一个分布式集群。这个集群统一对外提供服务，来提高系统整体的处理能力。

水平伸缩优点和方案

最早的时候是单机系统，这时候可以满足少量用户的使用；
随着数据量提升，需要进行应用服务器与数据库分离，这时候可以满足万级用户的使用；
再然后需要通过分布式缓存和服务器集群提升系统性能，可以满足十万级的用户；
之后需要进行反向代理，CDN 加速，还需要数据库读写分离，以满足百万用户级的访问；
随着数据量爆发式增长，使用分布式文件系统和分布式数据库系统，以满足千万级用户的访问；
最后使用搜索引擎、NoSQL、消息队列、分布式服务等更复杂的技术方案，以满足亿级用户的访问。

少量用户访问

可达万级别访问

十万级用户访问

百万级用户访问

千万级用户访问

亿级用户访问

子主题

例：
1. CPU就有缓存，预加载一部分指令和数据到cache中。
2. 操作系统文件缓存，加快访问磁盘文件数据的速度。
3. 数据库的查询缓存，如索引的结构B+树进行缓存，对一些热点数据也要进行缓存。
4. 外部系统比较常用的有DNS客户端缓存、HTTP浏览器缓存、HTTP代理和反向代理缓存、CDN缓存、各种类型的对象缓存（Redis）

1. 缓存的数据来自于内存，访问速度更快

2. 缓存中存储的数据形态通常是最终的结果形态，减少资源消耗

3. 缓存可以降低数据库磁盘或网络的负载压力

缓存使用的数据结构主要是哈希表，最终的存储形式是一个顺序表，也就是一个数组结构。
通过先计算key的哈希值，找到hash表索引的位置，将key，value存到这个下标数组中。

从统计数字上看，唯一键越多，重用的机会越小。比如IP地址缓存天气，需要40亿个键。但如果用国家缓存天气数据，只需几百个。所有尽可能减少缓存键的数量

物理上缓存空间越大，缓存的对象越多，缓存的命中率也越高

缓存的时间越长，被重用的可能性就越高。
失效时间有两种：超时失效，清除失效

代理缓存是在应用程序一端的代理，缓存在客户端一端的，代理客户端访问互联网。它的主要作用是互联网访问代理。代理了所有客户端HTTP请求，所以它可以进行页面缓存。
一般情况不作为我们系统架构中的一部分，我们能够管理的是反向代理缓存。

通过互联网连到数据中心，连接通常是一个反向代理服务器，在本地的反向代理缓存中查找用户请求的数据

网络服务商的缓存服务，通过网络服务商提供的网络链接才能连接到数据中心，从CDN中查找静态资源（js，css，图片）数据，不存在则向数据中心请求并缓存到CDN服务器上，再返回客户端

通读缓存有需要访问的数据时，直接返回，没有，则向真正的数据提供者发出请求。

各种介质数据访问的延迟

使用虚拟节点。也就是说我们这一个服务器节点放入到一致性哈希环上的时候，并不是把真实的服务器的哈希值放到环上，而是将一个服务器虚拟成若干个虚拟节点，把这些虚拟节点的 hash 值放到环上去。在实践中通常是把一个服务器节点虚拟成 200 个虚拟节点，然后把 200 个虚拟节点放到环上。key 依然是顺时针的查找距离它最近的虚拟节点，找到虚拟节点以后，根据映射关系找到真正的物理节点

在面向服务的体系架构里面，服务的提供者向注册中心注册自己的服务，而服务的使用者向注册中心去发现服务。发现服务以后，根据服务注册中心提供的访问接口和访问路径对服务发起请求，由服务的提供者完成请求返回结果给调用者

单体应用系统架构，里面的各个模块互相调用、耦合，所有的系统和模块打包在一起，最后组成一个庞大的巨无霸系统。
微服务架构，根据服务的粒度和可复用的级别，对服务进行拆分，以独立部署服务的方式，对外提供服务调用。而应用系统也按照用途和场景的不同，依赖这些可复用的服务，进行逻辑组合，构建成自己的业务系统

接口调用考虑

1. 服务提供者
服务的提供者程序在 Dubbo 的服务容器中启动，服务管理容器向服务注册中心进行注册，声明服务提供者所要提供的接口参数和规范，并且注册自己所在服务器的 IP 地址和端口。
2. 服务消费者
服务的消费者如果想要调用某个服务，只需依赖服务提供者的接口进行编程。而服务接口通过 Dubbo 框架的代理访问机制，调用 Dubbo 的服务框架客户端，服务框架客户端会根据服务接口声明，去注册中心查找对应的服务提供者启动在哪些服务器上，并且将这个服务器列表返回给客户端。客户端根据某种负载均衡策略，选择某一个服务器通过远程通讯模块发送具体的服务调用请求。
3. 服务调用
服务调用请求，通过 Dubbo 底层自己的远程通讯模块，也就是 RPC 调用方式，将请求发送到服务的提供者服务器，服务提供者服务器收到请求以后，将该请求发送给服务提供者程序，完成服务的执行，并将服务执行处理结果通过远程调用通讯模块 RPC 返回给服务消费者客户端，服务消费者客户端将结果返回给服务调用程序，从而完成远程服务的调用，获得服务处理的结果。

Spring cloud 的服务提供者通过 Spring Boot 启动，然后向服务注册中心 Eureka Server 进行注册，而服务的消费者通过一个 Zuul 网关访问 Eureka Server 进行服务的发现，获得自己想要调用的远程服务对应的服务地址。获得地址以后，通过 HTTP 的方式向远程的服务提供者发起调用请求。服务提供者完成服务处理后，将处理结果通过 HTTP 返回。从而实现了远程的微服务调用。

熔断

降级

超时管理

1. 业务先行，先理顺业务边界和依赖，技术是手段而不是目的

2. 要有独立的功能模块，然后才有分布式的服务

3. 如果模块本身就是混乱的、耦合严重的、边界不清晰的、关系复杂的，那么，把它们拆分成独立的微服务进行部署，只会使事情变得更加复杂。

4. 要搞清楚实施微服务的目的究竟是什么，是为了业务复用，是为了开发边界清晰，是为了分布式集群提升性能，还是仅仅想要使用微服务？目的一定要清楚

注：
进行微服务架构设计之初，就要先做好业务模块的设计和规划。如果做不好模块的划分和耦合管理。那么，宁可晚一点进行微服务架构重构，也不要仓促上马，以免最后带来巨大的损失。
实施微服务的目的是什么：为了业务复用，为了开发边界清晰，为了分布式集群提升性能。

要根据需求去考虑具体的价值，再根据价值构建我们的设计原则，根据原则寻找最佳实践，最后根据实践去选择最合适的工具。按这样的方式去选择技术做架构设计才是比较成熟和高效的

将用户的请求处理过程，每一次的状态变化都记录到事件日志中，并按照时间序列进行持久化的存储，也就是说，把所有的变更操作都按日志的方式，按时间化序列进行记录。

分布式事务

在服务接口层面将查询操作（也就是读操作）和命令操作（也就是写操作）隔离开来，在服务层实现读写分离。
在读操作中：主要使用的优化方式是缓存操作。可以将接口层面的查询操作即读操作，尽量多地通过缓存来返回。
写操作：也就是命令操作，主要的性能优化方式是使用消息队列。可以将数据的更新操作，尽量通过消息队列，通过异步化的方式进行处理，以改善性能。

服务不可用，可以使用断路器对故障服务进行隔离，在 Spring Cloud 中可以使用 Hystrix 实现断路器。

要设置上游调用者的超时时间大于下游调用者的超时时间之和，相同的超时设置是没有意义的

子主题

一年大概有 53 分钟不可用。这个 99.99% 就叫做系统的可用性指标
年度可用性指标= 1 −（不可用时间/年度总时间）×100%

故障分类的计算方式是用故障时间乘以故障权重来计算得到的。而故障的权重通常是在故障产生以后，根据影响程度，由运营方确定的一个故障权重值

故障处理流程和故障时间

通过一个负载均衡服务器，将用户的请求分发给多个应用服务器，将多个应用服务器构建成一个集群，共同对外提供服务。
服务器宕机，要有检测并转发给其他服务器的能力，保证用户的请求是成功的。

实现方法

数据库复制与失效转移

限流：
是指对进入系统的用户请求进行限流处理，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的
注：最好别超过服务的最大处理能力

降级：
在高并发时，某些功能可以先关闭，将资源留下来给比较重要的功能。

数据中心分布在多个不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问

重点

采用自动化测试，通过自动化脚本自动对 APP 或者是服务接口进行测试

系统在线上运行的时候，必须要实时的监控系统的各项指标，包括业务指标和技术指标。业务指标包括用户访问量、订单量、查询量这些主要的业务指标，技术指标包括 CPU、磁盘、内存的使用率等。通过这些指标可以实时监控业务是否正常，系统是否正常。如果指标不正常，通过监控报警的手段，通知相关的人员，还可以在自动化监控的基础上去，触发自动化的运维工具，进行自动化的系统修复。

在线上的服务器集群里面有一台服务器，是专门的预发布服务器，这台服务器不配置在负载均衡服务器，也就是说外部的用户是无法访问到这台服务器的，但是这台服务器跟其它的应用服务器，使用的配置、连接的数据库、连接的第三方服务都是完全一样的，它是一个完全线上的一个服务器，而这个服务器只有内部的工程师才可以访问到。

在系统发布的时候，先发布到这台预发布服务器上，然后工程师通过域名绑定的方式，直接访问这台服务器，进行一些关键的业务操作，看系统是否正常。如果正常，那么就将代码同步到其它的服务器上，这时候外部服务器才能够访问到最新的代码。如果发现问题，那么就可以重新进行修复。这个问题虽然是线上的，但是并不会影响到外部用户的使用。预发布的工作原理如下图。

大型互联网系统，会使用一种灰度发布的手段，也就是说每天都只发布一部分服务器，如果出现问题，那么只需要回滚这一部分服务器就可以。发布以后观察一天，第二天再发布一部分服务器。如果没有故障报告，那么就继续发布，如果有故障报告就进行回滚，减少故障的影响力和影响时间。

应用端主要是移动端的应用，通过负载均衡访问 Web 服务器集群，也就是前端集群。
前端集群是两台 Nginx 服务器组成的，在 Nginx 再进行一次负载均衡，将用户请求分发到一组应用服务器集群。
应用服务器集群按照应用场景分为买家系统、卖家系统、供应链系统以及运营系统四个系统集群，
每个系统集群又包含了若干台服务器，所有这些系统都连接到一台 MySQL 服务器上。

优化
1. 前端使用CDN服务，用户请求的各种静态资源都通过 CDN 服务返回，而所有的商品图片，再通过一个分布式文件系统进行管理。
2. 应用服务器上又加了一个Redis集群
3. mysql做主从复制分离，一主两从分布式，其它业务可以从从服务器获取数据进行业务处理。
4. 大数据平台，对数据的处理的要求也比较高。除了各种各样的统计分析、竞对分析，还有各市场大区的绩效、具体到每个人的绩效都需要进行统计计算，所以专门搭建了一个大数据平台。

挑战

优化
1. 微服务拆分：将可复用的一些业务拆分为独立的微服务，进行分布式部署，供应用系统调用，典型的就是用户服务、商品服务、订单服务、红包服务等。
2. 数据库冷热分离：对数据库在原来的主从分离的基础上又做了一次冷热分离。把一部分订单完成的记录，由定时任务备份到其他历史数据库中（如NoSQL中）。保留近一个月的数据作为热点数据，存储访问压力、数据存储压力大大减轻。
3. 

进行海量的数据存储，也就是说可以在大规模服务器的集群上进行数据存储，可以进行透明的集群管理。

要求能够线性伸缩，当集群存储资源不足的时候，可以很容易地添加服务器到集群中，对集群进行平滑的扩容。

系统要高可用，要能够自动的容错和故障转移，当集群出现服务器宕机故障的时候，不会影响系统的读写，更不会出现数据丢失的情况。

同时要高性能，要在高并发的情况下，依然保持较低的响应时间。

还要具备灵活的扩展能力，可以很方便地扩展新功能。

要有较低的运维成本。可以在无需运维工程师的支持下进行集群的扩容、监控和故障管理。

客户端。Doris 给应用程序提供一个客户端的 SDK 包，客户端可以使用 Doris SDK 进行分布式的数据读写操作，Doris 支持存储 Key Value 这样的 KV 数据结构，跟缓存一样。客户端一方面连接 Doris 集群的控制中心 Administration，从控制中心获得配置信息，主要是获得服务器集群的地址端口、角色等配置信息，另一方面获得路由算法信息。

Administration。可以通过控制台进行集群的故障管理和扩容管理。

Data Server 数据存储。Data Server 也是真正的分布式数据存储的地方，Doris 对数据进行分片存储的。根据集群规模、配置信息和算法进行路由计算，计算每个 KV 应该存储的的 Data Server 服务器。Data Server 服务器也和 Administration 服务器进行通信，报告自己的健康状况。应用程序的 KV Client 与 Administration 之间的通讯，只包括配置或者控制信息的通信，不会进行数据通讯，也就是说真正的数据读写操作，只会在 Client 和 Data Server 之间，不需要通过 Administration 进行数据代理。

Doris 数据分区架构与分区算法

流由生产者生产，并由一或多个消费者消费的元素序列。这种生产者/消费者模型也称发布/订阅模型。

拉模式

推模式

子主题

如果消费者消费数据的速度赶不上生产者生产数据的速度，它就会持续消耗系统的资源。使得消费者可以根据自身当前的处理能力通知生产者来调整生产数据的速度，这就是背压

背压机制可以通知生产者当前处理能力，生产者则会调整生产消息的速度

原理

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-webflux</artifactId> 
    <version>{version}</version> 
</dependency>

在Spring WebFlux中，从任何操作返回的数据都打包到响应流中。 这种方法体现了两种类型，它们是WebFlux应用程序的构建块-Mono和Flux 。

Mono是返回零个项目或单个项目（ 0..1 ）的流，而Flux是返回零个或多个项目（ 0..N ）的流。

因此，在期望单个（或没有）结果（例如从数据库中检索唯一用户）时，将使用Mono ，而在期望多个结果或某种类型的集合时，将使用Flux 。