浅谈服务端的缓存
2016-09-16 本文已影响351人
imnx
笔者工作中处理过包括视频、图片和业务元数据在内的cache处理,也遇到了一些比较常见的坑,做个笔记。希望能抛砖引玉。
cache的主要指标
- 命中率 命中率越高,回源率越少。cache的主要职责之一是减少回源,保护存储层。实际项目中,要想法设法,比如加大内存、加长过期时间去维持高命中率。如果有些业务确实回源了仍然miss而无法cache,这时也是可以考虑cache miss_key的。
- 实时性 实时性体现在cache的及时更新或淘汰上。可以参考我的另外一篇文章基于mysql binlog解析的数据更新通道。
踩过的坑
- 隔离,重要的cache资源,或者量大的要进行物理隔离。降低耦合,减少互相影响。
- 做local cache,有时候可以解决热点问题,而且走unix sock更快,尤其单次请求大量key的时候更靠谱。当然实时性看怎么保证,如果时间太短可能会影响命中率。
- db和cache很难做成事务,所以可能会存在各种各样的不一致的坑。比如当需要异步更新cache数据时,如果是del cache的方式,须优先更新数据源,再更新cache。否则先del可能会造成,此时读请求cache miss后读到脏数据而回写cache。一般如果希望保证最终一致,可以丢给mq做异步更新保证时序和可靠性,或者走mysql binlog通道更新。
- 使用redis的INCR、SADD、HSET、zadd等操作前,须先expire判断该key是否存在,否则可能会因为key过期导致错误的value。
- 类似计数相关的cache操作,尽量写绝对值而不是增量写。否则一次cache失败很容易造成永久的脏数据。比如可以新增一个技术表,与具体记录表做成事务写,然后每次缓存更新直接读计数更新。
- 对于非结构化数据,比如大于100k的value,redis的性能是下降比较厉害的,优先存memcache。再大一些的比如1M以上的,建议放其他的缓存系统,比如nginx proxy_cache、couchbase、groupcache等。
- 对于命中率低的业务场景,要分析原因。有些是大量查询不存在的数据(db里也不存在),这种可以做空缓存。有些是大量冷数据,也叫长尾数据,可以加大缓存和延长缓存周期,或者做预判和预加载。
- nginx proxy_cache 我们线上存储服务维护确实遇到一些坑,比如某次发生cpu wa%特别高,nginx的日志相对比较少,所以发个strace跟踪看看:
rename("/usr/local/nginx/proxy_temp/0/55/0943989550", "/mnt/storage00/ngx_cache/7/82/5c8b3d15f415b3e0007cd01ddc914827") = -1 EXDEV (Invalid cross-device link) open("/usr/local/nginx/proxy_temp/0/55/0943989550", O_RDONLY) = 46 fstat(46, {st_mode=S_IFREG|0600, st_size=2176, ...}) = 0 open("/mnt/storage00/ngx_cache/7/82/5c8b3d15f415b3e0007cd01ddc914827.0943989551", O_WRONLY|O_CREAT, 0600) = 55 read(46, "\3\0\0\0\0\0\0\0}\202}X\0\0\0\0>\10CW\0\0\0\0\375GtX\0\0\0\0"..., 2176) = 2176 write(55, "\3\0\0\0\0\0\0\0}\202}X\0\0\0\0>\10CW\0\0\0\0\375GtX\0\0\0\0"..., 2176) = 2176 close(55) = 0 close(46) = 0
明显的报错:Invalid cross-device link,proxy_cache在miss后回写数据到磁盘,先写到tmp文件,然后rename的,这样可以避免并发读写同个文件。而这里当rename失败后,open->read->write->close就走了好一大段弯路......终究原因是配置proxy_cache的时候忽视了proxy_temp_path,而可能就导致上面的不一致问题。还有一次也是cpu wa%特别高,当时是批量导数据,上千万张数据很多miss了。perf top看xfs的一些系统调用大量阻塞了cpu,导致机器负载陡增,程序性能也急剧下降!最后推测原因,由于读写海量小文件,可能触发了ssd的一些频繁GC等各种不熟悉、未预期的行为,也可能是踩到了xfs系统的瓶颈,导致实际上的io wa还是非常高。最终呢,我们是升级到了ATS。读者有兴趣可以了解下ats,是基于大文件存储的架构,特别适合海量小文件缓存。
一些经验
- cache节点的部署,尽量跨机器,多节点。可以避免cache节点挂掉而导致回源对db的冲击。
- cache的监控,除了日常的资源监控,还要包括tps、命中率、会不会有过热的key等。特别热门的大key要做冗余存储。