现有的缓存框架已经非常成熟而且优秀，J2Cache 无心造一个新的轮子，它要解决的几个问题如下：
使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞
使用内存缓存时，多个应用节点无法共享缓存数据
使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满。现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢
在遭遇问题1、2 时，很多人自然而然会想到使用 Redis 来缓存数据，因此就难以避免的导致了问题3的发生。
当发生问题 3 时，又有很多人想到 Redis 的集群，通过集群来降低缓存服务的压力，特别是带宽压力。
但其实，这个时候的 Redis 上的数据量并不一定大，仅仅是数据的吞吐量大而已。
两种节点间数据同步的方案 —— Redis Pub/Sub 和 JGroups 。当某个节点的缓存数据需要更新时，通过 Redis 的消息订阅机制或者是 JGroups 的组播来通知集群内其他节点。当其他节点收到缓存数据更新的通知时，它会清掉自己内存里的数据，然后重新从 Redis 中读取最新数据。
用好缓存首先要确保以下几点：
1.根据业务规划好不同的 region 来存放不同的缓存数据
2.根据实际情况确定每个 region 的缓存数据数量和 TTL 时间
3.尽量必要未经定义直接使用一个全新的 region （避免使用 default 数据）
缓存场景，开启固化功能，有什么利弊？
如果只是缓存场景，数据存放在数据库，缓存在redis，此时如果开启固化功能：
优点是，redis挂了再重启，内存里能够快速恢复热数据，不会瞬时将压力压到数据库上，没有一个cache预热的过程。
缺点是，在redis挂了的过程中，如果数据库中有数据的修改，可能导致redis重启后，数据库与redis的数据不一致。
因此，只读场景，或者允许一些不一致的业务场景，可以尝试开启redis的固化功能。
更新策略
1.先删除缓存再更新DB
结论：产生脏数据的概率较大（若出现脏数据，则意味着再不更新的情况下，查询得到的数据均为旧的数据）
比如：两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。
2.先更新DB再删除缓存（使用场景多）
结论：产生脏数据的概率较小，但是会出现一致性的问题；若更新操作的时候，同时进行查询操作，若hit，则查询得到的数据是旧的数据。但是不会影响后面的查询。（代价较小）
（ 一个是查询操作，一个是更新操作的并发，首先，没有了删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题，后续的查询操作一直都在取老的数据。）
该设计模式产生脏数据的可能情况：
一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。
该情况出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。
注意：本文归作者所有，未经作者允许，不得转载
