Redis分布式缓存

最新推荐文章于 2025-09-09 16:06:57 发布

原创最新推荐文章于 2025-09-09 16:06:57 发布 · 375 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis

Redis 专栏收录该内容

1 篇文章

订阅专栏

本文详细介绍了Redis的高性能特性，包括TPS、RT和QPS等指标，以及如何通过读写分离提升性能。在主从复制中，探讨了RDB和AOF两种持久化策略的优缺点。进一步讲解了Sentinel系统实现的高可用性，包括主观下线和客观下线的概念，以及自动故障转移的流程。最后，提到了Redis内置的Cluster集群和数据分布策略，以及事务、数据结构的应用场景和Redis在实际业务中的常见用途。

1.Redis读写分离

1.1Redis性能

TPS（吞吐量）

系统在单位时间内处理请求的数量

RT（响应时间）

系统对请求作出响应的时间。在讨论一个系统的响应时间时，一般指系统所有功能的平均时间或者所有功能的最大响应时间

QPS（每秒查询率）

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，即最大吞吐量

1.2Redis读写分离

本机redis性能测试QPS为17万，而一些大型项目需要千万级别的QPS，这时需要采用读写分离突破性能瓶颈。通过运行新的服务器

（从服务器）连接主服务器，然后主服务器发送数据副本给从服务器，这样就有新的服务器处理读请求。通过读写分离，用户将有新的服务器专门处理读请求，提高了redis性能。

1.3Redis同步原理

主从复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称作数据库状态一致。

Redis持久化方式有两种：

RDB全量持久化
- 是什么？
  - 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
  - RDB保存的是dump.RDB文件，持久化过程中新的文件会替换旧的文件
- 优势
  - 相对于aof，在恢复大规模数据时更加高效
  - 对于数据的完整性不是非常敏感
- 劣势
  - rdb是间隔一段时间做一次备份，所以如果redis意外宕机，就会丢失最后一次快照后的所有修改
  - 内存的数据在被克隆时，大概会有两倍的膨胀性，需要考虑
- 如何触发设置rdb快照
  - save 900 1 ----含义为redis900s内有一个key发生改变就会触发rdb
- 如何恢复
  - 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
- 如何停止rdb
  - 在redis.conf文件中设置 save " "
AOF增量持久化
- 是什么
  - 以日志的形式记录每个写操作(读操作不记录),只许追加文件，但不可以改写文件。redis重启的话就根据日志的内容将指令从前往后执行一次，以完成数据的恢复工作
- 保存文件格式
  - appendonly.aof
- 如何启动文件
  - 修改默认的appendonly no,改为yes
- 重写
  - aof采用的是文件追加的方式，文件会越来越大，当文件超过设定的阈值时，redis就会将内容压缩
- 优势
  - 每次发生数据变更会被立即记录到磁盘性能较差但数据完整性比较好
- 劣势
  - 相同数据而言aof的文件要远大于rdb，恢复速度要慢于rdb，效率低于rdb
总结
- 如果数据只在服务器运行时存在，可以不适用任何的持久化方式
- 当两种持久化方式都开启时，redis会优先载入AOF文件来恢复数据，因为通常情况下aof文件的数据完整性要优于rdb

数据同步步骤

旧版本使用SYNC，完整重同步非常耗费资源
新版本使用PSYNC，使用完整重同步和部分重同步，效率较高

2.Redis高可用Sentinel

2.1高可用介绍

高可用是分布式系统架构设计中非常重要的因素，高可用就是减少系统不可用的时间，高可用一般遵循以下几点：

避免单点故障。某个功能的实现不能只有一台服务器，否则出现故障整个系统就不可用
保证冗余。增加重复的部分，对数据库等有备份
保证自动故障转移。每次故障人工修复会增加不可用的时间，所以要实现自动故障转移

redis主从复制后将主节点的数据复制给从节点，从节点此时具有的功能有：

分担主节点的读写压力
主节点故障后，从节点可以代替主节点从而实现高可用

2.2手动主从切换

当主节点故障后，我们可通过手动主从切换让某一从节点成为主节点继续工作。其中需要手动修改配置文件和修改主从配置等，十分繁琐

2.3Sentinel实现高可用

2.3.1Sentinel介绍

哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵的三大工作任务：

监控：通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
提醒：当某个redis发生故障，哨兵可通过API通知管理员
自动故障转移：当主服务器失效时，sentinel会进行一次自动故障转移，sentinel会将主服务器的一个从服务器自动升级为主服务器，并且让失效主服务器的其他从服务器改为复制新的主服务器

自动故障转移的过程：

当哨兵1检测到有服务器宕机，仅仅哨兵1判断服务器宕机我们称之为主观下线。当有多于n个（n可以自己设置）哨兵判断服务器宕机，此时为客观下线，如果故障了根据投票数自动将从库转换为主库。

互联网冷备和热备

冷备

冷备发生在数据库完全关闭的情况下，备份快速安全，易于维护

热备

热备发生在数据库开启的情况下，难于维护

3.Redis内置集群（cluster）

3.1集群原理

原理：

1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
5、Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

哨兵与集群

哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存

集群，就是分布式存储。即每台redis存储不同的内容

Redis集群的主从复制模型

为了保证集群的高可用性，redis每个节点都有至少一个复制节点。
可实现读写分离、容灾恢复
复制原理
- 1.slave连接到master后会发送一个sync(全量复制)命令
- 2.master将传送整个数据到slave，以完成一次完全同步

Redis一致性保证

为了提高性能，主节点先回复命令再复制给从节点数据，这样有可能造成主从不一致情况，为了性能作出的必要取舍。

4.Redis集群扩展

4.1集群现状

很多公司在使用自己的redis高可用集群方案，并没有使用redis内置集群（上线较晚）
网络通讯问题。
数据迁移问题

5.redis事务

5.1是什么

可以一次执行多个命令，本质是一组命令的集合，一个事务中的所有命令都会被序列化，按照顺序执行，不允许加塞
redis事务是部分支持，不保证原子性，redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

5.2事务常用的命令

命令演示

5.3乐观锁与悲观锁

乐观锁
- 认为每次访问都不会修改数据，所以不会上锁，但是在更新时会判断其他人是否更新了数据，比如加入版本号
悲观锁
- 每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等7.Redis快的原因
redis数据存放在内存，直接操作内存比操作硬盘速度快很多
redis采用单线程，不用考虑各种锁的问题，不存在加锁解锁操作，不会因为死锁而导致的性能损耗
redis使用的多路IO复用，redis使用非阻塞IO

8.redis的数据结构相关，说说字典？

字符串
- redis是使用C语言开发，但C中并没有字符串类型，redis设计了一种简单动态字符串（数组）作为底层实现
列表（list）
- 底层由quicklist实现，整体上quicklist就是一个双向链表结构，和普通的链表操作一样，插入删除效率很高，但查询的效率却是O(n)。不过，这样的链表访问两端的元素的时间复杂度却是O(1)。所以，对list的操作多数都是poll和push。
哈希（hash）
- 底层由hashtable实现，和hashmap相同是由数组加链表，不过hashtable加了sychronized锁
集合(set)
- 集合则通过使用散列表（hashtable）来保证自已存储的每个字符串都是各不相同的(这些散列表只有键，但没有与键相关联的值)，redis中的集合是无序的
有序集合（zset）
- 底层由字典实现
- dict，又称字典(dictionary)或映射(map)，是集合的一种；这种集合中每个元素都是KV键值对。字典dict在各编程语言中都有体现，面向对象的编程语言如C++、Java中都称其为Map