分布式缓存与多级缓存可以实现服务的高性能和高可用。下面将介绍一下分布式缓存中主从集群与哨兵集群的配置，与多级缓存的基本场景。
一、分布式缓存配置
（一）主从集群
主从集群一般由一个负责写的主节点和多个负责读的从节点组成。下面将演示在本机搭建一个三节点的主从集群，它们的端口号分别为：7001、7002、7003，其中，7001为主节点。
分别编辑三个redis配置文件，如下：
# 7001.conf
port 7001
# 7002.conf
port 7002
# 7003.conf
port 7002
随后逐个启动它们：
redis-server 7001.conf
redis-server 7002.conf
redis-server 7003.conf
最后，进入任意一个节点验证它们的主从关系：
redis-cli -p 7001
> INFO Replication
在控制台返回的信息可以看到，7001是master节点，它下面还有两个slave节点。主从集群不允许往从节点写入数据，本集群中7001是唯一一个可以写入数据的主节点。
（二）哨兵集群
主从集群在一定程度上提升了Redis的性能，哨兵集群则在主从集群的基础上强化了Redis集群的可用性，保证Redis服务的自动故障恢复。
下面将演示在本机搭建一个三节点的哨兵集群，它们的端口号分别为：27001、27002、27003。
分别编辑三个sentinel配置文件，如下：
# 27001.conf
port 27001
sentinel monitor mymaster 127.0.0.1 7001 2
# 27002.conf
port 27002
sentinel monitor mymaster 127.0.0.1 7001 2
# 27003.conf
port 27003
sentinel monitor mymaster 127.0.0.1 7001 2
随后逐个启动它们：
redis-sentinel 27001.conf
redis-sentinel 27002.conf
redis-sentinel 27003.conf
随后，哨兵集群会监控主从集群，在主从集群某些节点挂掉后，哨兵会自动选举某一个从节点成为新的主节点，在旧的主节点恢复服务后，其会降级为从节点加入到新的主节点中。
为了验证上述规则，可以先关停7001主节点服务，监控7002与7003的日志，在等待一段时间后，通过日志可以发现，其中一台节点会成为主节点，随后重启7001，等待片刻，连接任意一台Redis，查看INFO信息，主从节点已然发生切换。
查看redis与sentinel的配置文件，可以发现它们已经被哨兵自动修改了。
（三）分片集群
主从集群与哨兵集群可以很好地为提供高性能高可用的Redis服务，以满足当前大多数读多写少的应用场景。但如果写操作也很频繁，则可以考虑搭建分片集群。
分片集群中有多个主节点，通过散列插槽机制将Redis数据分布到不同的主节点。主节点相互交换心跳数据以保证健康（类似于上面的哨兵），且每个主节点都可以有从节点（类似于上面主从）。
普通应用场景使用主从集群与哨兵集群即可，此处暂时略过分片集群的配置过程，后续有需要再加上。
二、多级缓存简介
一个请求的流程一般是：用户浏览器 -> Nginx -> Tomcat -> Redis -> DB。从浏览器到数据库的各个阶段都可以配置缓存，包括：浏览器缓存、Nginx缓存、Tomcat中JVM进程缓存、Redis缓存等等，它们组合在一起便是多级缓存。多级缓存可以有效提升性能，避免服务雪崩。
Redis缓存是多级缓存的重要部分，其本身的性能不成问题。但在高并发场景下，Tomcat却会成为性能桎梏，在Tomcat中访问Redis便会成为短板。与之相比，Nginx性能更好，对Redis预热数据的读操作可以提前交由基于Nginx的OpenResty执行。这样之后，一个请求的流程就变成了用户浏览器 -> Nginx -> Redis -> Tomcat -> DB。可以看到，与之前的流程相比，Redis相较于Tomcat提前了。这种方案解决了高并发的缓存数据高频读的问题，但同时也引入了额外的开发成本（基于Nginx的OpenResty基于lua语言），需要根据业务需求来权衡性能与开发成本。
多级缓存中的数据同步可以采用Canal等组件，canal伪装成了一个MySql从节点，来实时监控数据的变动，一旦数据库存在增删改操作，收到通知将主动更新Redis中的数据，以达到数据库与Redis的数据同步。
参考文档