刚来时搞不清楚POC什么意思，查了下在这也普及下：Proof Of Conception，概念证明。

背景：

属于中途介入、二次分包项目，之前的分包商做出的东西性能上稍微有些弱，架构上有些不合理。

设计：

数据推送流程：总部->大区->城市，考虑到总部压力大，将压力分摊到大区来做，总部只做数据入库。与甲方探讨此设计时，直接被毙掉，理由是出于安全考虑，大区不能直接访问总部DB。无奈，只能将压力再次压到总部系统。[甲方对此项目的理解并不完全清晰，有些需求也很不确定]数据过滤，数据分发，结果反馈，数据入库全部压到总部系统，大区只成了一个向城市分发数据的过道，不做任务处理将数据分下去，谈不上任何压力，也谈不上存在的必要性。只是简单的降低了一些数据分发时积压量。同时，还需要一套监控程序，来监控数据包在各个阶段流转的情况以及各个SERVER的状态。

实现：

消息系统：IBM Websphere MQ，Apache ActiveMQ，监控：Apache MINA，代码框架：Spring+MyBatis，数据库：MYSQL

测试指标：

100W数据入库+消息分发+结果反馈+关键数据入库，2-3分钟【数据到大区不下发，直接返回总部】。

关键点：

1、消息组包后分发，单纯从分角度讲，组包分发与单条分发效率上区别不大，但后期包的反馈结果要入库，此时若是单条返回，效率可想而知，即便是多消费者、多线程操作，效率上不及按包回馈。

2、数据批量操作，100W单条入库，相当耗时，分包后可一次入库，比如可分成200/包，只需处理5000次即可完成100W；同时消息反馈时，也可以一次入库。

3、接收IMQ消息时，可以单消费者接收数据，前提是采用多线程，数量不会有太多积压在通道中。

4、采用多线程处理数据，效率上能提升不少，但会出现数据安全性方面问题，所以代码实现时，多考虑些线程安全的对象来使用,一些非线程安全的对象谨慎使用。eg：SimpleDateFormat使用时需要每次都new一个对象，而不是写一个常量只同使用，；对象存储时只能Hashtable，而不能使用HashMap。

5、接口要畅通，避免接口使用前要加工成规则数据才能使用，造成不必要的时间浪费。

6、架构设计上可以更近一步，将总部与大区合并，形成虚拟大区，配合总部完成数据下发。

7、充分利用MyBatis的动态SQL功能，批量操作数据库。

手机扫一扫，欢迎关注公众号

关注程序员成长