# 分布式缓存设计

目前常见的缓存方案都是分层缓存，通常可以分为以下几层：

- `NG` 本地缓存，命中的话直接返回。
- `NG` 没有命中时则需要查询分布式缓存，如 `Redis` 。
- 如果分布式缓存没有命中则需要回源到 `Tomcat` 在本地堆进行查询，命中之后异步写回 `Redis` 。
- 以上都没有命中那就只有从 `DB` 或者是数据源进行查询，并写回到 Redis 中。


## 缓存更新的原子性

在写回 Redis 的时候如果是 `Tomcat` 集群，多个进程同时写那很有可能出现脏数据，这时就会出现更新原子性的问题。

可以有以下解决方案:
- 可以将多个 Tomcat 中的数据写入到 MQ 队列中，由消费者进行单线程更新缓存。
- 利用[分布式锁](https://github.com/crossoverJie/Java-Interview/blob/master/MD/Java-lock.md#%E5%9F%BA%E4%BA%8E%E6%95%B0%E6%8D%AE%E5%BA%93)，只有获取到锁进程才能写数据。

## 如何写缓存

写缓存时也要注意，通常来说分为以下几步：

- 开启事务。
- 写入 DB 。
- 提交事务。
- 写入缓存。

这里可能会存在数据库写入成功但是缓存写入失败的情况，但是也不建议将写入缓存加入到事务中。
因为写缓存的时候可能会因为网络原因耗时较长，这样会阻塞数据库事务。
如果对一致性要求不高并且数据量也不大的情况下，可以单独起一个服务来做 DB 和缓存之间的数据同步操作。

更新缓存时也建议做增量更新。

## 负载策略

缓存负载策略一般有以下两种：
- 轮询机制。
- 一致哈希算法。

轮询的优点是负载到各个服务器的请求是均匀的，但是如果进行扩容则缓存命中率会下降。

一致哈希的优点是相同的请求会负载到同一台服务器上，命中率不会随着扩容而降低，但是当大流量过来时有可能把服务器拖垮。

所以建议两种方案都采用：
首先采用一致哈希算法，当流量达到一定的阈值的时候则切换为轮询，这样既能保证缓存命中率，也能提高系统的可用性。