缓存服务器 性能指标,浅谈服务端的缓存

隔离，重要的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，是基于大文件存储的架构，特别适合海量小文件缓存。