流程图：

业务场景：
客户端发起请求后，服务会通过 http 对外接口收集客户端的 “A 字段” 信息，并写进 redis 缓存和保留永久数据到 mongodb，然后提供 searchtag 接口供其他服务获取 “A 字段” 信息。
其他服务通过 collect 服务提供的 search 接口获取 “A 字段” 信息时，根据唯一标识获取信息，如果 redis 中存在数据，直接在 redis 中获取，如果 redis 中未获取到数据，则从 mongodb 获取。

发版：
线上总用户量：过亿，日活（保密）
collect 是一个经过长时间的鞭打还好好活着的服务
发版结果：collect 服务存在 oom

问题定位：

监控服务告警，提示 collect 服务 oom，查看请求耗时时发现 mongodb 插入时间耗时过长，时间最长的达到 3s，其他服务未发现明显问题，初步判断是 sql 插入逻辑存在性能问题，接着定位具体问题，sql 语句只是小数据量的插入直接排除 sql 语句问题，最终定位的结果是高并发时 mongodb 连接数过多，即使 sql 插入数据量小，但也会消耗大部分机器资源。

性能优化：
调整 sql 插入逻辑，在收集客户端信息时只写缓存，然后定时从 redis 批量获取数据，再定时批量插入数据到 mongodb，解决 mongodb 多连接数的问题，再次上线后服务稳定。

复盘：
由于逻辑简单且业务紧急，从研发侧、测试侧都觉得可以忽略性能测试，之后存在数据库操作、redis 读写的都需要做性能测试。