分布式cdn刷新预缓存系统遇到的坑

话题是,构建分布式cdn刷新预缓存遇到的坑。


    cdn刷新系统由Openresty + Python开发的,使用redis做消息队列,未避免丢失信息,在设计上规避了大概率丢失消息的可能,保证了绝大数场景的消息可靠性。 现如今,该系统单机每秒可以承载7K的刷新预缓存,所有主控及分控节点加起来可以到每秒10W的刷新量级。 

该文章写的有些乱,欢迎来喷 ! 另外文章后续不断更新中,请到原文地址查看更新. 

http://xiaorui.cc/?p=4455

    由于项目相当的着急,十万火急,要求半个月开发完毕,一周内测试上线。  这对于我来说是个很大的挑战,不管是心灵和肉体…   另外使用python构建这种高频的服务端,中间因为这样、那样的问题,出现了不少的技术坑。 讲真,在以前的工作中曾不止一次开发过这类分布式系统,有基于事件的即时通信、分布式爬虫系统,调度系统等。但可能因项目时间方面过于紧张,很多曾经遇到的坑,居然再走了一遍,实在是不应该如此呀。 很多高性能系统设计的要点,不仅仅要记录在心里,还要用文字记录下来,后期再开发该类系统,对照的撸就可以了。


下面我把该项目遇到的麻烦及解决方法列出来,供大家有些思考吧。 


细节方面我会慢慢的填充….

1.  redis频繁交互的问题

2.  cs上下文过高问题

3.  队列堵塞的问题

4.  避免队列饿死的问题

5.  数据校验问题

6.  批量io问题

7.  OOM问题

8.  连接池问题

9.  Queue cpu密集问题.

10. 内存空日志方案

11. json性能问题

12. 锁的效率

13. cpu亲和性

14. 通过火焰图查找优化逻辑

15.  使用jit功能的pypy解释器

16.  gcc原子计数

17.  引入http-parser加速解析性能


….

END.



大家觉得文章对你有些作用! 如果想赏钱,可以用微信扫描下面的二维码,感谢!
另外再次标注博客原地址  xiaorui.cc