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


    系统由Openresty + Python构建开发的,使用redis做消息队列,未避免丢失信息,在设计上实现了基于调度器的消息确认机制。 现如今,该系统单机每秒可以承载5K的刷新预缓存,所有主控及分控节点加起来可以到每秒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解释器


….

END.




对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!
暂无相关产品

评论已关闭。