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

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

之前自己做过消息模板,还蛮简单,我以为这个功能也很简单,很快可以完成,但是,并没有想象的那么顺利,上次项目经理让我推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条数据了。

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180802G1O8OO00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券