很久很久没有更新了，更新一下

自从来到了新纪元就没有看见过晚霞是什么样的，每天都在疯狂加班，各种被甲方欺负。尤其还是有点傻逼的甲方。最近几天项目已经上线进入平稳期，也就稍微不怎么忙了，这两天一直在负责微信消息模板的推送。

之前自己做过消息模板，还蛮简单，我以为这个功能也很简单，很快可以完成，但是，并没有想象的那么顺利，上次项目经理让我推36w条消息模板给用户，结果发现太慢的，我第一次分批推5w数据花了两个小时，简直崩溃，由于是单线程的，发送固然很慢，接下来是这引入了线程池，这里使用了40个线程的线程池，测试表明，速度提升的很明显，还是可以的能达到1分钟处理1000个请求，但是随着而来了另外一个问题：在多线程环境下，http的连接经常超时，也就是说出错率极其的高，分析了一下原因，是我使用的HttpClient是默认的配置，没有一个关闭连接的过程，在多线程情况下出现了 Address already in use：connect的问题，于是，每次发完请求都将连接关闭，下一个请求到达，再建立连接，测试时发现，不知道报刚才的错误了，但是由于没有都会重新建立连接，这是十分昂贵的，类比，之前一直在用的数据库连接池和线程池，心想http也应该有连接池的概念，后来加入了http连接池，这是设置的连接数量为200个，这时候再进行测试，发现，速度已经是非常的快了，平均可以达到每分钟处理3.8k个请求。

但是这离项目经理的预期还是有点距离（他希望20w数据在30分钟内可以处理完），http连接的瓶颈解决了，接下来发现瓶颈是在数据库这里，之前的方案是每次去数据库取1000条记录，每发送一条消息更新一下其在数据库中的状态，处理完了再去取1000条记录，直到数据库中的数据全部被处理过，这里照成瓶颈的原因是频繁的读写关系型数据库，即使是加上索引依然比较慢，后来我将所有的数据放在redis中，利用redis的List的这种数据结构，做了一个简易的mq（消息队列），现将数据一条条push到redis中，然后在发送消息是直接从redis中pop出2000条再处理，处理完后，再pop2000条，现在的处理速度平均可得达到每分钟处理1.2w条数据了。

简单记录一下。发现微信公众号并不怎么适合贴代码。