​本文是鱼皮在腾讯实习期间，从零开始一周紧急上线百万高并发系统的相关经验、思路及感悟，分享给大家。

花 5 分钟阅读本文，你将收获：

从年前开始和导师二人接手了一个紧急项目，年前加班做完一期后项目效果显著，于是年后开工立刻加急开发二期，目标是一周上线。由于项目业务逻辑复杂、工期紧、人手缺、对接方多，难度很大，极具挑战性，因此和导师二人开始了 007 的爆肝工作。

远程办公无疑为 007 无休工作制提供了有利条件，那段时间，我做梦都在敲代码。

首先要介绍下负责的项目及系统。项目背景、业务等信息自然不能透露，这里剥离业务，仅介绍关键系统模型，如下图：

如图，我负责的是一个状态流转系统和查询系统，以及它们依赖的数据库服务。

状态流转系统的作用是按照逻辑修改数据库中某条数据的状态字段，并在修改成功后依据状态向其他业务侧发送通知。

查询系统，顾名思义就是从数据库中查询数据，包括最基础的鉴权、查询等功能。

先分析一下系统中一些难点：

分析出了难点，在写代码之前，要先编写可行的技术方案。

在实际工作中，编写详细的技术方案是非常有必要的。优秀的工程师会在技术方案中考虑到各种场景、评估各种风险、工作量估时、记录各种问题等，不仅帮助自己梳理思路、归纳总结，同时也给其他人提供了参照以及说服力（比如你预期7天上线，没有方案谁信你？）。

根据二八定理，复杂的系统中，编写技术方案、梳理设计思路的时间和实际敲代码开发的时间比例为 8 : 2。

设计遵循的原则是 “贴合业务”，没有最好的架构，只有最适合业务的架构。切忌过度设计！

此外，还要考虑项目的紧急程度和人力成本，先保证可用，再追求极致。

一些简单的设计这里就略过了，下面针对系统难点和业务需求，列举几个重点设计及技术选型：

提到高并发，大家首先想到的是缓存和负载均衡，缺一不可。

负载均衡说白了就是 “砸钱，加机器！”，但是为公司省机器、节约成本是每位后端工程师的信仰，这就要靠技术选型和架构设计来实现了。目标是尽可能利用每台机器的资源，抗住最大的并发请求。

选型如下：

其中，缓存是抗住高并发流量的关键，须重点设计。

缓存方案

用过缓存的同学都了解，关于缓存 Key 的设计是很重要的。根据业务来，保证缓存 key 之间不冲突、便于查找就好。此处我选择请求参数 + 接口唯一 id 来拼接 key。并且分页查询接口可复用全量查询接口的缓存。

找不到对应 key / redis 连接失败时直接查库。

当数据库发生修改时，需要对缓存进行删除。由于存在非必填的请求参数，因此缓存 key 可能是一个模糊值。比如有 a、b 两个请求参数，key 可能为 “a”，也可能为 “ab”。

针对请求字段固定（所有字段必填）的接口，更新缓存时，直接拼接出唯一的 key 进行删除即可。

而针对请求字段不固定（存在非必填字段）的接口，可使用 redis 的 scan 命令范围扫描（不要用 keys 命令！）或者通过循环拼接出所有可能的 key。比如使用 scan 命令清除所有 key 前缀为 user1 的缓存。

无论查询出的列表是否为空，都写入缓存。但在业务会返回多种错误码时，不建议采用这种方式，复杂度高，成本太大。

兼容性主要考察接口的设计，为兼容多个业务侧，需要将请求参数以及响应参数设置的尽可能灵活。在设计接口时，切忌一定要和所有的业务侧对齐，否则一个字段设计不当可能导致满盘皆输！

这里有三个技巧：

上面介绍难点时提到：状态流转系统与查询系统、其他业务侧存在互相发送通知的交互。当状态流转时，需要通知其他业务，还要查询系统立即更新缓存。对消息的实时性要求很高。

这里最初有两种方案：

最后还是采取了第二种方案，并选用腾讯自研的 TubeMQ（万亿级分布式消息中间件，已开源Apache孵化），原因如下：

在技术选型和确定方案时，不仅要关注当前的业务需求，也要有一定的前沿视角。

切记，在选用中间件 / 框架前，要尽可能多的进行了解，评估其可能带来的风险。一般公司内都有自己的知识库，可以利用好内部资源或者找谷歌度娘。

这里我评估了 TubeMQ 带来的风险，从消息可靠性、消息顺序性、消息重复、监控告警等多个角度进行了分析，还是发现了一些可能的风险。比如当消费方消费数据状态改变的消息失败时，缓存未被及时更新，导致数据库和缓存中的数据不一致。

那么，如何规避风险呢？我从消息队列生产方和消费方的角度设计了消息可靠性和数据一致性的解决方案。

解决方案

生产方消息可靠性：

消费方消息可靠性和数据一致性：

其实开发过程没什么好说的，就是按照技术方案去敲代码。

这里也有几个小窍门：

很多问题在本地开发时是察觉不到的，在测试及线上环境才会被发现。问题解决的过程就像坐过山车，经常的状态是：测试 => 开发 => 测试 => 上线 => 开发 => 测试，循环往复。

两个温馨小贴士：

下面分享一些让鱼皮印象深刻的问题。

1. 事务提交时报错？

原因：事务中调用的函数里也有事务，因此事务里套了事务，破坏了隔离性。

解决：修改代码，保证事务隔离性。

2. 依赖包存在，项目启动却报错？

原因：存在多版本 jar 包，导致 Java 代码使用反射机制动态生成类时不知道使用哪个 jar 包里的类。

解决：删掉多余版本 jar 包。

3. 缓存未即时更新

原因：经排查，是由于实际的缓存 key 数量可达千万级，导致更新缓存时使用 scan 命令扫描的效率过低，长达20多秒！

解决：修改更新缓存的方案，不再使用 scan 命令，而是在业务代码中拼凑出所有可能的 keys，依次删除。

以为这个问题这样就结束了？不要忘记上面的小贴士：

“解决问题后，千万别激动，可以先深呼吸几口气，因为你还会产生新的问题，而且往往新问题更严重！”

4. 缓存仍未即时更新？

原因：某业务侧要求数据强一致性，缓存和数据库中的状态必须完全一致！而缓存虽然是毫秒级更新，但无法做到实时一致。

解决：为该业务侧定制一个接口，该接口不查询缓存，直接查数据库，保证查到的数据一定是最新值。

5. 请求卡死

服务运行一段时间后，发现所有的请求都被阻塞了！心脏受不了。

原因：使用 jstack 打印线程信息后分析 thread_dump 文件，发现是由于缓存类库 Jedis 未手动释放连接导致连接数耗尽，导致新的请求线程会不断等待 Jedis 连接释放，从而卡死。

解决：补充释放 Jedis 连接的代码即可。

6. 线上环境分析日志时突然告警，磁盘 IO 占用超过 99%！

原因：误用 cat 命令查看未分割的原始日志文件，由于日志文件太大（几十 GB），导致磁盘 IO 直接刷爆！

解决：使用 less、tail、head等命令代替 cat，并删除已备份的大日志文件。

7. 进程闪退

排查：通常 JVM 进程闪退是有错误日志的，但是并没有找到，排查陷入绝境。没办法，只能祈祷问题不再复现。后来问题真的没出现过了，谢谢！

原因：后来，经询问，是有人手动 kill 掉了这个进程。好的，***。

8. 线上环境的消息通知发送成功了，怎么没有预期的数据更新效果？

定位思路：先看消息是否被消费，再看对消息的处理是否正确。

排查：查看线上日志，发现消息并未被消费；但是查看监控界面，发现消息被测试环境的机器消费了！

原因：由于测试环境和线上环境属于同一个消费组，当消息到达时，同一个消费组只有一个消费者能够成功消费该消息，被测试环境消费掉了，导致线上环境数据没更新。

发现这个问题的时候，已经是上线前一天的深夜。再申请一个消费组已经来不及了，情急之下，只能先下掉测试环境的服务。第二天申请好消费组后，根据环境去区分使用哪个消费组就可以了，这样每个消费组都会独立消费消息，成功避免了消息竞争。

9. 报告！流量太大，撑不住啊！

原因：机器不够，需进行紧急扩容。

解决：紧急新申请了 10 台机器，完成初始化配置，成功部署新机器后，成功增大了并发度。

小技巧：多个机器做相同操作时，有两种快捷的做法。

10. 上线前一天你跟我说接口设计有问题？

原因：沟通出现严重问题！

工作中，一些同事因为自身业务繁忙，可能在核对接口设计方案的时候没有注意。等他们忙完了，会反复 @ 你、私聊你询问。我们一定不要这样！

解决：紧急电话会议，拉群核对方案

11. 线上出 bug 了！

线上出 bug，是一件很大的事，必须紧急响应。在梦里也得给我爬起来！

原因：测试环境和线上环境未必完全一致，且测试环境未必能测出所有问题。因此验证时通常需要预发布环境，数据使用线上数据，但却是独立的服务器，保证不影响线上。

解决：紧急排查定位问题，三分钟成功修复！

修复 bug 有一定的技巧，分享下个人的排错路径：

截图 / 问题 => 请求 => bug 是否可复现，和测试紧密配合 => 数据 => 数据源（真实数据与接口数据是否一致） => 数据处理

解释一下：

通常发现问题的是运维、用户或者测试，他们会抛出一个问题或者问题的相关的截图，这时，我们要快速想到这个问题对应的功能（即对应的请求/接口），然后让问题描述者尽可能多的提供信息（比如请求参数、问题时间等）。

如果问题时间较久，看日志及监控不易排查，可以询问是否可以造一个复现该问题的case，这样只需观察最新的日志即可，方便排错。

定位到请求后，我们要分析请求及响应的哪些数据是异常的，即定位关键数据，然后定位数据来源（是从数据库查的，还是从缓存查的），并观察响应数据与真实数据源是否一致。如果不一致，可能是业务逻辑中对数据的处理出现了问题，再进一步去做分析。

高效沟通建议：描述问题，尽量用数据说话，给出截图的同时，要提供完整的数据、请求等信息，有助他人分析。

12. 线上出现部分错误数据

这是一个可以预见的问题。还好已经在项目中配置了邮件告警，能够报告错误数据的信息，错误数据量也不大。

解决：修复导致错误数据的 bug 后，编写程序循环所有错误信息并生成请求代码，然后手动执行请求代码，刷新线上不同步数据即可。

建议：设计时还是要尽可能考虑到风险，可以按照问题的严重程度做分级报警策略（短信 > 邮件 > 通讯软件）。

13. 线上机器 OOM！

上线三天后发现的问题，部分线上机器竟然出现了OOM（堆内存溢出）的情况，导致服务不可用。经排查，是使用的第三方中间件的当前版本存在 bug， 所以说在使用组件前要充分调研和风险评估，选择正确的版本。

上线后如果发现问题，会经历如下流程，我称它为 hapy 流程。

比如当发现 DB 服务的 bug 后，你只需要改 DB 服务的一行代码。然而还要做：

1. 修改DB服务的一行代码

2. 跑单元测试

3. DB服务打成依赖包

4. 修改“状态流转系统”、“查询系统”对DB服务的依赖包（改动版本号/更新本地缓存拉取最新包）

5. 重新发布“状态流转系统”、“查询系统”至测试环境

6. 可能还要重新交给测试的同学进行回归测试

7. 测试通过，再次提交“状态流转系统”、“查询系统”的代码，发起 CR（代码审查）

8. 找同事或 Leader 读代码，通过 CR

9. 合并分支

10. 发布 “状态流转系统”、“查询系统” 至线上环境，每发一台机器，都要进行一次验证（滚动部署）。

11. 再次发现新的bug

这是一件恶心到爆炸的事情，但是在第 2、6、8 步骤时，是存在空余等待时间的。这时我们可以做做其他工作，记录一下工作内容、问题等。

首先总结一下这个项目各阶段的耗时：

其中，修复 bug 贯穿后面的几个流程，大概占了总时间的60%。

项目过程存在的问题：

自我感觉良好的地方：

成长与收获：