3. Cache失效后的拥堵问题

　　通常我们会为两种数据做Cache，一种是热数据，也就是说短时间内有很多人访问的数据；另一种是高成本的数据，也就说查询很耗时的数据。当这些数据过期的瞬间，如果大量请求同时到达，那么它们会一起请求后端重建Cache，造成拥堵问题。
一般有如下几种解决思路可供选择：

• 首先，通过定时任务主动更新Cache；
  其次，我们可以加分布式锁，保证只有一个请求访问数据库更新缓存。

4. Multiget的无底洞问题

　　出于效率的考虑，很多Memcached应用都以Multiget操作为主，随着访问量的增加，系统负载捉襟见肘，遇到此类问题，直觉通常都是增加服务器来提升系统性能，但是在实际操作中却发现问题并不简单，新加的服务器好像被扔到了无底洞里一样毫无效果。Multiget根据key请求多台服务器，但这并不是问题的症结，真正的原因在于客户端在请求多台服务器时是并行的还是串行的！问题是很多客户端，在处理Multiget多服务器请求时，使用的是串行的方式！也就是说，先请求一台服务器，然后等待响应结果，接着请求另一台，结果导致客户端操作时间累加，请求堆积，性能下降。

5. 缓存命中率下降，但是内存的利用率很高时，我们需要如何进行处理？

　　内存空间不足，导致缓存失效移除，命中率下降，既然内存利用率高，扩容MC服务器

6. 缓存命中率下降，内存的利用率也在下降时，我们需要如何进行处理？

　　跟问题2类似，也是Slab钙化问题。空间利用率高的Slab Class不会使用空间利用率低的其他的Slab Class，导致空间利用率高的Slab Class不断因为LRU踢出数据，总体而言，缓存命中率下降，内存的利用率也会下降。
Slab钙化降低内存使用率，如果发生Slab钙化，有三种解决方案：

1. 重启Memcached实例，简单粗暴，启动后重新分配Slab class，但是如果是单点可能造成大量请求访问数据库，出现雪崩现象，冲跨数据库。
2. 随机过期：过期淘汰策略也支持淘汰其他slab class的数据，twitter工程师采用随机选择一个Slab，释放该Slab的所有缓存数据，然后重新建立一个合适的Slab。
3. 通过slab_reassign、slab_authmove。

7. 通常情况下，缓存的粒度越小，命中率会越高。

　　举个实际的例子说明：当缓存单个对象的时候（例如：单个用户信息），只有当该对象对应的数据发生变化时，我们才需要更新缓存或者移除缓存。而当缓存一个集合的时候（例如：所有用户数据），其中任何一个对象对应的数据发生变化时，都需要更新或移除缓存。
　　由于序列化和反序列化需要一定的资源开销，当处于高并发高负载的情况下，对大对象数据的频繁读取有可能会使得服务器的CPU崩溃。

8. 缓存被“击穿”问题

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑另外一个问题：缓存被“击穿”的问题。

• 概念：缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
• 如何解决：业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。类似下面的代码：

   1 static Lock reenLock = new ReentrantLock();
   2  
   3     public List<String> getData04() throws InterruptedException {
   4         List<String> result = new ArrayList<String>();
   5         // 从缓存读取数据
   6         result = getDataFromCache();
   7         if (result.isEmpty()) {
   8             if (reenLock.tryLock()) {
   9                 try {
  10                     System.out.println("我拿到锁了,从DB获取数据库后写入缓存");
  11                     // 从数据库查询数据
  12                     result = getDataFromDB();
  13                     // 将查询到的数据写入缓存
  14                     setDataToCache(result);
  15                 } finally {
  16                     reenLock.unlock();// 释放锁
  17                 }
  18  
  19             } else {
  20                 result = getDataFromCache();// 先查一下缓存
  21                 if (result.isEmpty()) {
  22                     System.out.println("我没拿到锁,缓存也没数据,先小憩一下");
  23                     Thread.sleep(100);// 小憩一会儿
  24                     return getData04();// 重试
  25                 }
  26             }
  27         }
  28         return result;
  29     }

  还可以使用分级缓存；采用 L1 (一级缓存)和 L2(二级缓存) 缓存方式，L1 缓存失效时间短，L2 缓存失效时间长。 请求优先从 L1 缓存获取数据，如果 L1缓存未命中则加锁，只有 1 个线程获取到锁,这个线程再从数据库中读取数据并将数据再更新到到 L1 缓存和 L2 缓存中，而其他线程依旧从 L2 缓存获取数据并返回。这种方式，主要是通过避免缓存同时失效并结合锁机制实现。所以，当数据更 新时，只能淘汰 L1 缓存，不能同时将 L1 和 L2 中的缓存同时淘汰。L2 缓存中 可能会存在脏数据，需要业务能够容忍这种短时间的不一致。而且，这种方案 可能会造成额外的缓存空间浪费。