Spring Boot实践四 --集中式缓存Redis

随着时间的积累，应用的使用用户不断增加，数据规模也越来越大，往往数据库查询操作会成为影响用户使用体验的瓶颈，此时使用缓存往往是解决这一问题非常好的手段之一。Spring 3开始提供了强大的基于注解的缓存支持，可以通过注解配置方式低侵入的给原有Spring应用增加缓存功能，提高数据访问性能。

一、进程内缓存的使用与Cache注解详解

下面使用Spring Data JPA访问MySQL一文的案例为基础。这个案例中包含了使用Spring Data JPA访问User数据的操作，我们为其添加缓存，来减少对数据库的IO，以达到访问加速的作用。
参考：https://blog.didispace.com/spring-boot-learning-21-5-1/

在Spring Boot中通过@EnableCaching注解自动化配置合适的缓存管理器（CacheManager），Spring Boot根据下面的顺序去侦测缓存提供者：

Generic
JCache (JSR-107) (EhCache 3, Hazelcast, Infinispan, and others)
EhCache 2.x
Hazelcast
Infinispan
Couchbase
Redis
Caffeine
Simple

除了按顺序侦测外，我们也可以通过配置属性spring.cache.type来强制指定。我们也可以通过debug调试查看cacheManager对象的实例来判断当前使用了什么缓存。

当我们不指定具体其他第三方实现的时候，Spring Boot的Cache模块会使用ConcurrentHashMap来存储。而实际生产使用的时候，因为我们可能需要更多其他特性，往往就会采用其他缓存框架，所以接下来我们会分几篇分别介绍几个常用优秀缓存的整合与使用。

二、使用EhCache及缓存集群

参考：
https://blog.didispace.com/spring-boot-learning-21-5-2/
https://blog.didispace.com/spring-boot-learning-21-5-3/

三、使用集中式缓存Redis

虽然EhCache已经能够适用很多应用场景，但是由于EhCache是进程内的缓存框架，在集群模式下时，各应用服务器之间的缓存都是独立的，因此在不同服务器的进程间会存在缓存不一致的情况。即使EhCache提供了集群环境下的缓存同步策略，但是同步依然是需要一定的时间，短暂的缓存不一致依然存在。

在一些要求高一致性（任何数据变化都能及时的被查询到）的系统和应用中，就不能再使用EhCache来解决了，这个时候使用集中式缓存就可以很好的解决缓存数据的一致性问题。接下来我们就来学习一下，如何在Spring Boot的缓存支持中使用Redis实现数据缓存。

参考：
https://blog.didispace.com/spring-boot-learning-21-5-4/

使用Redis的发布订阅功能

发布订阅模式中有个重要的角色，一个是发布者Publisher，另一个订阅者Subscriber。本质上来说，发布订阅模式就是一种生产者消费者模式，Publisher负责生产消息，而Subscriber则负责消费它所订阅的消息。这种模式被广泛的应用于软硬件的系统设计中。比如：配置中心的一个配置修改之后，就是通过发布订阅的方式传递给订阅这个配置的订阅者来实现自动刷新的：

与观察者模式区别：

可以看到这里有一个非常大的区别就是：发布订阅模式在两个角色中间是一个中间角色来过渡的，发布者并不直接与订阅者产生交互。

回想一下生产者消费者模式，这个中间过渡区域对应的就是是缓冲区。因为这个缓冲区的存在，发布者与订阅者的工作就可以实现更大程度的解耦。发布者不会因为订阅者处理速度慢，而影响自己的发布任务，它只需要快速生产即可。而订阅者也不用太担心一时来不及处理，因为有缓冲区在，可以一点点排队来完成（也就是我们常说的“削峰填谷”效果）。

而我们所熟知的RabbitMQ、Kafka、RocketMQ这些中间件的本质其实就是实现发布订阅模式中的这个中间缓冲区。而Redis也提供了简单的发布订阅实现，当我们有一些简单需求的时候，也是可以一用的。

参考：
https://blog.didispace.com/spring-boot-learning-25-5-5/