持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第23天，点击查看活动详情
文档参考：书名：《从程序员到架构师：大数据量、缓存、高并发、微服务、多团队协同等核心场景实战》-王伟杰
26.学习心得-冷热分离概述 - 掘金 (juejin.cn)
27.学习心得-如何分离冷热数据 - 掘金 (juejin.cn)
43.学习心得-基于MySQL的分表分库 - 掘金 (juejin.cn)
45.学习心得-如何更新redis缓存 - 掘金 (juejin.cn)
47.学习心得-写缓存实现思路 - 掘金 (juejin.cn)
50.学习心得-全链路日志 - 掘金 (juejin.cn)
1. 业务场景：如何预防一个服务故障影响整个系统
在一个新零售架构系统中，有一个通用用户服务（很多页面都会使用），它包含两个接口。
1）第一个是用户状态接口，包含用户车辆所在位置。它在用户信息展示页面都会用到，比如客服系统中的用户信息页面。
2）第二个接口用于返回给用户一个可操作的权限列表，它包含一个通用权限，也包含用户定制权限，而且每次用户打开App时都会使用它。而这两个接口各自会碰到相应的问题，下面分别讨论。
1.1 第一个问题：请求慢
用户状态的接口、服务间的调用关系如图10-1所示。在Basic Data Service（基础数据服务）中，接口/currentCarLocation需要调用第三方系统的数据，但第三方响应速度很慢，而且有时还会发生故障，导致响应时间更长，接口经常出现超时报错。
有一次，用户反馈App整体运行速度慢到无法接受的程度。运维人员通过后台监控查看了几个Thread Dump（线程转储），发现User API与Basic Data Service的线程请求数接近极限值，且所有的线程都在访问第三方接口（3rd Location API）。因为连接数满了，其他页面便不再受理User API的请求，最终导致App整体出现卡顿。
之前运维人员针对这个问题做过相关处理，考虑响应时间长，就把超时时间设置得很长，这样虽然超时报错少了，其他页面也保持正常，但是会导致客服后台查看用户信息的页面响应时间长。
1.2 第二个问题：流量洪峰缓存超时
户权限的接口、服务间的调用关系与上面类似，如图10-2所示。服务间的调用流程具体分为以下3个步骤。
1）APP访问User API。
2）User API访问Basic Data Service接口/commonAccesses。
3）Basic Data Service提供一个通用权限列表。因为权限列表对所有用户都一样，所以把它放在了Redis中，如果通用权限在Redis中找不到，再去数据库中查找。
所以把它放在了Redis中，如果通用权限在Redis中找不到，再去数据库中查找。
有一次，因为历史代码的原因，在流量高峰时Redis中的通用权限列表超时了，那一瞬间所有的线程都需要去数据库中读取数据，导致数据库的CPU使用率升到了100%。
数据库崩溃后，紧接着Basic Data Service也停了，因为所有的线程都堵塞了，获取不到数据库连接，导致Basic Data Service无法接收新的请求。User API因调用Basic Data Service的线程而出现了堵塞，以至于User API服务的所有线程都出现堵塞，即User API也停止工作，使得App上的所有操作都不能使用，后果比较严重。
2 覆盖场景
为了解决以上两个问题，需要引入一种技术，这种技术还要满足以下两个条件。
2.1 线程隔离
首先针对第一个问题进行举例说明。假设User API中每个服务配置的最大连接数是1000，每次API调用Basic Data Service的/currentCarLocation时速度会很慢，所以调用/currentCarLocation的线程就会很慢，一直不释放。
那么原因可能是，User API这个服务中的1000个连接线程全部都在调用/currentCarLocation这个服务。因此，希望控制/currentCarLocation的调用请求数，保证不超过50条，以此保证至少还有950条连接可用于处理常规请求。如果/currentCarLocation的调用请求数超过50条，就设计一些备用逻辑进行处理，比如在页面上给用户提示。
2.2 熔断
针对第二个问题，因为此时数据库并没有死锁，流量洪峰缓存超时只是因为压力太大，所以可以使Basic Data Service暂缓服务、不接收新的请求，这样Redis的数据会被补上，数据库的连接也会降下来，服务也就没问题了。
总结一下，这个技术应能实现以下两点需求。
1）发现近期某个接口的请求经常出现异常时，先不访问接口的服务。
2）发现某个接口的请求总是超时时，先判断接口的服务是否不堪重负，如果是，就先别访问它。
