Java最全同程旅行基于 RocketMQ 高可用架构实践，Java工程师必看书籍

总结

总的来说，面试是有套路的，一面基础，二面架构，三面个人。

最后，小编这里收集整理了一些资料，其中包括面试题（含答案）、书籍、视频等。希望也能帮助想进大厂的朋友

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

之前单机房出现过网络故障，对业务影响较大。为保障业务高可用，同城双中心改造提上了日程。

​

为何做双中心

---

​

• 单机房故障业务可用；​

• 保证数据可靠：若所有数据都在一个机房，一旦机房故障，数据有丢失风险；

• 横向扩容：单机房容量有限，多机房可分担流量。

​

双中心方案

---

​

做双中心之前，对同城双中心方案作了些调研，主要有冷（热）备份、双活两种。（当时社区 Dledger 版本还没出现，Dledger 版本完全可做为双中心的一种可选方案。）

​

1）同城冷（热）备份

​

两个独立的 MQ 集群, 用户流量写到一个主集群，数据实时同步到备用集群，社区有成熟的 RocketMQ Replicator 方案，需要定期同步元数据，比如主题，消费组，消费进度等。

​

2）同城双活

​

两个独立 MQ 集群，用户流量写到各自机房的 MQ 集群，数据相互不同步。

​

平时业务写入各自机房的 MQ 集群，若一个机房挂了，可以将用户请求流量全部切到另一个机房，消息也会生产到另一个机房。

​

对于双活方案，需要解决 MQ 集群域名。

1）若两个集群用一个域名，域名可以动态解析到各自机房。此方式要求生产、消费必须在同一个机房。假如生产在 idc1 ，消费在 idc2 ，这样生产、消费各自连接一个集群，没法消费数据。

2）若一个集群一个域名，业务方改动较大，我们之前对外服务的集群是单中心部署的，业务方已经大量接入，此方案推广较困难。

为尽可能减少业务方改动，域名只能继续使用之前的域名，最终我们采用一个 Global MQ 集群，跨双机房，无论业务是单中心部署还是双中心部署都不影响；而且只要升级客户端即可，无需改动任何代码。

双中心诉求

---

​

• 就近原则：生产者在 A 机房，生产的消息存于 A 机房 broker ； 消费者在 A 机房，消费的消息来自 A 机房 broker 。

• 单机房故障：生产正常，消息不丢。

• broker 主节点故障：自动选主。

就近原则

---

​

简单说，就是确定两件事：

• 节点（客户端节点，服务端节点）如何判断自己在哪个 idc；

• 客户端节点如何判断服务端节点在哪个 idc。

如何判断自己在哪个 idc?

​

1. ip 查询

节点启动时可以获取自身 ip ，通过公司内部的组件查询所在的机房。

​

2）环境感知

需要与运维同学一起配合，在节点装机时，将自身的一些元数据，比如机房信息等写入本地配置文件，启动时直接读写配置文件即可。

我们采用了第二个方案，无组件依赖，配置文件中 logicIdcUK 的值为机房标志。

​

客户端节点如何识别在同一个机房的服务端节点？

​

客户端节点可以拿到服务端节点的 ip 以及 broker 名称的，因此：

​

• ip 查询：通过公司内部组件查询 ip 所在机房信息；

• broker 名称增加机房信息：在配置文件中，将机房信息添加到 broker 名称上；

• 协议层增加机房标识：服务端节点向元数据系统注册时，将自身的机房信息一起注册。

相对于前两者，实现起来略复杂，改动了协议层， 我们采用了第二种与第三种结合的方式。

就近生产

---

​

基于上述分析，就近生产思路很清晰，默认优先本机房就近生产；

​

若本机房的服务节点不可用，可以尝试扩机房生产，业务可以根据实际需要具体配置。

就近消费

---

​

优先本机房消费，默认情况下又要保证所有消息能被消费。

​

队列分配算法采用按机房分配队列

​

• 每个机房消息平均分给此机房消费端；

• 此机房没消费端，平分给其他机房消费端。

​

伪代码如下：

​

Map<String, Set> mqs = classifyMQByIdc(mqAll);

Map<String, Set> cids = classifyCidByIdc(cidAll);

Set<> result = new HashSet<>;

for(element in mqs){

result.add(allocateMQAveragely(element, cids, cid)); //cid为当前客户端

}

​

消费场景主要是消费端单边部署与双边部署。

​

单边部署时，消费端默认会拉取每个机房的所有消息。

双边部署时，消费端只会消费自己所在机房的消息，要注意每个机房的实际生产量与消费端的数量，防止出现某一个机房消费端过少。

单机房故障

---

​

• 每组 broker 配置

一主两从，一主一从在一机房，一从在另一机房；某一从同步完消息，消息即发送成功。

​

• 单机房故障

消息生产跨机房；未消费消息在另一机房继续被消费。

故障切主

---

​

在某一组 broker 主节点出现故障时，为保障整个集群的可用性，需要在 slave 中选主并切换。要做到这一点，首先得有个broker 主故障的仲裁系统，即 nameserver（以下简称 ns ）元数据系统（类似于 redis 中的哨兵）。

​

ns 元数据系统中的节点位于三个机房（有一个第三方的云机房，在云上部署 ns 节点，元数据量不大，延时可以接受），三个机房的 ns 节点通过 raft 协议选一个leader，broker 节点会将元数据同步给 leader, leader 在将元数据同步给 follower 。

​

客户端节点获取元数据时, 从 leader，follower 中均可读取数据。

​

切主流程

​

• 若 nameserver leader 监控到 broker 主节点异常, 并要求其他 follower 确认；半数 follower 认为 broker 节点异常，则 leader 通知在 broker 从节点中选主，同步进度大的从节点选为主;

• 新选举的 broker 主节点执行切换动作并注册到元数据系统；

• 生产端无法向旧 broker 主节点发送消息。

​

流程图如下

切中心演练

​

用户请求负载到双中心，下面的操作先将流量切到二中心—回归双中心—切到一中心。确保每个中心均可承担全量用户请求。

先将用户流量全部切到二中心

流量回归双中心，并切到一中心

​

回顾

• 全局 Global 集群

• 就近原则

• 一主二从，写过半消息即及写入成功

• 元数据系统 raft 选主

• broker 主节点故障，自动选主

​

MQ 平台治理

============================================================================

​

即使系统高性能、高可用，倘若随便使用或使用不规范，也会带来各种各样的问题，增加了不必要的维护成本，因此必要的治理手段不可或缺。

​

目的

---

​让系统更稳定

• 及时告警

• 快速定位、止损

​

最后

现在正是金三银四的春招高潮，前阵子小编一直在搭建自己的网站，并整理了全套的**【一线互联网大厂Java核心面试题库+解析】：包括Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等**

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

稳定

• 及时告警

• 快速定位、止损

​

最后

现在正是金三银四的春招高潮，前阵子小编一直在搭建自己的网站，并整理了全套的**【一线互联网大厂Java核心面试题库+解析】：包括Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等**

[外链图片转存中…(img-2XvDNBIw-1715341029629)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取