【八股消消乐】构建微服务架构体系—实现制作库与线上库分离

😊你好，我是小航，一个正在变秃、变强的文艺倾年。
🔔本专栏《八股消消乐》旨在记录个人所背的八股文，包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点，期待与你一同探索、学习、进步，一起卷起来叭！

题目

💬技术栈：微服务架构

🔍简历内容：熟悉主流隔离策略，为保证C端用户服务体验，实现制作库与线上库隔离。

🚩面试问：如果采用分组隔离策略，热点的放一组，非热点的放一组，你觉得可不可行？为什么？

---

💡建议暂停思考10s，你有答案了嘛？如果你有不同题解，欢迎评论区留言、打卡。

---

答案

热点数据不能集中放，因为热点数据一般的请求量很大，需要将热点数据均衡分配各个节点，降低热点数据造成的压力。

隔离

隔离：通过资源划分，在不同服务之间建立边界，防止相互影响的一种治理措施。

目的：

• 提升可用性，也就是说防止被影响或防止影响别人。这部分也叫做故障隔离。
• 提升性能， 这是隔离和熔断、降级、限流不同的地方，一些隔离方案能够提高系统性能，而且有时候甚至能做到数量级提升。
• 提升安全性， 也就是为安全性比较高的系统提供单独的集群、使用更加严苛的权限控制、迎合当地的数据合规要求等。

缺点：

• 带来资源浪费，需要更多钱， 维护它也需要钱。
• 隔离还容易引起资源不均衡的问题。比如说在连接池隔离里面，可能两个连接池其中一个已经满负荷了，另外一个还是非常轻松。

机房隔离

机房隔离：把核心业务单独放进一个机房隔离，不会和其他不重要的服务混在一起。

在这种形态下，其中一个机房崩溃了自然不会对另外一个机房有任何影响。

机房隔离：不同服务分散在不同的机房；
多活：同一个服务在不同的城市、不同的机房里面有副本。

实例隔离

实例隔离：某个服务独享某个实例的全部资源。

分组隔离

分组隔离：一起部署的服务上有多个接口或者方法，那么就可以利用分组机制来达成隔离的效果。

• B 端一个组，C 端一个组。
• 普通用户一个组，VIP 用户一个组。
• 读接口一个组，写接口一个组。这种也叫做读写隔离。比如说在生产内容的业务里面，没有实行制作库和线上库分离的话，那么就可以简单地把读取内容划分成一个组，编辑内容划分成另外一个组。
• 快接口一个组，慢接口一个组。这个和前面的读写隔离可能会重叠，因为一般来说读接口就是比较快。

连接池隔离和线程池隔离

两种都可以看作池子隔离，一个池子里面放的是连接，另一个池子里面放的是线程。

线程池隔离在 Java 里面被广泛使用。 Go 语言中，虽然存在所谓的 GMP 调度，里面有线程的概念，但是开发者是操作不了线程的。而协程过于廉价了，似乎不太值得做池化。

第三方依赖隔离

第三方依赖隔离：为核心服务或者热点专门提供数据库集群、消息队列集群等第三方依赖集群。

简历优化

确定隔离机制：

1. 数据库方面：你们公司有几个物理上的数据库（包括主从集群），有没有业务是独享某一个物理数据库的。
2. 你们公司有没有准备多个 Redis 实例或者多个集群。另外理论上来说开启了持久化功能或者被用作消息队列的 Redis 最好是一个独立的集群，防止影响正常将 Redis 用作缓存的业务。
3. 其他类似的中间件，包括消息队列、Elasticsearch等，是否针对不同业务启用了不同的集群。
4. 对核心业务、热点业务在资源配置上有没有什么特别之处。
5. 在业务上，有没有针对高价值用户做什么资源倾斜。
6. 在具体的系统上，有没有使用连接池隔离、线程池隔离等机制。
7. 因为缺乏隔离机制引起的事故报告。【大对象】
8. 因为组织关系引起的隔离。比如说公司 A 部门和 B 部门各自有独立的 Redis 集群，但这并不是出于隔离的目的有意设计的，而是纯粹因为两个部门的利益冲突才各自维护了一个 Redis 集群。

回答模板：

（1）BC 端隔离：

示例场景：为了保障我们 C 端用户的服务体验，我在我们的服务上利用微服务框架的分组功能做了一个简单的隔离。

解决方案：我们的服务本身部署了八个实例，我将其中三台实例分组为 B 端。于是商家过来的请求就只会落在这三台机器上，而 C 端用户的请求就可以落到八台中的任意一台。

核心目的：限制住 B 端使用的资源，但是 C 端就没有做任何限制。

（2）大对象：

示例场景：服务原本运行得很好，结果突然之间 Redis 就卡住了，导致Redis 请求大部分超时，请求都落到了数据库上，数据库负载猛增，导致数据库查询也超时。

原因分析：运维排查，确认了 Redis 在那段时间因为别的业务上线了一个新功能，这个功能会批量计算数据，产生的结果会存储在 Redis。但是这个结果非常庞大，所以在这个功能运行的时候，Redis 就相当于在频繁操作大对象。

解决方案：使用 Redis 的时候，分成了核心与非核心。核心 Redis 有更加严格的接入机制和代码 review 机制，而非核心的就比较随意。不仅如此，我们还为高并发的服务设计了数据库限流，防止再来一次 Redis 失效导致 MySQL 被打崩的事故。

慢任务隔离

有两种很常见的场景，我们会考虑开启一个线程池来处理。

• 异步任务：比如说收到请求之后直接返回一个已接收的响应，而后往线程池里面提交一个任务，异步处理这个请求。
• 定时任务：比如说每天计算一下热榜等。

存在的隐患：慢任务可能把所有的线程都占掉。

场景：我们的定时任务总不能及时得到调度。后来我们加上监控之后，发现是因为存在少数执行很慢的任务，将线程池中的线程都占满了。

解决方案：引入了线程池隔离机制，核心就是让慢任务在一个专门的线程池里面执行。

准备两个线程池：一个线程池专门执行慢任务，一个是执行快任务。

识别慢任务：当任务开始执行的时候，先在快任务线程池里执行一些简单的逻辑，确定任务规模。根据要处理的数据量的大小，分出慢任务。如果是快任务，就继续执行。否则，转交给慢任务线程池。

根据要处理的数据量的大小：例如找到数据库里面符合条件的数据，然后逐条处理。那么可以先统计一下数据库有多少行是符合条件的。如果数据量很多，就转交给慢任务处理。

也可以根据运行时间是否超过阈值。在识别循环处理数据里面比较好用。只需要在每次进入循环之前检测一下执行时长就可以了。

制作库与线上库分离

制作库：创作者正在创作的时候，他们的文章、视频等内容是存放在制作库的。
线上库：等到他们完成创作之后，点击发布的时候，就会保存到线上库。

场景：在我们的业务里面，采用了制作库和线上库分离的方案来保证业务的可用性和性能。

• 作者在 B 端写作，操作的都是制作库，这个过程 C 端读者是没有任何感知的。
• 当作者点击发布之后，就会开始同步给审核，审核通过之后就会同步给线上库。
• 在同步给线上库的时候，我们还会直接同步到缓存，这样作者的关注者阅读文章的时候就会直接命中缓存。
• 后面如果作者要修改文章，修改的也是 B 端制作库，等他修改完毕，就会再次提交审核。
• 审核完成之前，C 端用户看到的都是历史版本，这样 B 端和 C 端隔离保证了两边的用户体验。
• 同时拆成两个数据库之后，C 端线上库几乎都是读流量，性能很好。

---

往期精彩专栏内容，欢迎订阅：

🔗【八股消消乐】20250612：[构建微服务架构体系—限流算法优化]https://blog.csdn.net/m0_51517236/article/details/148607490)
🔗【八股消消乐】20250611：构建微服务架构体系—降级策略全总结
🔗【八股消消乐】20250610：构建微服务架构体系—熔断恢复抖动优化
🔗【八股消消乐】20250609：构建微服务架构体系—负载均衡算法如何优化
🔗【八股消消乐】20250608：构建微服务架构体系—服务注册与发现
🔗【八股消消乐】20250607：MySQL存储引擎InnoDB知识点汇总
🔗【八股消消乐】20250606：MySQL参数优化大汇总
🔗【八股消消乐】20250605：端午节产生的消费数据，如何分表分库？
🔗【八股消消乐】20250604：如何解决SQL线上死锁事故
🔗【八股消消乐】20250603：索引失效与优化方法总结
🔗【八股消消乐】20250512：慢SQL优化手段总结
🔗【八股消消乐】20250511：项目中如何排查内存持续上升问题
🔗【八股消消乐】20250510：项目中如何优化JVM内存分配？
🔗【八股消消乐】20250509：你在项目中如何优化垃圾回收机制？
🔗【八股消消乐】20250508：Java编译优化技术在项目中的应用
🔗【八股消消乐】20250507：你了解JVM内存模型吗？
🔗【八股消消乐】20250506：你是如何设置线程池大小？
🔗【八股消消乐】20250430：十分钟带背Duubo中大厂经典面试题
🔗【八股消消乐】20250429：你是如何在项目场景中选取最优并发容器？
🔗【八股消消乐】20250428：你是项目中如何优化多线程上下文切换？
🔗【八股消消乐】20250427：发送请求有遇到服务不可用吗？如何解决？

📌 [ 笔者 ]   文艺倾年
📃 [ 更新 ]   2025.6.12
❌ [ 勘误 ]   /* 暂无 */
📜 [ 声明 ]   由于作者水平有限，本文有错误和不准确之处在所难免，本人也很想知道这些错误，恳望读者批评指正！