redis-sentinel

　　在上一篇博客---- Redis详解（八）------ 主从复制 ,我们简单介绍了Redis的主从架构,但是这种主从架构存在一个问题,当主服务器宕机,从服务器不能够自动切换成主服务器,为了解决这个问题,我们又介绍了哨兵模式,本篇博客我们继续深入的介绍一下这种模式. 1、架构图 　　 2、服务器列表 　　 3、搭建主从模式 　　 ①、主要配置项 　　主服务器(上图的Node1)配置文件 redis.config 主要配置项: #配置端口 port 6379 #以守护进程模式启动 daemonize yes #pid的存放文件 pidfile /var/run/redis_6379.pid #日志文件名 logfile "redis_6379.log" #存放备份文件以及日志等文件的目录 dir "/opt/redis/data" 　　从服务器配置文件主要配置项基本和主服务器保持一致,需要修改端口 port ;另外存放位置和日志文件名也可以根据需要修改. 　　为了表示主从关系,还需要在从服务器配置文件中添加一行 重要配置 : #配置主服务器IP,端口 slaveof 192.168.14.101 6379 　　 ②、验证主从关系 　　配置完成后,我们通过 redis-server redis.conf 命令启动Redis.然后通过 redis-cli -p 端口

一、缓存雪崩 缓存雪崩表示在某一时间段，缓存集中失效，导致请求全部走数据库，有可能搞垮数据库，使整个服务瘫痪。 使缓存集中失效的原因： 1.redis服务器挂掉了。 2.对缓存数据设置了相同的过期时间，导致某时间段内缓存集中失效。 如何解决缓存集中失效： 1.针对原因1，可以实现redis的高可用，Redis Cluster 或者 Redis Sentinel(哨兵) 等方案。 2.针对原因2，设置缓存过期时间时加上一个随机值，避免缓存在同一时间过期。 <?php $redis = new Redis (); $redis -> connect ( '127.0.0.1' , 6379 , 60 ); $redis -> auth ( '' ); //设置过期时间加上一个随机值 $redis -> set ( 'article_content_1' , '文章内容' , 60 + mt_rand ( 1 , 60 )); $redis -> set ( 'article_content_2' , '文章内容' , 60 + mt_rand ( 1 , 60 )); 3.使用双缓存策略，设置两个缓存，原始缓存和备用缓存，原始缓存失效时，访问备用缓存，备用缓存失效时间设置长点。 //原始缓存 $redis->set('article_content_2', '文章内容', 60); /

本page主要总结redis作为软件系统的缓存可能带来的问题及应对方法总结。 1. 缓存穿透 　　 　　 缓存穿透： 指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。 缓存穿透几种解决办法： 缓存空值，在从 DB 查询对象为空时，也要将空值存入缓存，具体的值需要使用特殊的标识， 能和真正缓存的数据区分开，另外将其过期时间设为较短时间。 使用布隆过滤器，布隆过滤器能判断一个 key 一定不存在（不保证一定存在，因为布隆过滤器结构原因，不能删除，但是旧值可能被新值替换，而将旧值删除后它可能依旧判断其可能存在），在缓存的基础上，构建布隆过滤器数据结构，在布隆过滤器中存储对应的 key，如果存在，则说明 key 对应的值为空。 2. 缓存击穿 　　 　　 缓存击穿： 某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。 缓存击穿几种解决办法： 设置二级缓存，或者设置热点缓存永不过期，需要根据实际情况进行配置。 使用互斥锁，在执行过程中，如果缓存过期，那么先获取分布式锁，在执行从数据库中加载数据，如果找到数据就存入缓存，没有就继续该有的动作

原文转载自「刘悦的技术博客」 https://v3u.cn/a_id_110 我们知道，Redis的集群方案大致有三种：1）redis cluster集群方案；2）master/slave主从方案；3）哨兵模式来进行主从替换以及故障恢复。 sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。 同样，我们使用docker进行搭建 新建一个mkdir redis-sentinel文件夹 进入项目文件夹 cd redis-sentinel，再建立一个sentinel专门来存放哨兵脚本，然后cd sentinel 建立sentinel.conf配置文件： sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 5000 该配置的意思是，监控主服务器的6379端口并且起两个实例，如果哨兵5s内没有收到主节点的心跳，哨兵就认为主节点宕机了

一、缓存雪崩 缓存雪崩表示在某一时间段，缓存集中失效，导致请求全部走数据库，有可能搞垮数据库，使整个服务瘫痪。 使缓存集中失效的原因： 1、redis服务器挂掉了。 2、对缓存数据设置了相同的过期时间，导致某时间段内缓存集中失效。 如何解决缓存集中失效： 1、针对原因1，可以实现redis的高可用，Redis Cluster 或者 Redis Sentinel(哨兵) 等方案。 2、针对原因2，设置缓存过期时间时加上一个随机值，避免缓存在同一时间过期。 <?php $redis = new Redis(); $redis->connect('127.0.0.1', 6379, 60); $redis->auth(''); //设置过期时间加上一个随机值 $redis->set('article_content_1', '文章内容', 60 + mt_rand(1, 60)); $redis->set('article_content_2', '文章内容', 60 + mt_rand(1, 60)); 3、使用双缓存策略，设置两个缓存，原始缓存和备用缓存，原始缓存失效时，访问备用缓存，备用缓存失效时间设置长点。 //原始缓存 $redis->set('article_content_2', '文章内容', 60); //设置备用缓存，失效时间设置长点 $redis->set(

缓存穿透 ：指查询一个一定不存在的数据。由于缓存命不中时会去查询数据库，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。 解决方案： 1.是将空对象也缓存起来，并给它设置一个很短的过期时间，最长不超过5分钟 ​ 2.采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力 雪崩 ：如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，就会造成缓存雪崩。 解决方案： 1.尽量让失效的时间点不分布在同一个时间点 2.保证缓存层服务的高可用，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，比如 Redis Sentinel 和 Redis Cluster 都实现了高可用。 缓存击穿 ：是指一个key非常热点，在不停的扛着大并发，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。 解决方案： 　　 可以设置key永不过期 来源： oschina 链接： https://my.oschina.net/u/4283481/blog/4133479

Redis缓存穿透和缓存雪崩以及解决方案 Redis缓存穿透和缓存雪崩以及解决方案 缓存穿透 解决方案 布隆过滤 缓存空对象 比较 缓存雪崩 解决方案 保证缓存层服务高可用性 依赖隔离组件为后端限流并降级 数据预热 缓存并发 分布式锁 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存不命中，接着查询数据库也无法查询出结果，因此也不会写入到缓存中，这将会导致每个查询都会去请求数据库，造成缓存穿透； 解决方案 布隆过滤 对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力； 缓存空对象 当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源； 但是这种方法会存在两个问题： 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键； 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。 比较 缓存雪崩 缓存雪崩是指，由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。 解决方案 保证缓存层服务高可用性 即使个别节点、个别机器

1. 异常信息: All sentinels down, cannot determine where is mymaster master is running... 通过测试: 　　 @Test public void testSentinel(){ HashSet <String> sentinels = new HashSet<> (); sentinels.add( "192.168.72.129:26379" ); JedisSentinelPool pool = new JedisSentinelPool("mymaster" , sentinels); Jedis jedis = pool.getResource(); jedis.set( "hello", "world" ); System.out.println(jedis.get( "hello" )); } 报出错误: 警告: Cannot get master address from sentinel running @ 192.168.72.129:26379. Reason: redis.clients.jedis.exceptions.JedisConnectionException: Failed connecting to host 192.168.72.129:26379. Trying

本篇基于centos7服务器进行部署开发 代码地址: https://github.com/chukaihong/docker-compose .喜欢的点个start 一.拉取redis镜像,使用如下命令 docker pull redis 1.查看镜像是否拉取成功,使用如下命令 docker images 显示如下则证明拉取成功 二.编写docker-compose.yml文件实现redis一主二从 version: '3.7' services: master: image: redis container_name: redis-master restart: always command: redis-server --port 6379 --requirepass test@dbuser2018 --appendonly yes ports: - 6379:6379 volumes: - ./data:/data slave1: image: redis container_name: redis-slave-1 restart: always command: redis-server --slaveof 192.168.8.188 6379 --port 6380 --requirepass test@dbuser2018 --masterauth test

文章大纲 一、基础知识学习 二、Redis常见的几种架构及优缺点总结 三、Redis之Redis Sentinel（哨兵）实战 四、Redis之Redis Cluster（分布式集群）实战 五、Java之Jedis连接Redis（Redis Cluster版本） 六、Redis之云平台介绍 七、项目源码与资料下载 八、参考文章 一、基础知识学习   Redis的基础包括以下内容，可参考文章 https://www.cnblogs.com/WUXIAOCHANG/p/10832330.html 进行学习 （1）安装并设置开机自动启动 （2）Redis文件结构 （3）Redis启动方式 （4）Redis持久化 （5）Redis配置文件详解 （7）Redis图形化工具 （8）Java之Jedis连接Redis单机 二、Redis常见的几种架构及优缺点总结 1. Redis单副本 Redis单副本，采用单个Redis节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。 优点 架构简单，部署方便； 高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务； 高性能。 缺点 不保证数据的可靠性； 在缓存使用