京东活动系统亿级流量应对之术(2)

为了解决这个问题,view工程每隔指定时间,向engine发起重新渲染请求-最新内容放入redis.下一次请求到来时即可获取到新内容.由于活动很多,也不能确定哪些活动在被访问,所以不建议使用timer.通过加一个缓存key来实现,处理逻辑如下.

好处就是,只对有访问的活动定时重新发起渲染.

新架构讲解

*整理架构(不包含业务)

view工程职责：

直接从缓存或者硬盘中获取静态HTML返回,如果没有返回错误页面(文件系统的存取性能比较低,超过100ms级别,这里没有使用)；

根据缓存key2是否过期,判断是否向engine重新发起渲染(如果你的项目外面接口都支持mq,这个功能就不需要了).

engine工程职责：

渲染活动页面,把结果放到硬盘、redis.

publish工程、mq职责：

页面发生变化,向engine重新发起渲染,具体的页面逻辑,这里不做讲解.

Engine工程的工作就是当页面内容发生变化时,重新渲染页面,并将整页内容放到redis,或者推送到硬盘.

* view工程架构(redis版)

View工程的工作,就是根据链接从redis中获取页面内容返回.

* view工程架构 (硬盘版)

两个版本对比

Redis版

优点：接入简单、性能好,尤其是在大量页面情况下,没有性能抖动.单个dockertps达到700；

缺点：严重依赖京东redis服务,如果redis服务出现问题,所有页面都无法访问.

硬盘版

优点：不依赖任何其他外部服务,只要应用服务不挂、网络正常就可以对外稳定服务；在页面数量不大的情况下,性能优越.单个dockertps达到2000；

缺点：在页面数据量大的情况下(系统的所有活动页有xx个G左右),磁盘io消耗增加(这里采用的javaio,如果采用nginx+lua(OpenResty),io消耗应该会控制在10%以内).

解决方案

对所有页面访问和存储采用urlhash方式,所有页面均匀分配到各个应用服务器上；

采用nginx+lua(OpenResty)利用nginx的异步io,代替javaio.

*Openresty+硬盘版

现在通过nginx+lua(OpenResty)做应用服务,所具有的高并发处理能力、高性能、高稳定性已经越来越受青睐.通过上述讲解,view工程没有任何业务逻辑.可以很轻易的就可以用lua实现,从redis或者硬盘获取页面,实现更高效的web服务.

通过测试对比,view工程读本地硬盘的速度,比读redis还要快(同一个页面,读redis是15ms,硬盘是8ms).所以终极版架构我选择用硬盘,redis做备份,硬盘读不到时在读redis.

这里前置机的urlhash是自己实现的逻辑,engine工程采用同样的规则推送到view服务器硬盘即可,具体逻辑这里不细讲.后面有时间再单独做一次分享.

优点：

具备硬盘版的全部优点,同时去掉tomcat,直接利用nginx高并发能力,以及io处理能力；

各项性能、以及稳定性达到最优.

缺点：

硬盘坏掉,影响访问；

方法监控,以及日志打印,需使用lua脚本重写.

总结

无论是redis版、硬盘版、openresty+硬盘版,基础都是页面渲染与页面浏览异步化.

优势：

• 所有业务逻辑都剥离到engine工程,新view工程理论上永远无需上线；
• 灾备多样化(redis、硬盘、文件系统),且更加简单,外部接口或者服务出现问题后,切断engine工程渲染,不再更新redis和硬盘即可；
• 新view工程,与业务逻辑完全隔离,不依赖外部接口和服务,大促期间,即便外部接口出现新能问题,或者有外部服务挂掉,丝毫不影响view工程正常访问；
• 性能提升上百倍,从1000ms提升到10ms左右.详见前面的性能截图；
• 稳定性：只要view服务器的网络还正常,可以做到理论上用不挂机；
• 大幅度节省服务器资源,按此架构,4+20+30=54个docker足以支持10亿级PV.(4个nginxproxy_cache、20个view,30个engine)

结束语

从事开发已有近10载,一直就像寄生虫一样吸取着网络上的资源.前段时间受“张开涛”大神所托,对活动系统新架构做了一次简单整理分享给大家,希望能给大家带来一丝帮助.第一次在网上做分享,难免有些没有考虑周全的地方,以后会慢慢的多分享一些自己的心得,大家一起成长.最后再来点心灵鸡汤...

文章出处：开涛的博客(订阅号ID：kaitao-1234567)

（编辑：ASP站长网）