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

缓存服务化的推进,性能也是业务方考虑的一个重要因素.

• 我们对原来的 pipeline 请求中的读取类请求,进行了请求合并,通过 merge req 机制提高性能；

• 把单进程升级为多进程(这一块也在内部开发中)；

• 对于 LRU 我们升级为 LS4LRU,线上数据分析发现,相同容量及过期时间, LS4LRU 总体命中率能进一步提高 5% – 7%.

LS4LRU 简介

这里对 LS4LRU 做个简单地介绍.首先介绍 S4LRU,它是分成四个子 LRU： LRU0-LRU3. Key miss 或新写入一个 key 时,把这个 key 放在第一层 LRU0,如果后来被命中则移到 LRU1 ；如果在 LRU1 又一次被命中则移到 LRU2,依此类推,一直升级到 LU3.如果它四次以上命中,就会一直把它放在 LU3.如果发现 LU3 的数据量太多需要 evict,我们先把待 evict 的 key 降级到 LU2 上,如此类推.同时每个 kv 有过期时间,如果发现它过期就清理.

而 LS4LRU 是在 S4LRU 的基础上增加一个分级的过期时间,每个 KV 有两个过期时间 exp1 和 exp2.比如说某业务,exp1 是一秒,xep2 是三秒,LS4LRU 被命中的时候,如果发现它是在一秒内的数据,则直接反给客户端的,如果是在 1 秒到 3 秒的时候,则会首先返回到客户端,然后再从异步获取最新的数据并更新.如果是 3 秒以上的,就直接去清理,走 key miss 流程.

服务化的总结

我们再看一下服务化的其他一些方面的实践总结.

• 对于容灾,Memcache 部分节点故障,我们有多级 Cache 解决；

• 对于 proxy/Memcache 较多节点异常,我们通过重新部署新节点,并通过 captain 在线通知配置中心,进而使新节点快速生效；

• 对于配置中心的故障,可以访问端的 snapshot 机制,利用之前的 snapshot 信息来访问 Cache proxy 或后端缓存资源.

• 对于运维,我们可以通过 Graphite、 captain,实现标准化运维；对于节点故障、扩缩容按标准流程进行界面操作即可.运维在处理资源变更时,不再依赖开发修改配置和业务重启,可以直接在后端部署及服务注册.对于是否可以在故障时直接部署并进行配置变更,实现自动化运维,这个我们也还在探索中.

历年的演进经验可以看到,缓存服务化的道路还是很长,未来还需要进一步的对各 Cache 组件进行打磨和升级,我们也会在这条路上不断前行.大家对于缓存的设计有各种建议的,欢迎在文后留言进行探讨.

Q&A

提问： L1 和 main 是如何协作的,什么时候可以把数据升级到了 L1,什么时候淘汰?为什么要使用这样的机制,L1 和 main 的访问速度应该差不了很多吧?为什么要另外再加一个热点数据放在 L1 里面? L1 跟 main 怎么做数据同步?

陈波：首先 L1 的容量比 Main 小很多,同时 L1 会有很多组,线上核心也有一般在 4-6 组以上,每组 L1 的数据基本上是热数据.如果部署了 L1,所有的写请求、 L1 的读 miss 后的回写,都会把数据写入 L1,淘汰方式是 L1 组在容量满了之后由 Memcache 自动剔除.

对于为什么需要 L1,因为对于微博业务来说,它是一个冷热非常明显的业务场景,一般来讲,新发的微博请求量大,之前发的微博请求量小,另外在峰值期请求量会特别大,在高峰访问期间、节假日时,核心业务单端口的访问 QPS 会有百万级,这时单层或双层 main-ha 结构的 Memcache 缓存性能上无法满足要求,主要表现就是带宽被打满、 CPU 过高、请求耗时增加.另外在突发事件爆发时,比如最近的宝宝事件,如果对部分热 key 有数十万级以上的并发访问,再加上其他不同 key 的请求,双层缓存结构是完全无法满足性能要求的,缓存节点过载,读取性能下降,超时会???量出现.因此我们增加 L1 层,通过多个 L1 组,把这些热数据分散到不到 L1 组来访问,从而避免 Cache 层过载.这样 L1 层就分担了 Main 层对热数据的大部分访问,一些温热的数据访问才会落到 Main 和 slave 层,为了保持 main 层数据的热度,实际线上运行中,我们也会把 main 层作为一个 L1 组来分担部分热数据的访问,只是这种情况下,key miss 后会直接访问 slave.

数据同步是通过多写和穿透回写的方式进行.在更新数据的时候,直接对所有的 L1、 Main、 slave 层进行更新,从而保证各层的数据是最新的.另外,进行数据读取的时候,存在 L1-main-ha、 DB 四层的穿透回写机制,如果前面读取的缓存层 miss 了,后面缓存层、 DB 层命中了,然后就可以进行原路回写,从而对前面的缓存层都写入相同的 kv.

提问：什么样的数据放在 L1 里面?

陈波：最热的数据存在 L1 中,它通过 Memcache 层的淘汰机制进行的.因为 L1 容量比 main 小很多,最热的数据、访问频率最高的数据基本都在 L1 里面,而稍冷的数据会很快的从 L1 里面踢走.所以直观上,你可以认为最热的、当前访问量最大数据就在 L1 层.比如说可以认为姚晨、宝强的最新数据都在 L1 层,我们普通用户的数据大多靠 Main 层命中.

提问：你们线上 Redis 的内存碎片情况如何?

陈波：我们去年和前年对部分业务的 Redis 有做过分析,一般有效内存负荷在 85% 到 90% 以上,也就是碎片率小于 1.1-1.2,很多是 1.0x,有些跑了半年或者一年以上的部分实例可能会稍微高一点.

提问： Redis 碎片率过高的话你们是怎么来优化的?

陈波：如果发现碎片率比较高,比如 master,我们会切换一个新 maste,然后把老的 maste 进行下线,然后通过重启解决,也可以通过我们的热升级机制解决.

本文及本次沙龙相关 PPT 链接如下

https://pan.baidu.com/s/1geTJtZX

文章出处：高可用架构

（编辑：云计算网_泰州站长网）

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