浅谈服务端的缓存

笔者工作中处理过包括视频、图片和业务元数据在内的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要做冗余存储。