缓存

利用Caffeine做一级缓存，Redis作为二级缓存。

1. 首先去Caffeine中查询数据，如果有直接返回。如果没有则进行第2步。
2. 再去Redis中查询，如果查询到了返回数据并在Caffeine中填充此数据。如果没有查到则进行第3步。
3. 最后去Mysql中查询，如果查询到了返回数据并在Redis，Caffeine中依次填充此数据。

对于Caffeine的缓存，如果有数据更新，只能删除更新数据的那台机器上的缓存，其他机器只能通过超时来过期缓存，超时设定可以有两种策略:

• 设置成写入后多少时间后过期
• 设置成写入后多少时间刷新

对于Redis的缓存更新，其他机器立马可见，但是也必须要设置超时时间，其时间比Caffeine的过期长。

为了解决进程内缓存的问题，设计进一步优化

4.缓存更新

一般来说缓存的更新有两种情况:

• 先删除缓存，再更新数据库。
• 先更新数据库，再删除缓存。 这两种情况在业界，大家对其都有自己的看法。具体怎么使用还得看各自的取舍。当然肯定会有人问为什么要删除缓存呢？而不是更新缓存呢？你可以想想当有多个并发的请求更新数据，你并不能保证更新数据库的顺序和更新缓存的顺序一致，那就会出现数据库中和缓存中数据不一致的情况。所以一般来说考虑删除缓存。

4.1先删除缓存，再更新数据库

对于一个更新操作简单来说，就是先去各级缓存进行删除，然后更新数据库。这个操作有一个比较大的问题，在对缓存删除完之后，有一个读请求，这个时候由于缓存被删除所以直接会读库，读操作的数据是老的并且会被加载进入缓存当中，后续读请求全部访问的老数据。

 

对缓存的操作不论成功失败都不能阻塞我们对数据库的操作，那么很多时候删除缓存可以用异步的操作，但是先删除缓存不能很好的适用于这个场景。

先删除缓存也有一个好处是，如果对数据库操作失败了，那么由于先删除的缓存，最多只是造成Cache Miss。

4.2先更新数据库，再删除缓存(推荐)

如果我们使用更新数据库，再删除缓存就能避免上面的问题。但是同样的引入了新的问题,试想一下有一个数据此时是没有缓存的，所以查询请求会直接落库，更新操作在查询请求之后，但是更新操作删除数据库操作在查询完之后回填缓存之前，就会导致我们缓存中和数据库出现缓存不一致。

为什么我们这种情况有问题，很多公司包括Facebook还会选择呢？因为要触发这个条件比较苛刻。

1. 首先需要数据不在缓存中。
2. 其次查询操作需要在更新操作先到达数据库。
3. 最后查询操作的回填比更新操作的删除后触发，这个条件基本很难出现，因为更新操作的本来在查询操作之后，一般来说更新操作比查询操作稍慢。但是更新操作的删除却在查询操作之后，所以这个情况比较少出现。

对比上面4.1的问题来说这种问题的概率很低，况且我们有超时机制保底所以基本能满足我们的需求。如果真的需要追求完美，可以使用二阶段提交，但是其成本和收益一般来说不成正比。

当然还有个问题是如果我们删除失败了，缓存的数据就会和数据库的数据不一致，那么我们就只能靠过期超时来进行兜底。对此我们可以进行优化，如果删除失败的话 我们不能影响主流程那么我们可以将其放入队列后续进行异步删除。

5.缓存挖坑三剑客

大家一听到缓存有哪些注意事项，肯定首先想到的是缓存穿透，缓存击穿，缓存雪崩这三个挖坑的小能手，这里简单介绍一下他们具体是什么以及应对的方法。

5.1缓存穿透

缓存穿透是指查询的数据在数据库是没有的，那么在缓存中自然也没有，所以，在缓存中查不到就会去数据库取查询，这样的请求一多，那么我们的数据库的压力自然会增大。

为了避免这个问题，可以采取下面两个手段:

1. 约定:对于返回为NULL的依然缓存，对于抛出异常的返回不进行缓存,注意不要把抛异常的也给缓存了。采用这种手段的会增加我们缓存的维护成本，需要在插入缓存的时候删除这个空缓存，当然我们可以通过设置较短的超时时间来解决这个问题。

 一些不可能存在的数据，小数据用BitMap，大数据可以用布隆过滤器，比如你的订单ID 明显是在一个范围1-1000，如果不是1-1000之内的数据那其实可以直接给过滤掉。

7.序列化

序列化是很多人都不注意的一个问题，很多人忽略了序列化的问题，上线之后马上报出一下奇怪的错误异常，造成了不必要的损失，最后一排查都是序列化的问题。列举几个序列化常见的问题:

1. key-value对象过于复杂导致序列化不支持:笔者之前出过一个问题，在美团的Tair内部默认是使用protostuff进行序列化，而美团使用的通讯框架是thfift，thrift的TO是自动生成的，这个TO里面很多复杂的数据结构，但是将其存放到了Tair中。查询的时候反序列化也没有报错，单测也通过，但是到qa测试的时候发现这一块功能有问题，发现有个字段是boolean类型默认是false，把它改成true之后，序列化到tair中再反序列化还是false。定位到是protostuff对于复杂结构的对象(比如数组，List<Map>等等)支持不是很好，会造成一定的问题。后来对这个TO进行了转换，用普通的Java对象就能进行正确的序列化反序列化。
2. 添加了字段或者删除了字段，导致上线之后老的缓存获取的时候反序列化报错，或者出现一些数据移位。
3. 不同的JVM的序列化不同，如果你的缓存有不同的服务都在共同使用(不提倡)，那么需要注意不同JVM可能会对Class内部的Field排序不同，而影响序列化。比如下面的代码，在Jdk7和Jdk8中对象A的排列顺序不同，最终会导致反序列化结果出现问题:

参考：https://my.oschina.net/u/4072299/blog/3019442

https://blog.csdn.net/zhuyu19911016520/article/details/81946202