▌15：超时时间设计
在使用远程缓存（如Redis、Memcached）时，一定要对操作超时时间进行设置，这是非常关键的，一般我们设计缓存作为加速数据库读取的手段，也会对缓存操作做降级处理，因此推荐使用更短的缓存超时时间，如果一定要给出一个数字，则希望是100毫秒以内。
笔者曾经遇到过一个案例：某个正常运行的应用突然报警线程数过高，之后很快就出现了内存溢出。
分析原因为：由于缓存连接数达到最大限制，应用无法连接缓存，并且超时时间设置得较大，导致访问缓存的服务都在等待缓存操作返回，由于缓存负载较高，处理不完所有的请求，但是这些服务都在等待缓存操作返回，服务这时在等待，并没有超时，就不能降级并继续访问数据库。这在BIO模式下线程池就会撑满，使用方的线程池也都撑满；在NIO模式下一样会使服务的负载增加，服务响应变慢，甚至使服务被压垮。
▌16：不要把缓存到存储
大家都知道一个颠扑不破的真理：在分布式架构下，一切系统都可能fail，无论是缓存、存储包括数据库还是应用服务器，而且部分缓存本身就未提供持久化机制比如memcached。即使使用持久化机制的cache，也要慎用，如果作为唯一存储的话。
▌17：缓存崩溃解决之道
当我们使用分布式缓存时，应该考虑如何应对其中一部分缓存实例宕机的情况。接下来部分将介绍分布式缓存时的常用算法。而当缓存数据是可丢失的情况时，我们可以选择一致性哈希算法。
- 取模
对于取模机制如果其中一个实例坏了，如果摘除此实例将导致大量缓存不命中，瞬间大流量可能导致后端DB/服务出现问题。对于这种情况可以采用主从机制来避免实例坏了的问题，即其中一个实例坏了可以那从/主顶上来。但是取模机制下如果增加一个节点将导致大量缓存不命中，一般是建立另一个集群，然后把数据迁移到新集群，然后把流量迁移过去。
- 一致性哈希
对于一致性哈希机制如果其中一个实例坏了，如果摘除此实例将只影响一致性哈希环上的部分缓存不命中，不会导致瞬间大量回源到后端DB/服务，但是也会产生一些影响。
▌18. 缓存崩溃后的快速恢复
如果出现之前说到的一些问题，可以考虑如下方案：
1）主从机制，做好冗余，即其中一部分不可用，将对等的部分补上去；
2）如果因为缓存导致应用可用性已经下降可以考虑：
- 部分用户降级，然后慢慢减少降级量；
- 后台通过Worker预热缓存数据。
也就是如果整个缓存集群坏了，而且没有备份，那么只能去慢慢将缓存重建；为了让部分用户还是可用的，可以根据系统承受能力，通过降级方案让一部分用户先用起来，将这些用户相关的缓存重建；另外通过后台Worker进行缓存数据的预热。
▌19. 开启Nginx Proxy Cache性能不升反降
开启Nginx Proxy Cache后，性能下降，而且过一段内存使用率到达98%；解决方案：
1）对于内存占用率高的问题是内核问题，内核使用LRU机制，本身不是问题，不过可以通过修改内核参数：
sysctl -wvm.extra_free_kbytes=6436787
sysctl -wvm.vfs_cache_pressure=10000
2）使用Proxy Cache在机械盘上性能差可以通过tmpfs缓存或nginx共享字典缓存元数据，或者使用SSD，我们目前使用内存文件系统。
▌20：“网络抖动时，返回502错误”缘于timeout
Twemproxy配置的timeout时间太长，之前设置为5s，而且没有分别针对连接、读、写设置超时。后来我们减少超时时间，内网设置在150ms以内，当超时时访问动态服务。
▌21：应对恶意刷的经验
商品详情页库存接口2014年被恶意刷，每分钟超过600w访问量，tomcat机器只能定时重启；因为是详情页展示的数据，缓存几秒钟是可以接受的，因此开启nginxproxy cache来解决该问题，开启后降到正常水平；后来我们使用Nginx+Lua架构改造服务，数据过滤、URL重写等在Nginx层完成，通过URL重写+一致性哈希负载均衡，不怕随机URL，一些服务提升了10%+的缓存命中率。
▌22：网卡打满了咋办？
用Redis都有个很头疼的问题,就是Redis的网卡打满问题,由于Redis的性能很高,在大并发请求下,很容易将网卡打满.通常情况下,1台服务器上都会跑几十个Redis实例 ，一旦网卡打满,很容易干扰到应用层可用性.所以我们基于开源的Contiv netplugin项目，限制了网卡的使用, 主要功能是提供基于Policy的网络和存储管理。Contiv比较“诱人”的一点就是，它的网络管理能力，既有L2（VLAN）、L3（BGP），又有 Overlay（VxLAN），有了它就可以无视底层的网络基础架构，向上层容器提供一致的虚拟网络了。最主要的一点是，既满足了业务场景，又兼容了以往的网络架构。在转发性能上，它能接近物理网卡的性能，特别在没有万兆网络的老机房也能很好的使用。在网络流量监控方面，我们通过使用ovs的sflow来抓取宿主机上所有的网络流量，然后自开发了一个简单的sflow Collecter, 服务器收到sflow的数据包进行解析，筛选出关键数据，然后进行汇总分析，得到所需要的监控数据。通过这个定制的网络插件,我们可以随意的控制某个Redis的流量,流量过大,也不会影响其他的项目,而如果某个服务器上的Redis流量很低,我们也可以缩小它的配额,提供给本机其他需要大流量的程序使用,这些,通过后台的监控程序,可以实现完全自动化。
▌23：缓存组件的选择
缓存的种类很多，我们实际使用时，需要根据缓存位置（系统前后端）、待存数据类型、访问方式、内存效率等情况来选择最适合的缓存组件。本小节接下来将主要探讨在应用层后端如何选择分布式缓存组件。
一般业务系统中，大部分数据都是简单KV数据类型，如前述微博Feed系统中的feed content、feed列表、用户信息等。这些简单类型数据只需要进行set、get、delete操作，不需要在缓存端做计算操作，最适合以memcached作为缓存组件。
其次对于需要部分获取、事物型变更、缓存端计算的集合类数据，拥有丰富数据结构和访问接口的Redis 也许会更适合。Redis还支持以主从（master-slave）方式进行数据备份，支持数据的持久化，可以将内存中的数据保持在磁盘，重启时再次加载使用。因磁盘缓存（diskstore）方式的性能问题，Redis数据基本只适合保存在内存中，由此带来的问题是：在某些业务场景，如果待缓存的数据量特别大，而数据的访问量不太大或者有冷热区分，也必须将所有数据全部放在内存中，缓存成本（特别是机器成本）会特别高。如果业务遇到这种场景，可以考虑用pika、ssdb等其他缓存组件。pika、ssdb都兼容Redis协议，同时采用多线程方案，支持持久化和复制，单个缓存实例可以缓存数百G的数据，其中少部分的热数据存放内存，大部分温热数据或冷数据都可以放在磁盘，从而很好的降低缓存成本。
对前面讲到的这些后端常用的缓存组件，可以参考下表进行选择。
最后，对于对存储效率、访问性能等有更高要求的业务场景，结合业务特性进行缓存组件的定制化设计与开发，也是一个很好的选择。
总之，缓存组件的选型要考虑数据模型、访问方式、缓存成本甚至开发人员的知识结构，从而进行因地制宜的取舍，不要盲目引入不熟悉、不活跃、不成熟的缓存组件，否则中途频繁调整缓存方案，会给开发进度、运维成本带来较大的挑战。
