初识Redis-3-Redis集群与进阶

最新推荐文章于 2024-09-10 21:44:14 发布
最新推荐文章于 2024-09-10 21:44:14 发布
阅读量365 收藏
点赞数
分类专栏： 数据库 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_43607736/article/details/117878756
版权
本文详细介绍了Redis的发布订阅、主从复制、哨兵模式，以及如何配置和测试哨兵模式。主从复制提供数据冗余和故障恢复，哨兵模式则能自动监测和切换主节点，提升系统的可用性。此外，还探讨了缓存穿透、缓存击穿和缓存雪崩的问题及其解决方案，包括布隆过滤器、缓存空对象、分布式锁和数据预热等策略。
摘要由CSDN通过智能技术生成

文章目录

Redis发布订阅

  • Redis发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息

  • Redis客户端可以订阅任意数量的频道

  • 订阅/发布消息图：
    在这里插入图片描述

  • 下图展示了频道channel1，以及订阅这个频道的三个客户端—client2、client5、client1之间的关系：
    在这里插入图片描述

  • 当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
    在这里插入图片描述

  • 这些命令被广泛用于构建即时通信应用，比如网络聊天室(chatroom)和实时广播、实时提醒等
    在这里插入图片描述

  • 测试

    # 一个客户端A订阅频道
127.0.0.1:6379> SUBSCRIBE cbc
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "cbc"
3) (integer) 1
# 另一个客户端B给这个频道发消息
127.0.0.1:6379> PUBLISH cbc 123
(integer) 1
# A收到消息
127.0.0.1:6379> SUBSCRIBE cbc
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "cbc"
3) (integer) 1
1) "message"
2) "cbc"
3) "123"

  • 原理

    • 通过SUBSCRIBE 命令订阅某频道后，redis-server里维护了一个字典，字典的键就是一个个频道，而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE 命令的关键，就是将客户端添加到给定channel的订阅链表中
    • 通过PUBLISH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者
    • Pub/Sub从字面上理解就是发布( Publish)与订阅( Subscribe )，在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能

Redis主从复制

概念

  • 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)。数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主

  • 默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点

  • 主从复制的作用主要包括：

    1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
    2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余
    3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载，尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量
    4. 高可用( 集群 )基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础

  • 一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的(宕机)，原因如下：

    • 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大
    • 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G

  • 电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"

  • 对于这种场景，我们可以使用如下的这种架构：
    在这里插入图片描述

  • 主从复制，读写分离。80%的情况下都是在进行读操作，减缓服务器的压力，架构中经常使用，一般一主二从

环境配置

  • 只配置从库，不用配置主库，info replication命令查看库信息，发现默认就是主库

    127.0.0.1:6379> info replication # 查看库信息
# Replication
role:master # 角色 master
connected_slaves:0 # 没有从机
master_failover_state:no-failover
master_replid:2dc52f6af068f911affeb4c7565eb8d9a601c4e8
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

  • 复制三个配置文件，修改对应的信息

    1. 端口
    2. pid 进程文件名
    3. log日志名字
    4. dump.rdb名字

  • docker的话启动3个容器，注意端口和挂载的目录要不同

一主二从配置

  • slaveof no one在从机上解除主从关系

  • 一般情况下只用配从机就行了，认老大模式

    # slaveof命令指定172.17.0.1:6379为自身的主机
127.0.0.1:6379> SLAVEOF 172.17.0.1 6379
OK
# 两台从机连接后主机就能看见
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.17.0.3,port=6379,state=online,offset=266,lag=0
slave1:ip=172.17.0.4,port=6379,state=online,offset=266,lag=0

  • 真实的主从配置是在配置文件中配置的

  • 细节

    • 默认配置下只有主机可以写，从机只能读，主机中的所有信息和数据，都会自动被从机保存

      127.0.0.1:6379> get k1
"1"
127.0.0.1:6379> set k2 1
(error) READONLY You can't write against a read only replica.

    • 主机断开连接，从机依旧连接到主机，主机重新连接后set值从机依然能接收到

    • 设为从机后，从机之前的数据会被清空

    • 如果使用的命令配置的主从，从机重启了就会变回主机，再次连上主机，主机数据依旧可以获取到

  • 复制原理

    • Slave启动成功连接到master后会发送一个sync同步命令
    • Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步(全量复制)
    • 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
    • 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步
    • 只要是重新连接master，一次完全同步(全量复制)将被自动执行

  • 主—从---从式连接

    • 中间的从机信息，又当从机又当主机

      127.0.0.1:6379> info replication
# Replication
role:slave # 172.17.0.2的从机
master_host:172.17.0.2
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:1186
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:1 # 172.17.0.4的主机
slave0:ip=172.17.0.4,port=6379,state=online,offset=1186,lag=1
master_failover_state:no-failover
master_replid:7df33a210a100f37dbac3f972127c3973ec02b5b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1186
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1186

    • 中间的崩了尾端的从机就无法与主机连接了

    • 如果主机没了，我们可以手动设置中间的作为新主机：slaveof on one使自己变回主机

    • 以上两种，开发中都不会使用

哨兵模式

概述

  • 自动选老大的模式

  • 主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentihel (哨兵）架构来解决这个问题

  • 谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

  • 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例
    在这里插入图片描述

  • 这里的哨兵有两个作用

    • 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
    • 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机

  • 然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式
    在这里插入图片描述

  • 假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线

测试

  • 我们目前的状态是一主二从

  1. 配置哨兵配置文件sentinel.conf

    # sentinel monitor 被监控的进程名称 所在ip地址 端口 这里的1是指只要有1个哨兵认为主服务器已经下线，主服务器就会被判定为客观下线
sentinel monitor myredis 172.17.0.2 6379 1

  2. 启动哨兵

    root@00e8f02730fb:/# redis-sentinel sentinel.conf
38:X 06 Jun 2021 15:13:00.331 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
38:X 06 Jun 2021 15:13:00.331 # Redis version=6.2.4, bits=64, commit=00000000, modified=0, pid=38, just started
38:X 06 Jun 2021 15:13:00.331 # Configuration loaded
38:X 06 Jun 2021 15:13:00.331 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.4 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 38
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

38:X 06 Jun 2021 15:13:00.332 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
38:X 06 Jun 2021 15:13:00.352 # Sentinel ID is 23e8ce04d62ed08b72e364b8f512f3579e1b6f58
38:X 06 Jun 2021 15:13:00.352 # +monitor master myredis 172.17.0.2 6379 quorum 1
38:X 06 Jun 2021 15:13:00.353 * +slave slave 172.17.0.3:6379 172.17.0.3 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:13:00.355 * +slave slave 172.17.0.4:6379 172.17.0.4 6379 @ myredis 172.17.0.2 6379

# 关闭主机后，哨兵日志
38:X 06 Jun 2021 15:16:48.419 # +sdown master myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:48.419 # +odown master myredis 172.17.0.2 6379 #quorum 1/1
38:X 06 Jun 2021 15:16:48.419 # +new-epoch 1
38:X 06 Jun 2021 15:16:48.419 # +try-failover master myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:48.420 # +vote-for-leader 23e8ce04d62ed08b72e364b8f512f3579e1b6f58 1
38:X 06 Jun 2021 15:16:48.420 # +elected-leader master myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:48.420 # +failover-state-select-slave master myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:48.483 # +selected-slave slave 172.17.0.4:6379 172.17.0.4 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:48.483 * +failover-state-send-slaveof-noone slave 172.17.0.4:6379 172.17.0.4 6379 @ myredis 172.17.0.2 6379 # 故障转移
38:X 06 Jun 2021 15:16:48.555 * +failover-state-wait-promotion slave 172.17.0.4:6379 172.17.0.4 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:49.463 # +promoted-slave slave 172.17.0.4:6379 172.17.0.4 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:49.463 # +failover-state-reconf-slaves master myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:49.532 * +slave-reconf-sent slave 172.17.0.3:6379 172.17.0.3 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:50.359 * +slave-reconf-inprog slave 172.17.0.3:6379 172.17.0.3 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:50.359 * +slave-reconf-done slave 172.17.0.3:6379 172.17.0.3 6379 @ myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:50.431 # +failover-end master myredis 172.17.0.2 6379
38:X 06 Jun 2021 15:16:50.431 # +switch-master myredis 172.17.0.2 6379 172.17.0.4 6379
38:X 06 Jun 2021 15:16:50.431 * +slave slave 172.17.0.3:6379 172.17.0.3 6379 @ myredis 172.17.0.4 6379
38:X 06 Jun 2021 15:16:50.431 * +slave slave 172.17.0.2:6379 172.17.0.2 6379 @ myredis 172.17.0.4 6379
38:X 06 Jun 2021 15:17:20.485 # +sdown slave 172.17.0.2:6379 172.17.0.2 6379 @ myredis 172.17.0.4 6379
    • 如果Master节点断开了，这个时候就会从从机中随机选择一个服务器作为主机 (这里有一个投票算法)

  • 老大重连了也无济于事，会变成新主机的从机，需要重新手动配置变回主机

  • 优点：

    1. 哨兵集群，基于主从复制模式，所有的主从配置的优点它都有
    2. 主从可以切换，故障可以转移，系统的可用性更好
    3. 哨兵模式就是主从模式的升级，从手动变为自动

  • 缺点：

    1. redis不好在线扩容，集群容量一旦到达上限，在线扩容十分麻烦
    2. 实现哨兵模式的配置其实很麻烦，里面有很多其他选择

哨兵模式配置

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379，如果有多个哨兵，每个哨兵的端口得不同
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
# 这个数字越小，完成failover所需的时间就越长，
# 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
# 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
# 2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
# 3.当想要取消一个正在进行的failover所需要的时间。  
# 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，
# slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
# 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
# 通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
# 这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
# 一个是事件的类型，
# 一个是事件的描述。
# 如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，
# 否则sentinel无法正常启动成功。
# 通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

Redis缓存穿透和雪崩

  • Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存
  • 另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案

缓存穿透 (查不到导致的)

概念

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透

解决方案

  • 布隆过滤器

    • 布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力
      在这里插入图片描述

  • 缓存空对象

    • 当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源
      在这里插入图片描述
    • 但是这种方法会存在两个问题：
    1. 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键
    2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响

缓存击穿 (缓存过期导致的)

概念
  • 这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞
  • 当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大
解决方案
  • 设置热点数据永不过期
    • 从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题
  • 加互斥锁
    • 分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大

缓存雪崩 (集中过期导致的)

概念

  • 缓存雪崩，是指在某一个时间段，缓存集中过期失效，或者Redis宕机

  • 产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况
    在这里插入图片描述

  • 其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮

解决方案
  • redis高可用
    • 既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群
  • 限流降级
    • 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待
  • 数据预热
    • 在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀
Done++
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Redis --- 哨兵、分片集群
乌云的博客
05-05 847
Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。
Redis（十四）：进阶篇 - 哨兵
HY0101的博客
07-02 273
哨兵   在Reids的复制一文以介绍已经介绍了复制的原理和使用方式，在一个典型的一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。   为此，Redis2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。 1、什么是哨兵   顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个
Redis-01.初识Redis
Snakewood的博客
05-26 185
NoSQL SQL和NoSQL的区别 SQL NoSQL 数据结构 结构化 非结构化（键值、文档、列、图等）结构比较松散 数据关联 关联的 无关联的 查询方式 SQL查询 非SQL 事务特性 ACID BASE 存储方式 磁盘 内存 扩展性 垂直 水平 使用场景 1）数据结构固定2）对数据安全性、一致性要求较高 1）数据结构不固定2）对一致性、安全性要求不高3）对性能要求 Redis 特征： 键值型，value支持多种不同的数据结构 单线程，每个命令具有原子性
【Redis-6.0.8】初识Redis
Edidaughter的博客
11-18 470
1.什么是Redis Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网 络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起， Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。 2.如何 ...
初识Redis-1-NoSQL与Redis
Done++的博客
06-13 507
文章目录Nosql概述为什么要用Nosql什么是NoSQLNoSQL特点NoSQL的四大分类KV键值对文档型数据库列存储图关系数据库四者对比Redis入门概述安装Windows安装Linux安装正常安装docker安装测试性能基础知识五大数据类型String (字符串)List (列表)Set (集合)Hash (哈希)Zset (有序集合)三种特殊数据类型geospatial (地理位置)hyperloglogbitmap Nosql概述 为什么要用Nosql 我们正处于大数据时代。对于大数据，一般的
Redis（6）-----初识Redis-----集群原理及搭建
weixin_34038652的博客
11-13 165
假如你现在还在为自己的技术担忧，假如你现在想提升自己的工资，假如你想在职场上获得更多的话语权，假如你想顺利的度过35岁这个魔咒，假如你想体验BAT的工作环境，那么现在请我们一起开启提升技术之旅吧，详情请点击http://106.12.206.16:8080/qingruihappy/index.html 一，集群原理 1.1，redis-cluster架构图     1.2.架构细节...
初识redis-cluster
weixin_30855099的博客
10-27 120
安装redis 1 [root@localhost ~]# cd /datas/soft/ 2 [root@localhost soft]# ll redis-5.0.0.tar.gz // 已经下载的最新版 3 -rwxrwxrwx 1 www www 1947721 Oct 22 14:21 redis-5.0.0.tar.gz 4 [root@localhost ...
微服务---分布式缓存redis进阶-redis集群部署
爪蛙毁一生的博客
05-03 996
基于Redis集群解决单机Redis存在的问题。
Redis（7）-----初识Redis-----客户端对Redis集群的使用方法
weixin_33721427的博客
11-13 120
假如你现在还在为自己的技术担忧，假如你现在想提升自己的工资，假如你想在职场上获得更多的话语权，假如你想顺利的度过35岁这个魔咒，假如你想体验BAT的工作环境，那么现在请我们一起开启提升技术之旅吧，详情请点击http://106.12.206.16:8080/qingruihappy/index.html 记得链接之前关闭防火墙，或者把本端口号添加到防火墙例外 [root@localhost...
Redis --- 基础篇
shuai_h的博客
12-18 599
Redis基础
Redis入门到进阶系列-1 Redis 初识：介绍 Redis 及其应用场景
weixin_41974725的博客
05-10 310
Redis 作为一款高性能的内存数据库，提供了灵活的数据类型支持和丰富的应用场景。了解 Redis 及其应用场景将帮助我们在实际开发过程中，针对不同场景选择合适的解决方案，提高系统的性能和可靠性。
开发知识点-LBS用户位置Redis-GEO附近人/店铺
aming小老弟
10-17 626
【代码】解决方案-用户位置GEO附近人/店铺。
redis---分布式锁存在的问题及解决方案（Redisson）
m0_61083409的博客
08-02 2896
初识分布式锁大多数人都是从setNx命令开始的，我们很轻易的就可以借助setNx命令及redis的特性创建一个简陋的分布式锁。释放锁时只需要直接删除即可。存在问题：上述只是列出的一小部分问题，实际还存在很多漏洞没有展示出来。我们循序渐进一点一点啃先解决以上几个问题。对于出现异常锁无法释放问题，我们很容易可以想到能够通过设置一个过期时间来进行处理。比如像订单30分钟未支付默认放弃此订单这样。这里采用常规的SETNX + EXPIRE 为两个单独的命令会缺乏原子性，想象一下如果加锁成功但是客户端节点在执行EXP
Redis 常用命令总结
weixin_73869209的博客
09-05 935
以上就是这篇博客的主要内容了,大家多多理解,下一篇博客见!
Redis
最新发布
weixin_45939821的博客
09-10 169
〇、redis的几种数据类型 一、两种储存机制：RDB和AOF RDB： rdb是redis默认的存储机制； 触发规则后将内存数据存储到硬盘的dump.rdb文件中: save 900 1 save 300 10
Redis 实现原理或机制
Flying_Fish_roe的博客
09-07 1121
Redis 的高性能、高可用性和灵活性来自其精巧的实现原理和机制。通过高效的内存管理、灵活的数据结构、强大的持久化机制、主从复制和集群功能，Redis 能够满足各种复杂的应用场景需求。无论是在缓存、会话管理、还是分布式存储领域，Redis 都能够提供卓越的性能和稳定性。
基于 Redis 的分布式锁实现原理及步骤
weixin_62371118的博客
09-05 1091
实现分布式锁的目的是在分布式系统中，保证多个节点之间对共享资源的并发访问是互斥的。常用的分布式锁实现方式有以下几种：基于数据库、基于 Redis、基于 Zookeeper。下面详细介绍基于 Redis 的分布式锁实现原理及步骤。
Spring Boot 集成 Redisson 实现消息队列
大橘的博客
09-10 340
【代码】Spring Boot基于Redisson的RBlockingQueue实现简单的消息队列，适用于简单队列应用。有普通队列与延迟队列实现。
Redis演进与Redis-Cluster集群读写策略
- Redis-cluster是官方提供的分布式集群解决方案，它将数据分布于多个节点，实现了数据分区和容错。每个节点都包含一部分键空间，且能处理对这些键的操作。官方默认不推荐在cluster中进行读写分离，因为每个节点都...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值