微服务架构

如何成为一名优秀的架构师？

一名优秀的架构师应该具备如下几个特点：

第一、强烈的好奇心。

不只是对软件技术本身，对大千世界都保持强烈的好奇心，强烈的好奇心能够让你敏锐地发

现有潜力的重要的新技术；

第二、敏锐的业务嗅觉。

工程技术不同于科学研究，工程技术最终要服务于实际业务的，要产生实际价值，是要赚钱

的，那么业务需要什么样的功能，需要什么样的技术去实现，都需要有敏锐的业务嗅觉；

第三、扎实的技术基础。

基本功一定要扎实，如操作系统、数据结构、数据库原理，编程语言和算法原理，设计模式

和设计原则等。只要这些软件技术基础都扎实了，才能构建起敏锐的技术嗅觉，才能构建起

自己坚实的技术体系；

第四、出色的编程能力。

虽然可能再需要你写代码，但是要有出色的编程能力，这样才能对架构中那些最敏感的技术

点保持敏锐的技术嗅觉，能够抓住软件的关键点，不会在纷繁复杂的问题中迷失方向；

第五、深刻领悟主流技术产品和模式。

架构师不是凭空进行架构设计，是站在巨人的肩膀上，在现有的其他优秀架构基础上进一步

设计出符合自己业务特点的架构系统。只有深刻领悟主流技术产品和模式是如何设计的，才

能根据自己的业务特点，去其糟粕，做最好的匹配和改进，从而设计出属于自己的优秀的系

统。

微服务入门

什么是微服务？

微服务是一种分布式架构，简单点就是将整体大应用，基于业务打散为更为微小的服务。然

后作为独立的进程进行开发、测试、部署、运行、维护。

微服务架构诞生的背景？

服务大了太臃肿，要拆成若干个小系统，然后进行分而治之（例如北京一个火车站到多个火

车站）。

这样分了以后，可以把每个服务作为一个独立的开发项目，由团队进行快速开发、迭代升级。

为什么需要微服务架构？

对系统分而治之 , 故障隔离、同时解决因并发访问过大带来的系统复杂性 ( 例如 : 业务 , 开发 ,

测试 , 升级 , 可靠性等 )

微服务架构可能带来什么问题？

数据一致性问题、网络通信故障、限流与熔断机制、调用链路跟踪 (sleuth 与 zipkin) 、集

群监控、用户登录与权限管理。

微服务解决方案有哪些？

大厂一般会自研 , 中小企业采用开源 Spring Cloud Netfix （大部分组件停止更新），

Spring Cloud Alibaba （一站式解决方案） ,Spring Clound Tencent( 一站式解决方案 )

等

微服务架构中有哪些关键组件？

注册中心、配置中心 , 限流降级 ,API 网关 , 链路追踪和监控，统一认证服务，分布式事务管

理等

注册中心部分

服务注册中心诞生的背景？

注册中心本质上就是存储服务信息的一个服务 , 也可以理解为一个中介 ( 这里用到了中介者

模式 ) 。我们知道服务多了，需要统一管理。例如所有公司需要在工商局进行备案，淘宝也

可以理解为买家和卖家的注册中心。

服务注册中心你是如何选型的？

选型时，我们首先要从这样的几个维度进行思考：

1) 社区活跃度 ( 用户群的大小 )

2) 稳定性

3) 功能

4) 性能

5) 学习成本。

你了解哪些服务注册中心？

Zookeeper,Eureka,Nacos( 阿里 ),Consul

说说你对 Nacos 的理解？

Nacos 是 Alibaba 基于 SpringBoot 技术实现的一个注册中心 , 配置中心，本质上也是一个

web 服务，

提供了服务的注册 , 发现 , 配置等功能。可以作为各个服务的一个中介，也就是所谓的中介者

模式。

Nacos 如何检测服务状态？

通过心跳包实现 , 服务启动时会定时向 nacos 发送心跳包 -BeatInfo 。默认是每隔 5 秒发送

一次， Nacos 会通过对心跳包的监控判断服务的状态 ( 是否健康 ) 。

Nacos 注册中心有哪些常用配置？

我们可以在项目的 application.yml 中进行服务的注册配置，例如：

 

服务之间进行调用你是如何实现的？

在微服务架构中，服务之间调用一般有两种方式：

1) Restful 方式（直接基于 http 协议进行远端服务调用，数据格式标准，通用性强，代

表作品有 SpringCloud 中的 OpenFeign ）

2) RPC 方式 ( 直接基于 tcp 协议进行远端服务调用，协议数据格式不够通用，但是效率会

比较好，代表组件有 Dubbo)

你是如何理解 OpenFeign 的？

它基于 restful 方式进行声明式服务调用的一个服务调用组件，它可以嵌入到服务调用的

客户端服务中，然后由客户端基于 Feign 代理以及 Restful 规范进行服务调用。

微服务调用过程中你用的负载均衡组件是什么？

SpringCloud 中基于 Feign 方式进行远程服务调用时，负载均衡组件默认使用的是 Ribbon 。

Ribbon 组件中内置了一些负载均衡算法，我们可以基于业务、策略选择不同的算法进行服

务的负载均衡调用。

常用负载均衡算法有哪些？

轮询、哈希（每次请求都对应同一个服务器）、权重 ( 能者多劳 ) 、重试、随机等

配置中心部分

诞生的背景？

实际项目中我们会有很多配置，例如连接数据库的配置，日志级别的配置，负载均衡的配置，

限流算法的配置，缓存是否开启等，这些配置起初可能是写在配置文件，但是项目上线以后，

我们直接再通过配置文件方式修改具体配置就不太方便了，即使可以，那我们修改了配置件

是否要重启系统呢？你重启气筒时，系统是否要停止对外界服务呢？，基于这些问题“配置

中心”就诞生了。

什么是配置中心？

配置中心是存储项目（服务）配置信息的一个服务，这个服务可以对所有服务的配置进行统

一管理，并且可以实现配置的动态发布和更新（更新了配置中心的数据，微服务中的配置数

据会自动更新）。

为什么要使用配置中心？

集中管理配置信息，动态发布配置信息，服务自动感知配置 , 提高服务可用性。例如实际项

目中我们数据库的账号和密码可能每隔两周或 1 个月都要更新一下（更新的目的是要保证

系统的安全），假如应用了配置中心，我们可以直接在配置中心进行更新即可，它会自动同

步到具体的服务，我们不需要重启服务就可以获取最新的配置了。

你在配置中心配置过什么内容？

连接数据库配置，负载均衡策略、连接池，日志、缓存、限流、熔断规则。

为什么要定义 bootstrap.yml 文件？

此文件属于系统级配置文件，被读取的优先级比较高（比 application.yml 的优先级还要

高），可以在服务启动时基于这个配置文件中的配置，访问配置中心，然后读取配置中心的

数据。然后通过这些数据来更新配置。

配置中心宕机了，还可以读到配置信息吗？

配置中心的数据可以在服务本地存储一份，所以配置中心宕机了，可以从本地内存读取。

微服务配置中心如何感知配置中心的配置的变化？

1.4.x 版本中的 nacos 客户端会基于长轮询机制从 nacos 获取配置信息。这个轮询可以这

样去理解，

我们骑着共享单车去火车站买票，但是票卖完了，一种方式是直接返回（这种方式称之为短

轮询）。还有一种方式在火车站的椅子上等一会，看看是否还会放票，是否有人会退票等。

那这种机制就是长轮询 (nacos 默认长轮训的时间为 30 秒，就是服务会每隔 30 秒去访问一

次 Nacos) 。

Nacos 的配置管理模型是怎样的？

在 nacos 中的配置管理模型中，一个 namespace 可以有多个分组（ group ），每个分组下又

可以有多个服务实例。

例如： namespace>group>service/data-id

Nacos 配置中心基础配置有哪些？

 限流降级部分

为什么要限流？

请求量比较大 , 但是系统资源处理能力不足。类似车辆限号。

你了解哪些限流组件

阿里巴巴的 Sentinel( 双十一 ),....

你了解哪些限流算法？

计数器 , 令牌桶 , 漏桶 , 滑动窗口算法。

Sentinel 如何对请求进行限流？

可以基于 Spring MVC 拦截器以及 aop 方式对请求进行限流（链路限流、热点数据限流）。

当请求传递到服务端后，服务器可以调用拦截器对请求进行拦截，判定此请求是否允许放行，

请求量太大可能就要被限制了。当然在热点数据限流上还可以通过 AOP 方式进行限制。

Sentinel 出现限流时的异常类型是什么？

BlockException （限流的异常类型 - 父类类型） ?

Sentinel 中默认的异常处理器是什么？

DefaultBlockExceptionHandler ，假如默认的异常处理器不能满足我们需求时，可以自

己定义异常处理器 ，直接或间接继承 BlockExceptionHandler 。

Sentinel 限流的阈值类型有哪些？

QPS （每秒请求次数），线程数（不准确，应用相对较少）

Sentinel 的流控模式有哪些？

1) 直接模式：直接对请求 url 进行限流，

2) 关联模式：一种霸权主义，要保证我 ( 核心业务 ) 先行。

3) 链路模式：对同一个资源的访问有多条链路，然后对指定链路进行限流。

如何理解 Sentinel 的关联限流？

霸权方式 , 当对 A 的资源的访问量比较大时 , 限流其它资源的访问 ( 例如我们可以优先保证创

建订单可以成功、查询订单可以被限流。 )

如何理解 Sentinel 的链路限流？

对同一个资源的访问 , 可能会有多条链路 , 可以对指定链路进行限流。（例如对 Google 的访

问）。

@SentinelResource 注解的作用是什么？

定义限流切入点方法 , 底层可以基于 aop 方式对请求链路进行限制（一般应用于链路限流、

热点数据限流）。对应的切面（ SentinelResourceAspect ）。

Sentinel 常见的限流效果是什么？

快速失败（抛出异常） ,warm up （预热方式 -3 秒放 100 请求） , 排队等待（超过的 QPS 的

数量的请求等待）

什么是服务降级？

系统出现大量的慢调用（一个请求响应的时间比较长）或一些异常（经常运行过程中会出现

异常），可以对这些服务进行熔断 - 暂时关闭系统

如何理解慢调用？

客户端发起一个请求，得到服务端的响应比较慢。当然一般会给出一个时间标准（我们自己

定义）

如何理解热点数据？

频繁访问的数据 - 例如文章、视频、图片、 ....

Sentinel 如何判断哪些数据是热点数据？

LRU 算法（最近最少使用算法 - 一般应用于缓存淘汰策略。）

对热点数据限流，底层基于什么机制去实现？

AOP (@SentinelResuource 注解定义切入点方法，然后在 SentinelResourceAspect 切

面中基于限流策略，进行限流。 )

 

API 网关部分

为什么要使用 API 网关？

1) 统一 url 访问（ Restful ， RPC ） : 一个页面中的数据可能来自多个服务

2) 服务保护（不对外暴露内部服务的真实地址，同时可以对外部请求进行校验）

3) 统一身份认证（单点登陆系统 - 不用每个服务都编写一个登陆认证模块 - 公园的通票）

4) 统一跨域设计（跨域可以在客户端配置，也可以在服务端配置 - 例如 nginx,gateway,… ）

5) 限流降级 ( 通过 Sentinel 实现限流和降级 )

6) 黑白名单 ( 通过全局过滤器 GlobalFilter 去实现对请求的统一校验 )

API 网关都可以配置什么？

1) 动态路由（ uri ， predicate ， filter ）

2) 统一身份认证

3) 负载均衡 (Ribbon)

4) 黑白名单设计 ( 自定义 )

5) 限流熔断 (Sentinel)

6) 跨域等

7)……

API 网关中的负载均衡如何实现？

Ribbon

SpringCloud Gateway 处理请求的基本流程？

 

 

1) 客户端向 Spring Cloud Gateway 发出请求。

2) 基于 GatewayHandlerMapping 调用谓词 predicates(predicates) 的集合判定请求与

路由 (Routers) 是否匹配，不匹配则抛出异常。

3) 将请求其发送到 Gateway Web Handler 。此对象基于路由配置调用过滤链中的过滤器

（也就是所谓的责任链模式）进一步的处理请求。

4) 将请求转发到具体的服务。

网关中谓词(Predicate)的作用是什么？

这里的 Predicate 都是基于 Jdk8 中的 Predicate 接口实现的，用于对请求 url 、请求数

据进行校验，符合规则再交给过滤器去处理。

你知道哪些谓词对象(Predicate)对象？

1) Path 相关的 （请求路径是否匹配）

2) 日期时间相关的 （请求时间的限制）

3) IP 相关的 （ ip 地址的限制）

4) Cookie 相关的 ( 基于 Cookie 中数据的限制 )

5) 请求参数相关的

6) 请求方式相关

7) 请求头相关的

8) 上传文件大小相关的

9) …

网关中的过滤器是如何分类的？

1 ）全局过滤器 ( 不需要配置 ) ，作用于所有路由。

2 ）局部过滤器（这个需要针对具体路由进行配置），只作用于具体路由。

你知道 Gateway 中的哪些过滤器？

1) 负载均衡相关的

2) 请求转发相关的

3) 限流相关的

4) 请求前缀、后缀相关的

5) ...

API Gateway 如何基于 Sentinel 进行限流？

1) 依赖

2) 配置

分布式事务

 

什么是分布式事务？

分布式事务是分布式架构下的一种事务处理方式，是指位于不同的节点之上的事务参与者，

执行一系列操作时，要确保这些操作要么都执行成功，要么都执行失败。本质上来说，就是

为了保证不同数据库的数据一致性。

分布式系统中的 CAP 定理是什么？

分布式系统有三个指标：

1)Consistency ：一致性

2)Availability ：可用性

3)Partition tolerance ：分区容错性

这三个指标不可能同时满足，这个定理就叫 CAP 定理。

在分布式系统中，通常分区容错性是必须满足的，可用性 (AP) 和一致性 (CP) 只能选择其一。

BASE 理论是什么？

Base 全称是 Basically Available （基本可用）， Soft state （软状态），和 Eventually

consistent （最终一致性）三个短语的缩写， BASE 理论是对 CAP 中一致性和可用性权衡的

结果，核心思想是：即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用

适当的方式来使系统达到最终一致性（通常可以将这种事务方式理解柔性事务）。

分布式事务中的二阶段提交？

分布式事务中增加了一个新的角色，事务协调者（ Coordinator ），它的职责就是协调各个分

支事务的开启与提交、回滚的处理。当一个订单创建时，首先事务协调者会向各服务下达 “ 处

理本地事务 ” 的通知，所谓本地事务就是每个服务应该做的事情，如订单服务中负责创建新

的订单记录；会员服务负责增加会员的积分；库存服务负责减少库存数量。在这个阶段，被

操作的所有数据都处于未提交（ uncommit ）的状态，会被排它锁锁定。这个阶段也是二阶段

提交中的第一阶段（也称之为预处理阶段），如图所示：

 

当本地事务都处理完成后，会通知事务协调者“本地事务处理完毕”。当事务协调者陆续收

到订单、会员、库存服务的处理完毕通知后，便进入“阶段二：提交阶段”。

在提交阶段，事务协调者会向每一个服务下达提交命令，每个服务收到提交命令后在本地事

务中对阶段一未提交的数据执行 Commit 提交以完成数据最终的写入，之后服务便向事务

协调者上报 “ 提交成功 ” 的通知。当事务协调者收到所有服务 “ 提交成功 ” 的通知后，就意味着

一次分布式事务处理已完成。

这便是二阶段提交的正常执行过程，但假设在阶段一有任何一个服务因某种原因向事务协调

者上报“事务处理失败”，就意味着整体业务处理出现问题，阶段二的操作就自动改为回滚

（ Rollback ）处理，将所有未提交的数据撤销，使数据还原以保证完整性。

分布式事务中二阶段提交有什么缺陷？

对于二阶段提交来说，它有一个致命问题，当阶段二某个服务因为网络原因无法收到协调者

下达的提交命令，则未提交的数据就会被长时间阻塞，可能导致系统崩溃。

 

以上图为例，假如在提交阶段，库存服务实例与事务协调者之间断网。提交指令无法下达，

这会导致商品库存记录会长期处于未提交的状态，因为这条记录被数据库排他锁长期独占，

之后再有其他线程要访问库存数据，该线程就会长期处于阻塞状态，随着阻塞线程的不断增

加，库存服务会面临崩溃的风险。

那这个问题要怎么解决呢？其实只要在服务这一侧增加超时机制，过一段时间被锁定的库存

数据因超时自动执行提交操作，释放锁定资源。尽管这样做会导致数据不一致，但也比线程

积压导致服务崩溃要好，出于此目的，三阶段提交（ 3PC ）便应运而生。

分布式事务中的三阶段提交？

三阶段提交实际上是将二阶段中的提交阶段拆分为“预提交阶段”与“提交阶段”，同时在

服务端都引入超时机制，保证数据库资源不会被长时间锁定。下面是三阶段提交的示意流程：

阶段 1 ：事务预处理阶段， 3PC 的事务预处理阶段与 2PC 是一样的，用于处理本地事务，

锁定数据库资源，例如：

阶段 2: 当所有服务返回成功后，进入阶段二。预提交阶段只是一个询问机制，以确认所有

服务都已准备好，同时在此阶段协调者和参与者都设置了超时时间以防止出现长时间资源锁

定

当阶段二所有服务返回“可以提交”，进入阶段三“提交阶段”。 3PC 的提交阶段与 2PC 的

提交阶段是一致的，在每一个数据库中执行提交实现数据的资源写入，如果协调者与服务通

信中断导致无法提交，在服务端超时后在也会自动执行提交操作来保证资源释放。

三阶段提交本质上是二阶段提交的优化版本，主要通过加入预提交阶段引入了超时机制，让

数据库资源不会被长期锁定，但这也会带来一个新问题，数据一致性也很可能因为超时后的

强制提交被破坏，对于这个问题各大软件公司都在各显神通，常见的做法有：增加异步的数

据补偿任务、更完善的业务数据完整性的校验代码、引入数据监控及时通知人工补录这些都

是不错的补救措施。

Seata 是什么

Seata 是 Alibaba 开源的一款分布式事务解决方案，致力于在微服务架构下提供高性能和

简单易用的分布式事务服务。它的官网是 http://seata.io/ 。

Seata 提供了哪些分布式事务方案？

1) AT 模式（ 是 Seata 主推的分布式事务解决方案，对业务无侵入，真正做到业务与事务

分离 ）

2) TCC 模式（对业务代码侵入性太强。没有 AT 模式全局锁，加锁逻辑需要根据业务自行

实现。因此 TCC 的性能会比 AT 模式更好）

3) SAGA 模式（ Saga 模式的正向服务和补偿服务都需要手动实现，因此有很强的侵入性。

能保证隔离性，不容易进行并发控制 ）

4) XA 模式 （利用事务资源实现对 XA 协议的支持，是传统分布式强一致性的解决方案，

性能较低，在实际业务中使用较少。）

什么是 AT 模式事务？

AT(Automatic Transaction) 全自动事务，是 Seata 提供的一种事务方案。采用了简单

易用且无侵入的事务处理机制，通过自动生成反向 SQL 实现事务回滚。

反向 SQL 如何理解？

insert into test(id,name) values (1,’Jason’);

delete from test where id=1;( 可以将这样的语句理解为上面 SQL 的反向 SQL)

AT 模式事务有什么特点?

AT 模式是 Seata 独创的模式，它是基于 2PC( 两阶段提交 ) 的方案，核心理念是利用数

据库 JDBC 加上 Oracle 、 MySQL 自带的事务方式来对我们分布式事务进行管理。其主要

特点如下：

1) 对业务无侵入，通过配置即可实现。

2) AT 事务使用一个数据源 (DataSource) 代理对象来实现自动化事务处理。

3) AT 事务执行分两个阶段：

第一阶段：执行本地事务。

第二阶段：全局事务提交，或全局事务回滚。

4) AT 事务使用 undo_log 表保存回滚日志，事务执行失败时，会根据回滚日志表来回滚

数据。

Seata 的三大组件是什么？

Seata 有三个组成部分：

1) 第一个是事务协调者（ TC ） ，它的作用是维护全局和分支事务的状态，驱动全局事务提

交或者回滚，这正是前面所说 2PC 或者 3PC 方案时提到的事务协调者组件的具体实

现， TC 由 SEATA 官方提供。

2) 第二个是事务管理器（ TM ） ，事务管理器用于定义全局事务的范围，开始全局事务提交

或者回滚全局事务都是由 TM 来决定。

3) 第三个是资源管理器（ RM ） ，他用于管理分支事务处理的资源，并且报告分支事务的状

态，并驱动分支事务提交或者回滚。

Seata 事务协调器(TC)的作用是什么？

协调各个模块的执行，例如：

- 启动全局事务。

- 收集各模块第一阶段的运行状态。

- 向各个模块发送第二阶段提交或回滚指令。

Seata 事务管理器(TM)的主要作用是什么？

负责主要全局事务决策，例如：

- 向协调器申请启动全局事务。

- 收集所有模块第一阶段的运行状态，并对全局事务的成功或失败进行决策。

- 将决策结果提交给事务协调器。

资源管理器(RM)的作用是什么？

在各个模块中与协调器通信，并控制第二阶段的执行：

- 在每个模块中向协调器注册分支事务。

- 向协调器提交第一阶段的执行状态。

- 接收协调器第二阶段的指令，控制执行二阶段的提交或回滚。

AT 事务中数据源代理对象作用是什么？

自动保存事务回滚日志。

第二阶段提交时，删除回滚日志。

第二阶段回滚时，执行根据回滚日志回滚数据，并删除日志。

说说 TCC 模式的事务？

TCC 模式，全称 Try-Confirm-Cancel ，通过名称也能看出来其流程主要有三个步骤：

1) 预处理 Try ：实现业务检查和资源预留

2) 确认 / 提交 Confirm ：业务确认和提交

3) 撤销 / 回滚 Cancel ：业务回滚

TCC 模式本身就是二阶段提交的一种改进，不一样的是，这次就没有 AT 模式那么方便了，

因为他需要我们自己写代码来实现了。 Seata 中的 TCC 模式的实现关键在于拆分二阶段，

也就是如何把一步操作拆分为两步，比如库存扣减，本身就是一个 update 语句，但是 TCC

下却需要我们拆分为先冻结库存，然后再扣减这部分库存

 

交易系统服务拆分问题？

Xxx 面试者提到负责了一个交易系统的实现，并将系统拆分成了报价系统、促销系统、订单

系统。那现在的问题是，为什么要进行系统拆分，而且拆分后带来的其它复杂度，你是怎么

考虑的？

答复：

1 ）从订单系统层面来看，由于交易流程中的订单系统相对来说业务稳定，不存在很多的迭

代需求，如果耦合到整个交易系统中，在其他功能发布上线的时候会影响订单系统，比

如订单中心的稳定性。基于这样的考虑，需要拆分出一个独立的子系统。

2 ）从促销系统层面来看，由于促销系统是交易流程中的非核心系统，出于保障交易流程稳

定性的考虑，将促销系统单独拆分出来，在发生异常的时候能让促销系统具有可降级的

能力。

3 ）从报价系统层面来看，报价是业务交易流程中最为复杂和灵活的系统，出于专业化和快

速迭代的考虑，拆分出一个独立的报价系统，目的就是为了快速响应需求的变化。

最后，从复杂度评估层面来看，系统拆分虽然会导致系统交互更加复杂，但在规范了 API 的

格式定义和调用方式后，系统的复杂度可以维持在可控的范围内。

我觉得，这样的回答很好地表达了应聘者对系统设计的思考与理解。因为他说出了原有系统

中关于订单、促销和报价功能耦合在一起带来的实际问题，这是 立足于点 ，又从交易流程的

角度做系统设计串联起三个系统的拆分逻辑，这是 连接成线 ，最后从复杂度和成本考量的方

向夯实了设计的原则，这是 扩展成面。

点评系统逻辑设计是怎样的？

在电商中，当用户发表一条商品评论，后台的逻辑是，点评系统会调用一系列的远程 API

接口，如调用风控系统、广告系统、图片系统、消息系统等很多个外部系统接口，这样的逻

辑如何实现？

你可能会说，我引入了 MQ 消息队列，做了系统解耦，采用异步消息通知的方式来触发系统

调用。

面对类似问题，我觉得应该考虑这样几个层面？

第一：复杂度问题？（功能复杂度 - 耦合和非功能复杂度 - 高可用）

1) 功能上假如这些系统之间的通讯是直接的 RPC ，那就意味着耦合可能会比较大，不利于

扩展。

2) 非功能上 ( 高性能 -TPS/QPS 、高可用 )

第二：有哪些可选解决方案？

1 ）引入第三方消息队列 （会带来新的复杂度）

2 ）基于 Redis 实现消息队列

3 ）基于内存中数组实现消息队列

第三：你评估的标准是什么？

1 ）功能复杂度

2 ）非功能复杂度 ( 无单点、可水平扩展、可降级 )

第四：说一下你的技术实现？

当你在确定了具体的架构解决方案之后，需要进一步说明你技术上的落地实现方式和原理，

假如你最终选择基于 Redis 来实现消息队列，那么可以有几种实现方式？各自的优缺点有

哪些？对于这些问题，要做到心里有数。比如，基于 Redis List 的 LPUSH 和 RPOP 的

实现方式、基于 Redis 的订阅或发布模式，或者基于 Redis 的有序集合（ Sorted Set ）

的实现方式等等。