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

    由于之前采集服务器（服务器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之间达到平行，而且波形很平滑，看着我舒服。

转载于:https://my.oschina.net/chrisforbt/blog/1630662