企业积分制团队激励，利用led实现奖扣数据显示；在线终端数900多台，每月增长量在60台左右；基于Netty+MongoDB，并使用RocketMQ解耦需求；在“延迟级别、Thread Pool”上参考RocketMQ的源码实现；
整体架构
主要实现高度解耦：1、SaaS服务做为主程序服务（终端socket连接、推送、报表）；2、环形队列、延迟级别及线程池，是给使用者定制的一套插件；3、展现层用于React+Redux+Webpack+Antd
1、SaaS服务
设计仅基于MQ实现异步消息推送和报表统计；其设计目的就是简单核心功能，方便后期插件化扩展；
2、扇形写，解决复杂场景
扇形写可以实现高效读，使用者可个性化设置消息有效时间，有助于环形队列实现；
3、环形队列
本实现利用MongoDB的document的数据有效机制，简化环形队列复杂可能性；其主要实现消息在有效时间内可重复被推送与显示；
4、统计
基于运维考虑，增加“上线、离线、发送、回执、心跳”等数据统计；
统计数据有效为7天(使用MongoDB数据有效期机制)，所有类型数据先写入到RocketMQ中，然后再把消息体和统计写入到MongoDB中；
1、上线、离线对比图：分析该终端当前所处的状态、和连接稳定性分析；
2、发送、回执对比图：分析数据发送丢包情况；
3、心跳、未知对比图：针对状态做更细微分析；
5、场景优化
5.1、对接mpm 2.3系统（已解决）：
场景说明：v2.3.0遗留问题在于，所有数据以屏号为key存储在Redis的list中，技术需要从Redis把N个屏的数据同步到环形队列中；
每1分钟推送一次数据，每次推送5条；
解决方案：
利用定时器间隔N秒，生成任务交给线程池去执行；需要考虑同步效率、MongoDB和Redis连接池等问题；
线程池运行效率、间隔时间和同步数量的均衡问题；由于每个屏均用队列，会比较吃线程，会造成线程池排队时间长的问题；
优化为：长间隔少量的同步方式；
1、同步间隔时间设置为：30s，同步数量设置为：5条；
2、增加同步线程池的并发量从6提高到30；
5.2、对接mpm 2.4系统：
场景说明：v2.4.0遗留问题在于，所有屏消息均存储在Redis的一个list中，这种结构会影响多屏数据同步不均衡，造成屏闲置的情况；
解决方案：
以最快的速度消费队列的数据；
1、提高线程池并发量从6提高到30；
1、短间隔多量的同步方式
很高兴认识你，我们都一样，有过迷茫却从未放弃；害怕孤独可从不寂寞。
