（1）缓存失效一致性问题
一般缓存的使用方式是：先读取缓存，若不存在则从DB中读取，并将结果写入到缓存中；下次数据读取时便可以直接从缓存中获取数据。
数据的修改是直接失效缓存数据，再修改DB内容，避免DB修改成功，但由于网络或者其他问题导致缓存数据没有清理，造成了脏数据。但这样仍然无法避免脏数据的产生，一种并发的场景下：假设业务对数据Key:Hello Value:World有大量的读取和修改请求。线程A向OCS读取Key:Hello，得到Not Found结果，开始向DB请求数据，得到数据Key:Hello Value:World；接下来准备向OCS写入此条数据，但在写入OCS前（网络，CPU都等可能导致A线程处理速度降低）另一B线程请求修改数据Key:Hello Value:OCS，首先执行失效缓存动作（因为B线程并不知道是否有此条数据，因此直接执行失效操作），OCS成功处理了失效请求。转回到A线程继续执行写入OCS，将Key:Hello Value:World写入到缓存中，A线程任务结束；B线程也成功修改了DB数据内容为Key:Hello Value:OCS。为了解决这个问题，OCS扩充了Memcached协议（公有云即将支持），增加了deleteAndIncVersion接口。此接口并不会真的删除数据，而是给数据打了标签，表明已失效状态，并且增加数据版本号；如果数据不存在则写入NULL，同时也生成随机数据版本号。OCS写入支持原子对比版本号：假设传入的版本号与OCS保存的数据版本号一致或者原数据不存在，则准许写入，否则拒绝修改。
回到刚才的场景上：线程A向OCS读取Key:Hello，得到Not Found结果，开始向DB请求数据，得到数据Key:Hello Value:World；接下来准备向OCS写入此条数据，版本号信息默认为1；在A写入OCS前另一个B线程发起了动作修改数据Key:Hello Value:OCS，首先执行删除缓存动作，OCS顺利处理了deleteAndIncVersion请求，生成了随机版本号12345（约定大于1000）。转回到A线程继续执行写入OCS，请求将Key:Hello Value:World写入，此时缓存系统发现传入的版本号信息不匹配（1 ！＝ 12345），写入失败，A线程任务结束；B线程也成功修改了DB数据内容为Key:Hello Value:OCS。
此时OCS中的数据为Key:Hello Value:NULL Version:12345；DB中的数据为Key:Hello Value:OCS，后续读任务时会再次尝试将DB中的数据写入到OCS中。
（2）缓存数据的写同步的与DB一致性问题
随着网站规模增长和可靠性的提升，会面临多IDC的部署，每个IDC都有一套独立的DB和缓存系统，这时缓存一致性又成了突出的问题。
首先缓存系统为了保证高效率，会杜绝磁盘IO，哪怕是写BINLOG；当然缓存系统为了性能可以只同步删除，不同步写入，那么缓存的同步一般会优先于DB同步到达（毕竟缓存系统的效率要高得多），那么就会出现缓存中无数据，DB中是旧数据的场景。此时，有业务请求数据，读取缓存Not Found，从DB读取并加载到缓存中的仍然是旧数据，DB数据同步到达时也只更新了DB，缓存脏数据无法被清除。
从上面的情况可以看出，不一致的根本原因是异构系统之间无法协同同步，不能保证DB数据先同步，缓存数据后同步。所以就要考虑缓存系统如何等待DB同步，或者能否做到两者共用一套同步机制？缓存同步也依赖DB BINLOG是一个可行的方案。
IDC1中的DB，通过BINLOG同步给IDC2中的DB，此事IDC2-DB数据修改也会产生自身的BINLOG，缓存的数据同步就可以通过IDC2-DB BINLOG进行。缓存同步模块分析BINLOG后，失效相应的缓存Key，同步从并行改为串行，保证了先后顺序。
（3）缓存穿透（DB承受了没有必要的查询流量）
方法一：是布隆过滤器。它是一种空间效率极高的概率型算法和数据结构，用于判断一个元素是否在集合中(类似Hashset)。它的核心是一个很长的二进制向量和一系列的hash函数。使用谷歌的guava实现布隆过滤器。1）存在误算率，随着存入的元素数量增加，误算率也随着增加2)一般情况下不能从布隆过滤器删除元素3)数组长度以及hash函数个数确定过程复杂，布隆过滤器的使用场景？1)垃圾邮件地址过滤(地址数量很庞大)2)爬虫URL地址去重3)解决缓存击穿问题
方法二：存储空结果，并设置空结果的时间
（4）缓存雪崩（缓存设置同一过期时间，引起的DB洪峰）
方法一：大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上
方法二：失效时间随机值
（5）缓存击穿（热点Key，大量并发读请求引起的小雪崩）
缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮
方法一：1.使用分布是缓存支持的互斥锁(mutex key)，去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存，也就是load DB 只会一个线程处理。
方法二：提前"使用互斥锁(mutex key)：在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。增加了业务代码的侵入过多，以及增加了编码复杂性
方法三： "永远不过期"： 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期
（6）缓存系统常见的缓存满了和数据丢失问题
需要根据具体业务分析，通常我们采用LRU策略处理溢出，Redis的RDB和AOF持久化策略来保证一定情况下的数据安全。
本文参考：
