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

为了解决这个问题,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+硬盘版

（编辑：焦作站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!