redis-数据安全性

性能压测脚本

Redis提供了压测脚本redis-benchmark，可以对Redis进⾏快速的基准测试。

# 20个线程，100W个请求，测试redis的set指令(写数据)redis-benchmark-a123qweasd-tset-n1000000-c20

Redis数据持久化机制

持久化策略
1、⽆持久化：完全关闭数据持久化，不保证数据安全。相当于将Redis完全当做缓存来⽤
2、RDB(RedisDatabase)：按照⼀定的时间间隔缓存Redis所有数据快照。
3、AOF(Append Only File)：记录Redis收到的每⼀次写操作。这样可以通过操作重演的⽅式恢复Redis的数据
4、RDB+AOF：同时保存Redis的数据和操作。

使⽤建议

1：如果你只是把Redis当做⼀个缓存来⽤，可以直接关闭持久化。 2、如果你更关注数据安全性，并且可以接受服务异常宕机时的⼩部分数据损失，那么可以简单的使⽤RDB策略。这样性能是⽐较⾼的。 3、不建议单独使⽤AOF。RDB配合AOF，可以让数据恢复的过程更快。

RDB

**功能：**在指定时间间隔内，将内存中的数据集快照写入磁盘文件。通常时dump.rdb二进制⽂件。

作用：rdb文件存储全量数据可以用来进行数据恢复，或同步到另一台redis服务器。

配置：
1> save 策略： 核⼼配置
2> dir ⽂件⽬录
3> dbfilename ⽂件名 默认dump.rdb
4> rdbcompression 是否启⽤RDB压缩，默认yes。
5> stop-writes-oin-bgsave-error 默认yes。
6>rdbchecksum 默认yes。

何时会触发RDB备份
1> 到达配置⽂件中默认的快照配置时
2>⼿动执⾏save或者bgsave指令时，save⽅法会阻塞主线程，bgsave会占用更多内存与cpu。
3、主从复制时会触发RDB备份。

LASTSAVE指令查看最后⼀次成功执⾏快照的时间。
文件修复命令：redis-check-rdb

优点

1、RDB⽂件⾮常紧凑，⾮常适合定期备份数据。 2、RDB快照⾮常适合灾难恢复。 3、RDB备份时性能⾮常快，对主线程的性能⼏乎没有影响。RDB备份时，主线程只需要启动⼀个负责数据备份的⼦线程即可。所有的备份⼯作都由⼦线程完成，这对主线程的IO性能⼏乎没有影响。 4.与AOF相⽐，RDB在进⾏⼤数据量重启时会快很多。

缺点：

1、RDB不能对数据进⾏实时备份，所以，总会有数据丢失的可能。 2、RDB需要fork化⼦线程的数据写⼊情况，在fork的过程中，需要将内存中的数据克隆⼀份。如果数据量太⼤，或者CPU性能不是很好，RDB⽅式就容易造成Redis短暂的服务停⽤。相⽐之下，AOF也需要进⾏持久化，但频率较低。并且你可以调整⽇志重写的频率。

AOF

**功能：**将每条写命令以追加的方式写入日志文件（文本文件），读操作不记录。

配置
1> appendonly 是否开启aof。 默认是不开启的。
2> appendfilename ⽂件名称。
3> appendfsync 同步⽅式 。默认everysecond 每秒记录⼀次。
4> appenddirname AOF⽂件⽬录。新增参数，指定aof⽇志的⽂件⽬录
5> auto-aof-rewrite-percentage, auto-aof-rewrite-min-size ⽂件重写触发策略。默认每个⽂件64M， 写到100%，进⾏⼀次重写。
6> no-appendfsync-on-rewrite aof重写期间是否同步

同步⽅式

everysecond ：每秒记录⼀次。 no :不记录(交由操作系统进⾏内存刷盘)。 always :记录每次操作，数据更安全，但性能较低。

redis7文件类型
在Redis7之前的版本中，aof⽂件也会包含⼆进制的RDB部分和⽂本的AOF部分。在Redis7中，将这两部分分成了单独的⽂件，这样，即可以分别⽤来恢复⽂件，也便于控制AOF⽂件的⼤⼩。

base.rdb：RDB 格式全量快照，⽂件即⼆进制的数据⽂件。 incr.aof：是增量的操作⽇志，AOF 格式命令。 manifest ：则是记录⽂件信息的元⽂件。

优点

1、AOF持久化更安全。例如Redis默认每秒进⾏⼀次AOF写⼊，这样，即使服务崩溃，最多损失⼀秒的操作。 2、AOF的记录⽅式是在之前基础上每次追加新的操作。因此AOF不会出现记录不完整的情况。即使因为⼀些特殊原因，造成⼀个操作没有记录完整，也可以使⽤redis-check-aof⼯具轻松恢复。 3、当AOF⽂件太⼤时，Redis会⾃动切换新的⽇志⽂件。这样就可以防⽌单个⽂件太⼤的问题。 4、AOF记录操作的⽅式⾮常简单易懂，你可以很轻松的⾃⾏调整⽇志。⽐如，如果你错误的执⾏了⼀次 FLUSHALL 操作，将数据误删除了。使⽤AOF，你可以简单的将⽇志中最后⼀条FLUSHALL指令删掉，然后重启数据库，就可以恢复所有数据。

缺点：

1、针对同样的数据集，AOF⽂件通常⽐RDB⽂件更⼤。 2、在写操作频繁的情况下，AOF备份的性能通常⽐RDB更慢。

混合持久化策略

同时打开RDB和AOF两种持久化策略参数： aof-use-rdb-preamble yes

结合了 RDB 和 AOF 的优点。它在 AOF 重写时，将当前内存数据以 RDB 格式写入 AOF 文件开头，后续的增量命令以 AOF 格式追加。 redis 7.0 混合持久化通过 RDB 快照保恢复速度、AOF 增量保数据安全、Multi-Part AOF 降重写开销，是性能与安全的最佳平衡。代价是牺牲文件可读性和增加修复难度。manifest 和 base.rdb 必须纳入备份策略，其重要性等同于数据文件本身

Redis的持久化策略只能保证单机的数据安全。如果服务器的磁盘坏了，那么再好的持久化策略也⽆法保证数据安全。如果希望进⼀步保证数据安全，那就需要增加以下⼏种集群化的⽅案了

redis分布式部署方案

主从复制 哨兵集群 redis集群

Redis主从复制

Replica是什么：使用 replicaof 命令使一个 Redis 实例成为另一个实例的副本

主从复制：将redis主节点（Master）服务器的数据，复制到redis从节点（slave）服务器。

特点：数据是单向复制的，只能从主节点复制到从节点。默认从库为只读节点，不允许写数据。一个主节点可以设置多个从节点，一个从节点只能有一个主节点。

作用

数据备份：每个从库都是一份完整的热数据副本，任一从库都可以随时切换为主库。 故障恢复：主节点宕机后，可以由从节点继续提供服务。但需要手动设置。 负载均衡：支持读写分离，主节点负责写服务，从节点负责读服务。 高可用基础：为后续哨兵、集群的实现提供基础

缺点

数据延时：所有操作在master节点执行，然后同步至slave,当出现从库负载高、网络延时等问题时，主从数据同步会延时。增加slave节点数量加大数据延迟。 无法自动主备切换：如果master宕机，slave节点不会自动切换为master,需要人工干预。 从数据安全性的⻆度，主从复制牺牲了服务⾼可⽤，但是增加了数据安全。

如果配置同步前Slave上已经有数据了，主从同步后slave的数据会被master覆盖。

主从复制⼯作流程

主从复制主要用于数据的冗余与读分担，并没有提高系统高可用性

哨兵集群Sentinel机制

Sentinel是什么？有什么作用

Sentinel是运行在redis集群中的特殊实例，不负责存储数据，负责监控，通知，故障转移，配置中心。实现⾃动故障恢复，提高系统可⽤性以及性能。 作用： -主从监控：检查主库从库是否运行正常，及时发现是否出现故障 -消息通知：当监控到有问题会通知给客户端。 -故障转移：主库宕机后会自动将从库提升为主库，并通知其他从节点。 -配置中心：应用可以通过sentinel动态感知并切换redis连接地址。

⼯作原理

通过独立的sentinel集群监控主从节点，自动发现故障并完成故障转移。

如何发现master服务宕机

主观下线：所有sentinel节点会不断向master服务发送心跳，master收到后响应。如果一段时间内没有收到master的相应，则sentinel节点主观认为master下线了（主观下线S_DOWN）。

客观下线：sentinel节点会寻求其他节点对主节点的判断，如果超过半数sentinel节点认为master下线了，则认为master下线（客观下线O_DOWN），然后开始故障切换。

故障切换过程

过程1：master下线后，sentinel集群选出一个节点作为领导者（Leader）负责协调选举过程。
过程2：sentinel在剩余的健康节点选举一个从节点作为master。

选举规则： 1：首先检查是否配置优先节点。redis.config中replica-priority配置最低的从节点，默认100. 2：找同步数据最快的salve节点。 3：按照slave的RunId字典顺序最小的节点。

过程3：切换新的主节点。Leader给新的mater节点执⾏ slave of no one操作，将他提升为master节点。 然后给其他slave发送 slave of 指令。让其他slave成为新Master的slave。
过程4：旧master恢复，降级为salve，并从新master同步数据。

Raft 分布式共识算法

在多个节点组成的集群中，确保大家对某个结果（或哪个节点是Leader）达成一致。

缺点

1:对客户端不太友好：master切换时，客户端写请求也要切换。 2:数据不安全：所有数据以master为主，当master宕机后，在mster已经完成的但没有同步到slave的数据会丢失。因为master切换后，所有数据以新master为准，旧master恢复后也会直接同步新master数据。⽹络异常时，如果此时主节点继续处理写操作，那么在⽹络恢复之前，这些操作可能不会被复制到从节点。

Redis集群Cluster

1、Cluster是什么？有什么⽤？

将多组Redis Replica主从集群整合到⼀起，像⼀个Redis服务⼀样对外提供服务。所以Redis Cluster的核⼼依然是Replica复制集。

Cluster核⼼要解决的问题：
1：客户端需要频繁切换master的问题。
2：服务端数据量太⼤后，单个复制集难以承担的问题。
3：master节点挂了之后，主动将slave切换成master，保证服务稳定

优点：
1：去中心化：解决客户端需要频繁切换master的问题
2：容量水平扩展，数据自动分片到多个节点，容量随节点增加线性扩展
3：读写请求分散到多个节点，提升QPS（读写分离，写仍串行）
4：规避单点故障风险，主从复制+自动故障转移

Slot槽位

Slot分配
Redis集群中内置16384个槽位。
在建⽴集群时，Redis会根据集群节点数量，将这些槽位尽量平均的分配到各个节点上。
并且，如果集群中的节点数量发⽣了变化。(增加了节点或者减少了节点)。就需要触发⼀次reshard，重新分配槽位。⽽槽位中对应的key，也会随着进⾏数据迁移。

如何确定key与slot的对应关系？

写⼊key时，使用计算⽅式 CRC16(key) mod16384 计算寻找所属的槽位。

Redis中计算槽位指令CLUSTER KEYSLOT

127.0.0.1:6381>CLUSTER KEYSLOT k1(integer)12706

如果请求涉及多个 Key 且不在同一 Slot，需要使用 {} 强制 hash tag，否则无法批量操作。

hashtag的使用
使⽤相同的hash tag，能保证这些数据保存在同⼀个节点上。
使用方式：根据key中⼤括号{}中的hash tag来计算槽位。

127.0.0.1:6381>mset user_{1}_name roy user_{1}_id1user_{1}_password123->Redirected to slot[9842]located at192.168.65.214:6382 OK

数据倾斜
现象：⼤量的数据被集中存储到了集群中某⼀个热点Redis节点上，从⽽造成这⼀个节点的负载明显⼤于其他节点。
影响：资源浪费
解决思路：
1：调整key的结构，尤其是那些访问频繁的热点key，让数据能够尽量平均的分配到各个slot上。
2：调整slot的分布，将那些数据量多，访问频繁的热点slot进⾏重新调配，让他们尽量平均的分配到不同的Redis节点上。

Redis集群能不能保证数据安全？
⾸先，在Redis集群相对⽐较稳定的时候，Redis集群是能够保证数据安全的。Redis集群中每个master都是可以配置slave从节点的。这些slave节点会即时备份master的数据。在master宕机时，slave会⾃动切换成master，继续提供服务。
由于Redis集群的gossip协议在同步元数据时不保证强⼀致性，这意味着在特定的条件下，Redis集群可能会丢掉⼀些被系统收到的写⼊请求命令。⽐如⽹络抖动产⽣的脑裂问题。