1、Ehcache做一级缓存，Redis做二级缓存
Ehcache是本地缓存，不需要走网络，而Redis是分布式缓存，需要走网络，所以使用Ehcache会减轻redis的访问压力，也可以提高访问速度；
如果redis在高并发的情况下，宕机了，突然大量请求操作数据库，产生雪崩效应；
2、搭建Redis集群方案
主从复制：主要因为每个节点都要保存一份数据，数据十分冗余，浪费内存；
客户端分片技术：不推荐，主要因为在扩容与缩容的时候需要手动调整分片程序；同时出现故障不能自动转移；
Redis-cluster:推荐使用这种方式，这里引入了一个卡槽的概念，就像mysql中的分库分表中的表的概念，卡槽的数量是一定的0-16384；当我们向redis存放一个key-value时，先应用CRC16算法计算出key的值，然后取余卡槽的数量，在查看具体的某个卡槽存放在哪个redis服务器节点，最后做出请求；卡槽是均摊到redis服务器节点的；没有检点都会有主节点与从节点，如果新增节点或删除redis节点会自动移动卡槽；
分布式缓存架构.docx集群环境搭建.doc上课代码.zip
3、redis做了集群，整体是不支持事务的，但是每个节点是支持事务的 multi exec discard
4、
雪崩效应的问题：如果redis中的所有key在同一时刻失效的话，同时在此刻有大量的请求来访问服务器，会导致直接数据库连接异常，甚至直接瘫痪整个系统（限流、服务降级、熔断）
redis雪崩效应解决方案：
分布式锁（本地锁）：分布式项目应用分布式锁，小项目部署在一台服务器则应用本地锁（lock/redis、 zookeeper）
使用消息中间件的方式：如果redis查询不到，则将请求存放到MQ中，消费者端可以做一个限流，做完查询操作 将结果返回给生产者，同时将结果缓存到redis中；但是通过限流将数据库应用利用到最大；
一级加二级缓存（Ehcache + redis）
均摊分配redis key的失效时间设置不同
穿透原因：
客户端传来的key，在redis和数据库中没有响应的数据，如果客户端连续发送大量这样的请求
穿透解决方案：
1、网关判断客户端传入对应的key的规则，如果不符合则就不需要查询，直接返回null;
2、如果我们的key没有做规则的一些定制，那么我们就要用雪崩效应的方案，同时加上将key对应的value设置为 null存放到redis中，不过在每次向数据库添加key的时候我们要清除redis中对应的key；
5、
在redis中如何设置唯一key，这里get到一点，可以借鉴一下，this.getClass().getName() + “-“ +Thread.currentThread().getStackTrace()[1].getMethodName() + “-id” + id;
若有收获，就点个赞吧
0 人点赞
