Redis1

内存

命令：

info memory

配置分析：

# Memory
used_memory:2587328
free_memory:4949498790
used_memory_human:2.47M
used_memory_rss:120233984
used_memory_peak:642276608
used_memory_peak_human:612.52M
used_memory_lua:36864
mem_fragmentation_ratio:46.47
mem_allocator:jemalloc-3.6.0

• used_memory
  Redis分配器分配的内存总量（单位是字节），包括使用的虚拟内存（即swap）
• used_memory_rss
  Redis进程占据操作系统的内存（单位是字节），与top及ps命令看到的值是一致的
• mem_fragmentation_ratio
  内存碎片比率，该值是used_memory_rss / used_memory的比值

if (ratio > 1) {
	// 内存碎片比例越大，浪费严重
	// 对于jemalloc来说，1.03比较健康
} else if (ratio < 1) {
	// 说明Redis使用了虚拟内存，由于虚拟内存的媒介是磁盘，比内存速度要慢很多，当这种情况出现时，应该及时排查，如果内存不足应该及时处理，如增加Redis节点、增加Redis服务器的内存、优化应用等
} else {
	// =1
}

• mem_allocator
  Redis使用的内存分配器，在编译时指定；可以是 libc 、jemalloc或者tcmalloc，默认是jemalloc

持久化（单机备份问题）

命令

info persittence

配置分析

loading:0
rdb_changes_since_last_save:190029650
rdb_bgsave_in_progress:0
rdb_last_save_time:1526278587
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

• rdb_last_bgsave_status:上次bgsave 执行结果，可以用于发现bgsave错误
• rdb_last_bgsave_time_sec:上次bgsave执行时间（单位是s），可以用于发现bgsave是否耗时过长
• aof_enabled:AOF是否开启
• aof_last_rewrite_time_sec: 上次文件重写执行时间（单位是s），可以用于发现文件重写是否耗时过长
• aof_last_bgrewrite_status: 上次bgrewrite执行结果，可以用于发现bgrewrite错误
• aof_buffer_length和aof_rewrite_buffer_length:aof缓存区大小和aof重写缓冲区大小
• aof_delayed_fsync:AOF追加阻塞情况的统计

RDB

手动触发保存RDB文件命令

# 会阻塞Redis服务器进程，直到RDB文件创建完毕为止，不推荐
save 
# 后台生成线程保存数据
bgsave

配置自动触发

# redis.conf
# 当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 900 1
save 300 10
save 60 10000

原理

每隔100ms，执行serverCron函数；在serverCron函数中，遍历save m n配置的保存条件，只要有一个条件满足，就进行bgsave。对于每一个save m n条件，只有下面两条同时满足时才算满足：
（1）当前时间-lastsave > m
（2）dirty >= n

其他场景触发：

• 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点
• 执行shutdown命令时，自动执行rdb持久化，如下图所示：

RDB文件分析

分析工具：

案例：使用内存过高问题分析
问题：redis作为缓存使用时，查询DB不存在时，value设置为empty，防止数据库穿透，发现短时间内存使用较高
分析：大量不存在的数据并发，导致empty的key剧增
方案：对于不存在的数据，适当减少key的生存时间

AOF

RDB持久化是将进程数据写入文件，而AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中（有点像MySQL的binlog）；当Redis重启时再次执行AOF文件中的命令来恢复数据。

与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案

配置

原理

主动复制（多机热备）

命令

info Replication

主要作用

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

搭建

从节点配置主节点的ip+port，通过slaveof异步命令，从节点完成主节点ip和port的保存后，向发送slaveof命令的客户端直接返回OK，实际的复制操作在这之后才开始进行。

功能演示

原理

时序图

接建立阶段、数据同步阶段、命令传播阶段

总结

哨兵

Redis Sentinel，主节点故障恢复的自动化

• 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
• 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

搭建

功能演示

原理

总结

1. 哨兵节点的数量应不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。
2. 哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。
3. 各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用ntp或类似服务，保证时间准确、一致。各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用ntp或类似服务，保证时间准确、一致。
4. 哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。
5. 当哨兵系统中的节点在docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而docker的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的IP和port，如果某个哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣称的port无法连接到A。当哨兵系统中的节点在docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而docker的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的IP和port，如果某个哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣称的port无法连接到A。

参考：
《Redis设计与实现》
《Redis开发与运维》
《Redis实战》