背景
业务说明
接到一个业务需求，往DB表中某个字段里新增一些数据，该字段本来是text类型，发现根据业务需求来说，新增数据超过text类型的最大长度，因此需要对数据库表的该字段类型做变更，变更为了MEDIUMTEXT类型来解决业务需求；
数据流转
DB表的数据会通过数据处理转化到mongo中存储，然后mongo再加载到redis中，打点服务会从redis读取该数据，进行json encode，然后做业务处理；
问题过程
- 开发反馈打点服务sg、fk集群机器出现响应时间突增以及请求出现大量5xx，运维增加集群机器数量后发现响应时间以及5xx数量并未减少，观察到新开的机器以及旧机器的打点服务进程的go携程数以及占用的内存非常高，开发开始排查具体原因
- 运维开始将fk地区请求转到vg地区集群，fk地区的请求响应时间以及5xx下降，服务恢复正常，vg地区表现正常（因为vg的机器多，即使解析慢了还是够应付）
- 开发反馈上午某业务需求服务上线新功能会导致mongo中的campaign中的问题字段数据量变大，可能是此变动影响到打点服务，进行回滚相应变动后，观察到sg地区请求5xx的数量逐渐下降，运维开始新开机器并重启旧机器，服务逐渐开始恢复
- sg地区服务恢复正常，fk地区请求也迁回fk集群机器，打点所有地区服务恢复正常
问题原因
- 运营反馈ss素材报表ctr出现100%的问题，排查到是上线素材区分国家后导致
- 开发操作上线修复此问题，同时会导致mongo中的campaign中的某问题字段数据量变大，由于打点通过zeus redis获取campaign数据，并且会进行json反序列化操作，部分单子的该问题字段数据量增大到2M以上，导致打点反序列化效率下降，造成请求堆积，最终导致进程中的携程增加，占用内存资源不断增加，导致服务不可用
问题总结/改进
- 信息同步，核心系统出现问题首先在群里反馈该问题，看之前是否有其他项目上线（包括DB/配置变更）导致该问题；
- 业务流程梳理，对全流程进行梳理，知悉数据去向和使用，方便问题的定位分析，快速发现问题；
- 系统架构优化，打点服务解耦，反序列化效率提升, mongo中campaign信息的拆分，了解到目前有部分信息是独立表的，打点服务在启动的时候会去load数据到内存中；
- 个人觉得架构问题是大于流程方面的，但复盘会下来流程问题大于架构，不可否认流程问题得到解决可以避免类问题，但随着业务持续增长/迭代这些问题始终是要暴露出来的；
其他
- 咨询了之前UC的同事那边的打点服务，打点服务可以拆分为接受+处理两个模块，接受模块来解析接受请求，然后存储在中间件中（类似kafka，metaQ消息队列），然后处理模块消费处理，这样可以解耦，如果处理失败的话，可以从中间件中重复消费减少损失
- 公司的算法强依赖日志，因为日志的确实会导致算法模型训练不准；
- 由于公司之前的节约成本的考虑，目前的mongo数据是刚刚够用状态，如果不从成本考虑，mongo机器够多，打点服务就可以马上加机器应对这次事故；临时加mongo机器很慢，因为加了机器还是同步数据，一般加mongo机器大概是1个小时左右，因此出现事故的时候一般不会加mongo机器时间花费太久了；但如果mongo机器只是够用的状态，只加打点服务的机器的话，mongo数据库会顶不住，太多服务连接使用，所以在加打点服务机器的时候出现了服务起不来，因为把mongo弄挂了；
- 打点服务的使用方是SDK，SDK发现打点服务返回不是200的时候有重试机制，所以导致打点服务请求暴增，因此引起雪崩了；
