稍微记录下这两天弄物联网采集数据缓冲的心得

    由于之前采集服务器(服务器A)采集的数据直接发完业务逻辑服务器(服务器B)进行处理,这样A需要阻塞等待B完成后才能继续发送数据,导致A采集部分存储了大量的数据,然后一次性发给B。B处理大量数据又耗时,这样A就要等待更久的时间,屯了更多的数据……(如此恶性循环下去,导致服务器性能没发挥上,响应慢

    于是乎,就打算弄个一级缓冲。

    A发送给B,B不做处理,直接扔到缓冲池,并且通知C数据存储完毕。这两步速度十分快,A调用B的接口很快就得以返回,所以就不会存在之前的情况了。然后C收到B的通知后,便通过事件驱动机制,去调用B的处理业务接口,让B无后顾之忧地全速跑。(测试后,1核1G的linux服务器跑出了平均负载10的效果,并发量达到了1k,而且不怎么卡

    但是这样可能会导致另外一个问题,由于A发得太快,A端的端口号可能不够用,产生很多TIME_WAIT。当然,这个也是可以计算的,而且在A端做个缓冲也就解决问题了。就是用缓冲池的话,会导致带宽波形锯齿状,看着好揪心。另外计算后发现是log函数,在TIME_WAIT数量为9k~10k之间达到平行,而且波形很平滑,看着我舒服。

猜你喜欢

转载自my.oschina.net/chrisforbt/blog/1630662