工作记录（一）

前言

本主题的文章目的是为了记录自己在开发过程中遇到的事故，作为前车之鉴，警醒自己。

公司是一家集研发、生产、销售一体的企业，主要业务是销售电子学生证，校徽等产品。其中校徽使用的是电信nb的对接流程，之前一位同事开发了线上容器，专门是对接电信nb协议，现容器使用日期已到期，且同事已离职，无人维护，需从新开发一套代码。

电信ctwing官网上的“MQ消息推送”这一章节介绍中，就有python的对接说明，以及相关SDK，因此本人承担起本次开发工作。

事故详情

MQ消息推送，示例代码已提供，将其修改成符合公司业务处理即可。

总的有三个步骤，也分三个模块，业务流程清晰明了：

1. 消息订阅。
2. 数据解析，下发ACK。
3. 保存数据。

在不改动SDK代码的情况下，修改父类 __init__方法不生效，因此只能使用全局Queue管道的方式，异步框架采用asyncio。消息订阅，将接收到的数据PUT进管道里；回复ACK的模块定时从管道中获取到数据，解析之后下发ACK，同时把解析出来的数据PUT到第二个管道里；存储数据的模块定时从第二个管道里获取数据，载批量保存数据。

一开始，学生还没有复课，因此校徽使用量少，上传数据量不大，一切看起来很正常。9月份学生开始回校上学了，每天上学、放学时间段，上传的数据量激增，管道中数据消费速度赶不上生成的速度，管道中数据堆积量增加，查询到的log中，最严重一次，管道中堆积了7W+未处理的数据，一方面ACK回复延时，一方面设备2分钟内收不到ACK会重传。明显的现象就是校徽定位无法更新，由此影响用户体验，以及无法使用考勤功能。

于是整个代码框架改用多进程，数据传输依然使用Queue管道，不过是multiprocess中的Queue，数据解析，下发ACK模块改用线程池（1024个worker），经过测试服务器测试该段代码，能有效解决数据堆积问题。