从优化性能到应对峰值流量：微博缓存服务化的设计与实践

在业务运行中,由于各个业务的访问量的不断变化、热点事件的应对,需要根据需要对缓存资源进行扩缩,有两种扩缩方式：集群内的扩缩 和 集群的增减.

对于集群内的扩缩,线上操作最多的是增减 L1 组或扩容 main 层.

对于 L1,通常直接进行上下线资源,并通过 captain 对配置中心的配置做变更即可生效.而 main 层扩缩有两种方式,一是通过 L1、 Main 的切换,即新的 main 层先做为 L1 上线,命中率达到要求后,再变更一次配置,去掉老的 main,使用新的 main 层 ; 另外一种方式是使用 main-elapse 策略,直接上线 main,把老的 main 改为 main-elapse,main 层 miss 后先访问 main_elapse 并回种,set 时对 main-elapse 做删除操作.

对于集群的增减,我们增加了一个新组件 updateServer,然后通过复制来实现,目前还在内部开发测试状态.为什么会有集群增减,因为微博的访问存在时间上的规律性,比如晚上 9 点到 0 点的高峰期、节假日、奥运等热点出现,流量可能会有 30-50% 以上 变化,原有集群可能撑不住这么大的量,我们可能需要新建一个前端 + 资源集群,来满足业务需要,这时可以提前 1-2 个小时在公有云部署资源服务并加热,供新集群的业务方使用,待峰值过去后,再做下线处理,在提供更好地服务的同时,也可以降低成本.

如何 updateServer 进行集群间复制?可以结合下面这张图来看.

缓存集群分为 master 集群、 slave 集群. Master 集群的 cacheProxy 收到 client 的请求后,对于读请求直接访问 L1-m-h 三层结构,但对写请求会发往本地的 updateServer ； slave 集群的 cacheProxy 除了做 master 集群的相同的动作,还会同时将写请求路由到 master 集群的 updateServer.只要 cacheProxy 更新 master、 local 集群中任何一个 updateServer 成功则返回成功,否则返回失败. updateServer 收到写请求,在路由到后端缓存资源的同时,会日志记录到 aof 文件,slave 集群的缓存即通过 updateServer 进行同步.为什么引入 updateServer 这个角色,主要是更好的应对前端本地部署,由于本地部署方式 cacheProxy 节点特别多,前端机器配置较差,更重要的原因前端 Docker 镜像随时可能会被下线清理,所以需要把写请求发送到独立部署的 updateServer 进行更新.而对于集中化部署,Cache proxy 和 updateServer 的角色也可以合二为一,变为一个进程.

（编辑：辽源站长网）

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