MongoDB 的坑

listCollections

• 问题：代码中存在 listCollections 操作，大量数据上报时，造成MongoDB CPU高升，使处理性能受到影响。经过检查，发现通信报文日表是自动创建的，每次都会判断集合是否存在；而mongo驱动包里判断集合是否存在的操作，就是先执行 listCollections；
• 优化：提前创建好需要的集合，不要在数据上报的时候进行判断、创建；ps：其实其他数据库，比如mysql、tdengine等，都是同样的道理；

连接数过大

• 问题：MongoDB 连接数配置较大，导致很多handler服务，过多的线程会导致上下文切换开销变大，同时内存开销也会上涨；
• 优化：调低连接数配置，进行压力测试；

规则引擎的坑

• 问题：为了提升性能，往往采用队列+规则引擎来处理业务，设备协议解析+计费业务是在一个handler里，而规则引擎则在下一个队列处理；规则引擎负责为欠费的表具创建短信提醒、关阀指令（产品欠费规则配置），往往在第一个队列里需等待N秒，将规则引擎创建的指令一起下方给表具，每天几百万表具实时上报数据+实时计费，数据并发量较大，如果都等待N秒，会严重影响处理性能；
• 优化：对计费后余额大于等于0的的表具，不等待N秒，直接回复结束指令，绝大部分表具其实已经是关阀状态，无需本次下发关阀指令，哪怕有需要关阀的，延后到下次通信再执行也没影响；对于小于0的表具，则使用原有逻辑；优化后，降低了90%的等待时间，大大提升高峰高并发处理性能；

HTTP订阅的坑

• 问题：前期主要通过AEP平台的http订阅实现NB表的通信，但是http服务在高并发时有时候会挂掉（具体表象就是两个http服务，只有一个存活，另一个服务存在，但不处理数据）；
• 优化：将http服务单独服务部署，不要和其他handler、服务抢占服务器资源，jvm也就不会崩了；后期采用MQ订阅方式；

站内信的坑

• 问题：原有产品设计当设备产生告警时（原生告警、规则告警等）有站内信提醒，经过项目实际运行，站内信数据非常庞大，时刻都有设备告警，导致web页面卡顿、后台web服务资源占用高；
• 优化：去掉设备站内信告警功能，一是站内信管理人员完全看不过来，二是设备告警在功能菜单里可以查询到；