Redis 3.x——哨兵开发与运维中的问题

原创 于 2026-07-17 00:04:59 发布 · 184 阅读 · 3 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
收录于
Redis

当前文章被收录于：

Redis
78 篇文章 3 人学习
订阅专栏 查看详情

哨兵开发与运维中的问题

1、故障转移日志分析

1.1、Redis Sentinel拓扑结构

本次故障转移的分析直接使用的拓扑和配置进行说明，为了方便分析故障转移的过程，表9-4列出了每个节点的角色、ip、端口、进程号、runId。

在这里插入图片描述
因为故障转移涉及节点关系的变化，所以下面说明中用端口号代表节点。

1.2、开始故障转移测试

模拟故障的方法有很多，比较典型的方法有以下几种：

  • 方法一，强制杀掉对应节点的进程号，这样可以模拟出宕机的效果。
  • 方法二，使用Redis的debug sleep命令，让节点进入睡眠状态，这样可以模拟阻塞的效果。
  • 方法三，使用Redis的shutdown命令，模拟正常的停掉Redis。

本次我们使用方法一进行测试，因为从实际经验来看，数百上千台机器偶尔宕机一两台是会不定期出现的，为了方便分析日志行为，这里记录一下操作的时间和命令。

用kill-9使主节点的进程宕机，操作时间2016-07-2409：40：35：

$ kill -9 19661

1.3、观察效果

6380节点晋升为主节点，6381节点成为6380节点的从节点。

1.4、故障转移分析

相信故障转移的效果和预想的一样，这里重点分析相应节点的日志。

(1)6379节点日志

两个复制请求，分别来自端口为6380和6381的从节点：

19661:M 24 Jul 09:22:16.907 * Slave 127.0.0.1:6380 asks for synchronization
19661:M 24 Jul 09:22:16.907 * Full resync requested by slave 127.0.0.1:6380
…
19661:M 24 Jul 09:22:16.919 * Synchronization with slave 127.0.0.1:6380 succeeded
19661:M 24 Jul 09:22:23.396 * Slave 127.0.0.1:6381 asks for synchronization
19661:M 24 Jul 09:22:23.396 * Full resync requested by slave 127.0.0.1:6381
…
19661:M 24 Jul 09:22:23.432 * Synchronization with slave 127.0.0.1:6381 succeeded

09：40：35做了kill-9操作，由于模拟的是宕机效果，所以6379节点没有看到任何日志（这点和shutdown操作不太相同）​。

(2)6380节点日志

6380节点在09：40：35之后发现它与6379节点已经失联：

19667:S 24 Jul 09:40:35.788 # Connection with master lost.
19667:S 24 Jul 09:40:35.788 * Caching the disconnected master state.
19667:S 24 Jul 09:40:35.974 * Connecting to MASTER 127.0.0.1:6379
19667:S 24 Jul 09:40:35.974 * MASTER <-> SLAVE sync started
19667:S 24 Jul 09:40:35.975 # Error condition on socket for SYNC: Connection 
refused
…

09：41：06时它接到Sentinel节点的命令：清理原来缓存的主节点状态，Sentinel节点将6380节点晋升为主节点，并重写配置：

19667:M 24 Jul 09:41:06.161 * Discarding previously cached master state.
19667:M 24 Jul 09:41:06.161 * MASTER MODE enabled (user request from 'id=7 
    addr=127.0.0.1:46759 fd=10 name=sentinel-7044753f-cmd age=1111 idle=0 
    flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 
    omem=0 events=rw cmd=exec')
19667:M 24 Jul 09:41:06.161 # CONFIG REWRITE executed with success.

6381节点发来了复制请求：

19667:M 24 Jul 09:41:07.499 * Slave 127.0.0.1:6381 asks for synchronization
19667:M 24 Jul 09:41:07.499 * Full resync requested by slave 127.0.0.1:6381
…
19667:M 24 Jul 09:41:07.548 * Background saving terminated with success
19667:M 24 Jul 09:41:07.548 * Synchronization with slave 127.0.0.1:6381 succeeded

(3)6381节点日志

6381节点同样与6379节点失联：

19685:S 24 Jul 09:40:35.788 # Connection with master lost.
19685:S 24 Jul 09:40:35.788 * Caching the disconnected master state.
19685:S 24 Jul 09:40:36.425 * Connecting to MASTER 127.0.0.1:6379
19685:S 24 Jul 09:40:36.425 * MASTER <-> SLAVE sync started
19685:S 24 Jul 09:40:36.425 # Error condition on socket for SYNC: Connection refused
…

后续操作如下：

1)09：41：06时它接到Sentinel节点的命令，清理原来缓存的主节点状态，让它去复制新的主节点（6380节点）​：

19685:S 24 Jul 09:41:06.497 # Error condition on socket for SYNC: Connection refused
19685:S 24 Jul 09:41:07.008 * Discarding previously cached master state.
19685:S 24 Jul 09:41:07.008 * SLAVE OF 127.0.0.1:6380 enabled (user request 
    from 'id=7 addr=127.0.0.1:55872 fd=10 name=sentinel-7044753f-cmd age=1111 
    idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=133 qbuf-free=32635 obl=36 
    oll=0 omem=0 events=rw cmd=exec')
19685:S 24 Jul 09:41:07.008 # CONFIG REWRITE executed with success.

2)向新的主节点（6380节点）发起复制操作：

19685:S 24 Jul 09:41:07.498 * Connecting to MASTER 127.0.0.1:6380
…
19685:S 24 Jul 09:41:07.549 * MASTER <-> SLAVE sync: Finished with success

(4)sentinel-1节点日志

09：41：05对6379节点作了主观下线(+sdown)，注意这个时间正好是kill-9后的30秒，和down-after-milliseconds的配置是一致的。Sentinel节点更新自己的配置纪元(new-epoch)：

19697:X 24 Jul 09:41:05.850 # +sdown master mymaster 127.0.0.1 6379
19697:X 24 Jul 09:41:05.928 # +new-epoch 1

后续操作如下：

1)投票给sentinel-3节点：

19697:X 24 Jul 09:41:05.929 # +vote-for-leader 7044753f564e42b1578341acf4c49dca
    3681151c 1
19697:X 24 Jul 09:41:06.913 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2

2)更新状态：从sentinel-3节点（领导者）得知：故障转移后6380节点变为主节点，并发现了两个从节点6381和6379，并在30秒后对(09：41：07~09：41：37)6379节点做了主观下线：

19697:X 24 Jul 09:41:06.913 # Next failover delay: I will not start a failover
     before Sun Jul 24 09:47:06 2016
19697:X 24 Jul 09:41:07.008 # +config-update-from sentinel 127.0.0.1:26381 
    127.0.0.1 26381 @ mymaster 127.0.0.1 6379
19697:X 24 Jul 09:41:07.008 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
19697:X 24 Jul 09:41:07.008 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ 
    mymaster 127.0.0.1 6380
19697:X 24 Jul 09:41:07.008 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ 
    mymaster 127.0.0.1 6380
19697:X 24 Jul 09:41:37.060 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ 
    mymaster 127.0.0.1 6380

(5)sentinel-2节点日志

整个过程和sentinel-1节点是一样的，这里就不占用篇幅分析了。

(6)sentinel-3节点日志

从sentinel-1节点和sentinel-2节点的日志来看，sentinel-3节点是领导者，所以分析sentinel-3节点的日志至关重要。

后续操作如下。

1)达到了客观下线的条件：

19713:X 24 Jul 09:41:05.854 # +sdown master mymaster 127.0.0.1 6379
19713:X 24 Jul 09:41:05.909 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
19713:X 24 Jul 09:41:05.909 # +new-epoch 1

2)sentinel-3节点被选为领导者：

19713:X 24 Jul 09:41:05.909 # +try-failover master mymaster 127.0.0.1 6379
19713:X 24 Jul 09:41:05.911 # +vote-for-leader 7044753f564e42b1578341acf4c49dca
    3681151c 1
19713:X 24 Jul 09:41:05.929 # 127.0.0.1:26379 voted for 7044753f564e42b1578341a
    cf4c49dca3681151c 1
19713:X 24 Jul 09:41:05.930 # 127.0.0.1:26380 voted for 7044753f564e42b1578341a
    cf4c49dca3681151c 1
19713:X 24 Jul 09:41:06.001 # +elected-leader master mymaster 127.0.0.1 6379

下表展示了3个Sentinel节点完成客观下线的时间点，从时间点可以看到sentinel-3节点最先完成客观下线。
在这里插入图片描述
3)故障转移。每一步都可以通过发布订阅来获取，对于每个字段的说明可以参考下表。

寻找合适的从节点作为新的主节点：

19713:X 24 Jul 09:41:06.001 # +failover-state-select-slave master mymaster
    127.0.0.1 6379

选出了合适的从节点（6380节点）​：

19713:X 24 Jul 09:41:06.077 # +selected-slave slave 127.0.0.1:6380 127.0.0.1
    6380 @ mymaster 127.0.0.1 6379

命令6380节点执行slaveof no one，使其成为主节点：

19713:X 24 Jul 09:41:06.077 * +failover-state-send-slaveof-noone slave
    127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

等待6380节点晋升为主节点：

19713:X 24 Jul 09:41:06.161 * +failover-state-wait-promotion slave
    127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

确认6380节点已经晋升为主节点：

19713:X 24 Jul 09:41:06.927 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1
    6380 @ mymaster 127.0.0.1 6379

故障转移进入重新配置从节点阶段：

19713:X 24 Jul 09:41:06.927 # +failover-state-reconf-slaves master mymaster
    127.0.0.1 6379

命令6381节点复制新的主节点：

19713:X 24 Jul 09:41:07.008 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1
    6381 @ mymaster 127.0.0.1 6379

6381节点正在重新配置成为6380节点的从节点，但是同步过程尚未完成：

19713:X 24 Jul 09:41:07.955 * +slave-reconf-inprog slave 127.0.0.1:6381
    127.0.0.1 6381 @ mymaster 127.0.0.1 6379

6381节点完成对6380节点的同步：

19713:X 24 Jul 09:41:07.955 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1
    6381 @ mymaster 127.0.0.1 6379

故障转移顺利完成：

19713:X 24 Jul 09:41:08.045 # +failover-end master mymaster 127.0.0.1 6379

故障转移成功后，发布主节点的切换消息：

19713:X 24 Jul 09:41:08.045 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380

下表记录了Redis Sentinel在故障转移一些重要的事件消息对应的频道。
在这里插入图片描述

<instance details>格式如下：

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

1.5、原主节点后续处理

重新启动原来的6379节点：

redis-server redis-6379.conf操作时间: 2016-07-24 09:46:21

(1)6379节点

启动后接到Sentinel节点的命令，让它去复制6380节点：

22223:M 24 Jul 09:46:21.260 * The server is now ready to accept connections on
    port 6379
22223:S 24 Jul 09:46:31.323 * SLAVE OF 127.0.0.1:6380 enabled (user request 
    from 'id=2 addr=127.0.0.1:51187 fd=6 name=sentinel-94dde2f5-cmd age=10 
    idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 
    oll=0 omem=0 events=rw cmd=exec')
        22223:S 24 Jul 09:46:31.323 # CONFIG REWRITE executed with success.
        …

(2)6380节点

接到6379节点的复制请求，做复制的相应处理：

19667:M 24 Jul 09:46:32.284 * Slave 127.0.0.1:6379 asks for synchronization
19667:M 24 Jul 09:46:32.284 * Full resync requested by slave 127.0.0.1:6379
…
19667:M 24 Jul 09:46:32.353 * Synchronization with slave 127.0.0.1:6379 succeeded

(3)sentinel-1节点日志

撤销对6379节点主观下线的决定：

19707:X 24 Jul 09:46:21.406 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @
    mymaster 127.0.0.1 6380

(4)sentinel-2节点日志

撤销对6379节点主观下线的决定：

19713:X 24 Jul 09:46:21.408 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @
    mymaster 127.0.0.1 6380

(5)sentinel-3节点日志

撤销对6379节点主观下线的决定，更新Sentinel节点配置：

19697:X 24 Jul 09:46:21.367 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @
    mymaster 127.0.0.1 6380
19697:X 24 Jul 09:46:31.322 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 
    6379 @ mymaster 127.0.0.1 6380

1.6、注意点

部署各个节点的机器时间尽量要同步，否则日志的时序性会混乱，例如可以给机器添加NTP服务来同步时间。

2、节点运维

2.1、节点下线

在介绍如何进行节点下线之前，首先需要弄清两个概念：临时下线和永久下线。

  • 临时下线：暂时将节点关掉，之后还会重新启动，继续提供服务。
  • 永久下线：将节点关掉后不再使用，需要做一些清理工作，如删除配置文件、持久化文件、日志文件。

所以运维人员需要弄清楚本次下线操作是临时下线还是永久下线。

通常来看，无论是主节点、从节点还是Sentinel节点，下线原因无外乎以下几种：

  • 节点所在的机器出现了不稳定或者即将过保被回收。
  • 节点所在的机器性能比较差或者内存比较小，无法支撑应用方的需求。
  • 节点自身出现服务不正常情况，需要快速处理。

(1)主节点

如果需要对主节点进行下线，比较合理的做法是选出一个“合适”​（例如性能更高的机器）的从节点，使用sentinel failover功能将从节点晋升主节点，只需要在任意可用的Sentinel节点执行如下操作即可。

sentinel failover <master name>

如图所示，在任意一个Sentinel节点上（例如 26379端口节点）执行sentinel failover即可。

在这里插入图片描述

Redis Sentinel存在多个从节点时，如果想将指定从节点晋升为主节点，可以将其他从节点的slavepriority配置为0，但是需要注意failover后，将slave-priority调回原值。

(2)从节点和Sentinel节点

如果需要对从节点或者Sentinel节点进行下线，只需要确定好是临时还是永久下线后执行相应操作即可。如果使用了读写分离，下线从节点需要保证应用方可以感知从节点的下线变化，从而把读取请求路由到其他节点。

需要注意的是，Sentinel节点依然会对这些下线节点进行定期监控，这是由Redis Sentinel的设计思路所决定的。下面日志显示（需要设置loglevel=debug）​，6380节点下线后，Sentinel节点还是会定期对其监控，会造成一定的网络资源浪费。

-cmd-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
    #Connection refused
-pubsub-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 
    #Connection refused
…

2.2、节点上线

(1)添加从节点

添加从节点的场景大致有如下几种：

  • 使用了读写分离，但现有的从节点无法支撑应用方的流量。
  • 主节点没有可用的从节点，无法支持故障转移。
  • 添加一个更强悍的从节点利用手动failover替换主节点。

添加方法：添加slaveof{masterIp}{masterPort}的配置，使用redis-server启动即可，它将被Sentinel节点自动发现。

(2)添加Sentinel节点

添加Sentinel节点的场景可以分为以下几种：

  • 当前Sentinel节点数量不够，无法达到Redis Sentinel健壮性要求或者无法达到票数。
  • 原Sentinel节点所在机器需要下线。

添加方法：添加sentinel monitor主节点的配置，使用redis-sentinel启动即可，它将被其余Sentinel节点自动发现。

(3)添加主节点

因为Redis Sentinel中只能有一个主节点，所以不需要添加主节点，如果需要替换主节点，可以使用Sentinelfailover手动故障转移。

2.3、节点配置

这里给出Sentinel节点配置时要注意的地方：

  • Sentinel节点配置尽可能一致，这样在判断节点故障时会更加准确。
  • Sentinel节点支持的命令非常有限，例如config命令是不支持的，而Sentinel节点也需要dir、loglevel之类的配置，所以尽量在一开始规划好，不过所幸Sentinel节点不存储数据，如果需要修改配置，重新启动即可。

Sentinel节点只支持如下命令：ping、sentinel、subscribe、unsubscribe、psubscribe punsubscribe、publish、info、role、client、shutdown。

3、 高可用读写分离

3.1、从节点的作用

从节点一般可以起到两个作用：第一，当主节点出现故障时，作为主节点的后备“顶”上来实现故障转移，RedisSentinel已经实现了该功能的自动化，实现了真正的高可用。第二，扩展主节点的读能力，尤其是在读多写少的场景非常适用，通常的模型如图所示。

在这里插入图片描述
但上述模型中，从节点不是高可用的，如果slave-1节点出现故障，首先客户端client-1将与其失联，其次Sentinel节点只会对该节点做主观下线，因为RedisSentinel的故障转移是针对主节点的。所以很多时候，Redis Sentinel中的从节点仅仅是作为主节点一个热备，不让它参与客户端的读操作，就是为了保证整体高可用性，但实际上这种使用方法还是有一些浪费，尤其是在有很多从节点或者确实需要读写分离的场景，所以如何实现从节点的高可用是非常有必要的。

3.2、Redis Sentinel读写分离设计思路

Redis Sentinel在对各个节点的监控中，如果有对应事件的发生，都会发出相应的事件消息​，其中和从节点变动的事件有以下几个：

  • +switch-master：切换主节点（原来的从节点晋升为主节点）​，说明减少了某个从节点。
  • +convert-to-slave：切换从节点（原来的主节点降级为从节点）​，说明添加了某个从节点。
  • +sdown：主观下线，说明可能某个从节点可能不可用（因为对从节点不会做客观下线）​，所以在实现客户端时可以采用自身策略来实现类似主观下线的功能。
  • +reboot：重新启动了某个节点，如果它的角色是slave，那么说明添加了某个从节点。

所以在设计Redis Sentinel的从节点高可用时，只要能够实时掌握所有从节点的状态，把所有从节点看做一个资源池（如图所示）​，无论是上线还是下线从节点，客户端都能及时感知到（将其从资源池中添加或者删除）​，这样从节点的高可用目标就达到了。

在这里插入图片描述

标签
#redis #运维 #Sentinel
[springboot]整合连接redis单例、哨兵及集群模式
字母哥博客
05-17 4408
当redis 哨兵或cluster集群搭建好之后，在Spring Boot应用中你该如何去理解这些redis实例及集群模式，如何连接及使用这些redis实例。
【Redis(5)】Redis哨兵模式配置示例
JCoder的博客
04-20 1123
哨兵节点是Redis高可用性架构的重要补充。它们提供了自动的故障检测和转移，无需人工干预，从而提高了Redis在面临主节点故障时的自我恢复能力。在设计Redis系统时，考虑到系统的稳定性和可用性，通常会在主从模式的基础上添加哨兵节点。推荐至少部署三个哨兵节点以确保系统的健壮性和决策的可靠性。
Redis开发与运维教程
q64261750的博客
07-06 3677
Redis 学习笔记 Redis特性 Redis可以做什么 缓存；排行榜系统；计数器应用；社交网络：点赞，喜好，推送；消息队列。 Redis为什么这么快 1.通过内存访问数据 2.采用非阻塞IO，不在网络IO上浪费过多时间 3.单线程避免了线程切换和多线程竞争资源的问题 Redis与Memcahce比较 1.Redis为单线程系统，memcache为多线程 2.Redis支持持久化，memcache不支持 3.Redis天然支持主从复制，memcache需要自己实现 4.Redis内存分配临时申请空间，存在
Redis主从哨兵模式中出现双主
喝醉酒的小白
09-29 1554
Redis主从哨兵模式中出现双主的原因主要与主从复制的机制和哨兵的故障转移机制有关。Redis主从哨兵模式中出现双主现象的原因主要是由于网络分区、配置错误和故障转移延迟等因素导致的。通过确保网络稳定、正确配置哨兵和优化故障转移策略，可以有效避免双主现象的发生。
Redis哨兵模式
最新发布
bit_pan的博客
09-27 651
摘要： Redis哨兵模式通过独立进程监控主从节点，实现自动故障转移，提升系统高可用性。其核心机制包括主观下线判定、客观下线投票、领头哨兵选举及从节点晋升流程。优点在于自动容灾、易用兼容；缺点包含写单点瓶颈、数据一致性风险及转移延迟。哨兵模式有效解决了主从复制的手动切换痛点，但需权衡其复杂度与性能局限。适用于对自动容灾有强需求的Redis主从架构场景。
Redis集群运维与核心原理（哨兵选举、集群选举等）剖析
小强同志的博客
02-06 3464
1、Redis集群方案比较 哨兵模式 高可用集群模式 redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要 sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可 水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于 之前版本的哨兵模式，且集群配置非常简单 2、Redis高可用集群搭建 redis安装 下载地址：ht
redis哨兵模式的原理及部署
misakivv的博客
04-16 1022
Redis Sentinel 是一个分布式系统，为Redis提供高可用性解决方案。可以在一个架构中运行多个 Sentinel 进程(progress)， 这些进程使用流言协议 (gossip protocols) 来接收关于主服务器是否下线的信息， 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。
Redis集群故障转移：Tiny RDM中的哨兵自动切换
gitblog_00215的博客
09-06 855
在分布式系统中，Redis集群的高可用性面临三大核心挑战：主节点故障导致服务中断、手动切换流程复杂易错、脑裂问题引发数据不一致。传统解决方案依赖人工监控与干预，平均恢复时间（MTTR）往往超过10分钟，远不能满足生产环境需求。哨兵（Sentinel）作为Redis官方高可用解决方案，通过监控、通知、自动故障转移三大功能解决上述痛点，但原生命令行操作门槛高、状态可视化缺失成为新的运维瓶颈。 Tin...
redis哨兵模式
超级博客
05-04 914
尽管哨兵模式提供了一些优势，但它也有一些局限性，例如内存容量和写入性能都受限于单个节点。为了克服这些限制，Redis在3.x版本后推出了Cluster模式，这一模式通过数据分片和多节点水平扩展，有效提高了内存利用率和写入性能，适用于更大规模和更高要求的数据处理场景。
SpringBoot--RedisTemplate详解(String，List)
吴声子夜歌的博客
02-05 5740
RedisTemplate Spring封装了RedisTemplate对象来对redis进行各种操作，它支持所有的redis原生api。 RedisTemplate在Spring代码中的结构如下： org.springframework.data.redis.core Class RedisTemplate<K,V> java.lang.Object org.springfr...
NoSQL概述、NoSQL数据库的分类、主流产品及特点
吴声子夜歌的博客
10-04 5462
什么是NoSQL NoSQL（NoSQL = Not Only SQL），即“不仅仅是SQL”，是一项全新的数据库理念，泛指非关系型数据库。 为什么需要NoSQL 随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0 网站，特别是超大规模和高并发的SNS类型的web2.0 纯动态网站已经显得力不从心，暴...
Redis--事务回滚
吴声子夜歌的博客
11-15 5179
Redis事务回滚 对于 Redis 而言，不单单需要注意其事务处理的过程，其回滚的能力也和数据库不太一样，这也是需要特别注意的一个问题——Redis 事务遇到的命令格式正确而数据类型不符合，如图 1 所示。 从图 1 中可知，我们将 key1 设置为字符串，而使用命令 incr 对其自增，但是命令只会进入事务队列，而没有被执行，所以它不会有任何的错误发生，而是等待 exec 命令的执行。 当 ...
SpringBoot--RedisTemplate详解（Hash、Set、ZSet）
吴声子夜歌的博客
02-05 4988
Redis的Hash数据结构 Redis的散列可以让用户将多个键值对存储到一个Redis键里面。 public interface HashOperations<H,HK,HV> HashOperations提供一系列方法操作hash： 初始数据: //template.opsForHash().put("redisHash","name","tom"); //temp...
Redis--watch命令——监控事务
吴声子夜歌的博客
11-15 1434
Redis watch命令——监控事务 在 Redis 中使用 watch 命令可以决定事务是执行还是回滚。一般而言，可以在 multi 命令之前使用 watch 命令监控某些键值对，然后使用 multi 命令开启事务，执行各类对数据结构进行操作的命令，这个时候这些命令就会进入队列。 当 Redis 使用 exec 命令执行事务的时候，它首先会去比对被 watch 命令所监控的键值对，如果没有发生...
Redis——构建布隆过滤器
吴声子夜歌的博客
04-16 1406
如果对应的 key 已经存在，bf.reserve 会报错。使用时不要让实际元素远大于初始化大小，当实际元素开始超出初始化大小时，应该对 布隆过滤器进行重建，重新分配一个 size 更大的过滤器，再将所有的历史元素批量 add 进 去 (这就要求我们在其它的存储器中记录所有的历史元素)。布隆过滤器的 initial_size 估计的过大，会浪费存储空间，估计的过小，就会影响准确 率，用户在使用之前一定要尽可能地精确估计好元素数量，还需要加上一定的冗余空间以避 免实际元素可能会意外高出估计值很多。
Redis——GeoHash
吴声子夜歌的博客
04-17 1217
方格越 小，坐标越精确。我们知道，经度范围是东经180到西经180，纬度范围是南纬90到北纬90，我们设定西经为负，南纬为负，所以地球上的经度范围就是[-180， 180]，纬度范围就是[-90，90]。这个命令和 GEORADIUS 命令一样， 都可以找出位于指定范围内的元素， 但是 GEORADIUSBYMEMBER 的中心点是由给定的位置元素决定的， 而不是像 GEORADIUS 那样， 使用输入的经度和纬度来决定中心点。命令返回的 geohash 的位置与用户给定的位置元素的位置一一对应。
Redis——Info指令
吴声子夜歌的博客
04-17 1059
当从库因为网络原因临 时断开了主库的复制，然后网络恢复了，又重新连上的时候，这段断开的时间内发生在 master 上的修改操作指令都会放在积压缓冲区中，这样从库可以通过积压缓冲区恢复中断的 主从同步过程。如果从库断开的时间过长，或 者缓冲区的大小设置的太小，都会导致从库无法快速恢复中断的主从同步过程，因为中间的 修改指令被覆盖掉了。在使用 Redis 时，时常会遇到很多问题需要诊断，在诊断之前需要了解 Redis 的运行状 态，通过强大的 Info 指令，你可以清晰地知道 Redis 内部一系列运行参数。
Redis--哈希数据结构（Hash）和常用命令
吴声子夜歌的博客
11-14 970
Redis哈希数据结构和常用命令 Redis 中哈希结构就如同 Java 的 map 一样，一个对象里面有许多键值对，它是特别适合存储对象的，如果内存足够大，那么一个 Redis 的 hash 结构可以存储 2 的 32 次方减 1 个键值对（40 多亿）。 一般而言，不会使用到那么大的一个键值对，所以我们认为 Redis 可以存储很多的键值对。在 Redis 中，hash 是一个 String ...
Redis——构建简单限流和漏斗限流
吴声子夜歌的博客
04-17 859
但这种方案也有缺点，因为它要记录时间窗口内所有的行为记录，如果这 个量很大，比如限定 60s 内操作不得超过 100w 次这样的参数，它是不适合做这样的限流 的，因为会消耗大量的存储空间。限流算法在分布式领域是一个经常被提起的话题，当系统的处理能力有限时，如何阻止 计划外的请求继续对系统施压，这是一个需要重视的问题。同时，代码的 复杂度也跟着升高很多。为节省内存，我们只需要保留时间窗口内的行为记录，同时如果用户是冷用户，滑动时 间窗口内的行为是空记录，那么这个 zset 就可以从内存中移除，不再占用空间。
Redis--链表（linked-list）数据结构和常用命令
吴声子夜歌的博客
11-14 773
Redis链表（linked-list）数据结构和常用命令 链表结构是 Redis 中一个常用的结构，它可以存储多个字符串，而且它是有序的，能够存储 2 的 32 次方减 1 个节点（超过 40 亿个节点）。 Redis 链表是双向的，因此即可以从左到右，也可以从右到左遍历它存储的节点，链表结构如图 1 所示。 由于是双向链表，所以只能够从左到右，或者从右到左地访问和操作链表里面的数据节点。但是...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值