文章目录
1. Redis 的数据类型
Redis 是典型的 Key-Value 型存储系统,所有数据类型都以 key 作为标识,总共可分为 5种 数据类型.当设置数据时 Nx(if not exist) 参数意味着如果 key 不存在则可以设置,可以用于实现分布式锁.
1.1 String
Redis中最基本的类型，它是key对应的一个单一值。二进制安全，不必担心由于编码等问题导致二进制数据变化。所以 redis 的String可以包含任何数据，比如jpg图片或者序列化的对象。Redis中一个字符串值的最大容量是512M。
使用方式为 set key value
1.2 List
List 是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）, 底层是基于链表实现的，所以它操作时头尾效率高，中间效率低。
使用方式为lpush key value
1.3 Set
唯一集合, 存储没有重复的的数据,是基于哈希表实现的。
使用方式为 sadd key value
1.4 Zset
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序, zset的成员是唯一的,但分数(score)却可以重复。
使用方式为 zadd key [score member]
1.5 Hash
类似于数据库中一条记录的结构, 主要记录结构化的信息.以 key 为主键, [field value]作为数据存储的单元.使用方式为 Hset
2. Redis 持久化机制
Redis 持久化机制主要分为 RDB 和 AOF 两种，当 Redis 重启时，系统会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整
2.1 RDB
2.1.1 RDB持久化
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储.
- 优点:
保存的是真实数据, 一旦出现灾难性故障可以较容易地恢复数据.另外BGSAVE是fork出子进程完成持久化的工作, 这样就可以极大的避免服务进程执行IO操作,提高性能.在服务启动时, 数据较大的话RDB的启动效率较高. - 缺点:
系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失.
2.1.2 RDB持久化配置
配置文件 *.conf 中可进行相关配置,默认开启.
| 配置 | 作用 |
|---|---|
| save 900 1 | 在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照 |
| save 300 10 | 在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照 |
| save 60 10000 | 在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照 |
2.2 AOF
2.2.1 AOF持久化
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录.
- 优点:
append模式,写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容.对数据的修改基本可以做到同步记录,当 AOF 文件过大时通过AOF Rewrite机制可以压缩文件.
| 配置项 | 含义 |
|---|---|
| auto-aof-rewrite-percentage 100 | 文件体积增大100%时执行AOF重写 |
| auto-aof-rewrite-min-size 64mb | 文件体积增长到64mb时执行AOF重写 |
- 缺点:
相同数量的数据集AOF文件通常要大于RDB文件, 根据同步策略不同, AOF 可能比 RDB 慢.
2.2.2 AOF文件损坏问题
Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现问题，就会立即退出并给出相应的错误提示。此时可利用Redis工具包中提供的redis-check-aof工具，该工具能够帮助我们定位到数据不一致的错误。其工作机制是将文件中损坏点之后的部分切除，而不是把受损数据恢复。
2.2.3 AOF持久化配置
在Redis的配置文件中存在三种同步方式, 不过需要手动配置启动.
| 配置 | 作用 |
|---|---|
| appendfsync always | 每次有数据修改发生时都会写入AOF文件 |
| appendfsync everysec | 每秒钟同步一次，该策略为AOF的缺省策略 |
| appendfsync no | 从不同步,高效但是数据不会被持久化 |
3. Redis 主从复制
Redis 集群中通常把 Master 服务器作为写服务器, Slave服务器作为读服务器, Slave默认没有写数据权限. Master 服务器与Slave 服务器之间数据的同步就是主从复制.
主从复制过程:
- 如果设置了 Slave,无论是第一次连接还是重连到Master,它都会发出一个SYNC请求.
- Master收到SYNC请求之后，会做两件事：
1.Master执行BGSAVE，fork一个子进程，在后台保存数据到磁盘（rdb快照文件）.
2.Master将新收到的写入和修改数据集的命令(非查询类)存入缓冲区.- 当Master在后台把数据保存到快照文件完成之后,会把这个快照文件传送给Slave,而Slave则把数据清空后,加载该文件到内存中.
- Master也会把此前收集到缓冲区中的命令通过Reids命令协议形式转发给Slave,Slave执行这些命令，实现和Master的同步.
- Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致.
需要注意的是 Master 和 Slave 之间一旦发生重连都会引发全量同步操作, 但在2.8之后版本也可能是部分同步操作.
部分复制
- Redis 2.8 的这个部分重同步特性会用到一个新增的 PSYNC 内部命令，只要从服务器是 Redis 2.8 或以上的版本， 它就会根据主服务器的版本来决定到底是使用 PSYNC 还是 SYNC 。
- 2.8开始，当 Master 和 Slave 之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。
- Master端为复制流维护一个内存缓冲区(in-memory backlog)，记录最近发送的复制流命令;同时Master和Slave之间都维护一个复制偏移量(replication offset), Slave 还会保存当前Master服务器ID(Master run id)。
- 当Slave尝试重连时, 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会根据复制偏移量将 Slave 下线这段时间的所有命令发送给它执行，这样就完成了部分复制工作; 否则依然需要全量复制操作。
4. Redis 哨兵机制
Redis哨兵sentinel 主要用于监控集群中服务器的状态, 通过类似心跳检测的机制不断询问服务器状态, 在发现Master服务器挂了后就会从slave中重新选举一个Master服务器,以避免单点故障导致系统不可用的问题.
4.1 工作原理
- 哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况.
- 同时哨兵节点之间也互相通信，交换对主从节点的监控状况.
- 每隔1秒每个哨兵会向整个集群(Master主服务器+Slave从服务器+其他Sentinel进程) 发送一次ping命令做心跳检测.如果一个节点距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel（哨兵）进程标记为主观下线(SDOWN).
哨兵用来判断节点是否正常的重要依据涉及两个概念：主观下线和客观下线.
- 主观下线(sdown)：一个哨兵节点判定节点down掉是主观下线.
- 客观下线(odown)：判定节点主观下线的哨兵节点数量达到配置的值，此时判定节点客观下线.
基本上哪个哨兵节点最先判断出主节点客观下线，就会在各个哨兵节点中发起投票机制 Raft 算法(选举算法),最终 1.被投为领导者的哨兵节点 完成 2.主从自动化切换的过程.
4.2 哨兵集群选举Leader
如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
- 每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。
- 如果一个Sentinel节点获得的选举票数达到指定票数(Sentinel节点数/2+1 与判定客观下线所需的哨兵节点数的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。
4.3 Redis 主从自动化切换
当哨兵集群选举出Leader后，由Sentinel Leader从redis从节点中选择一个作为主节点：
- 过滤故障的节点
- 选择优先级slave-priority最大的从节点作为主节点，如不存在则继续
- 选择复制偏移量最大的从节点（复制偏移量：数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从节点的偏移量一致，则数据是完全同步）作为主节点，如不存在则继续
- 选择runid 最小的从节点（redis每次启动的时候生成随机的runid作为redis的标识）作为主节点
5. Redis 内存淘汰策略
Redis内存使用超过一定值的时候可采用以下策略淘汰数据：
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰volatile-lfu: 从所有设置了过期时间的键中驱逐使用频率最少的键allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰noeviction：禁止驱逐数据，当内存使用达到阈值的时候，所有引起申请内存的命令会报错allkeys-lfu:从所有键中驱逐使用频率最少的键
- 设置方式
config set maxmemory-policy volatile-lru
扫一扫
934
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
