Redis高级运用之持久化配置策略与运维优化-爱代码爱编程
一、 Redis的特性
-
性能高
Redis能读的速度是10W+次/s,写的速度是8W+次/s 。
-
丰富的数据类型
Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
-
操作原子性
Redis的所有操作都是原子性的,Redis还支持对几个操作全并后的原子性执行。
-
功能丰富
支持 publish/subscribe, lua脚本、事务、pipeline、 通知、 key 过期等等特性。
-
支持多种编程语言
java,python、PHP、C、C++等等。
-
持久化
Redis支持两种方式的持久化,即将数据写入磁盘的方法,RDB(Redis DataBase)和AOF(Append Only File)。
-
主从复制
Redis支持主从复制功能,主节点中断,可以进行主从切换, 不影响客户端的使用。
-
高可用与分布式
Redis从2.8版本后,支持Redis Sentinel,即“哨兵模式”,保障Redis节点的故障发现与自动转移; 还可以支持集群模式(3.0版本),实现分布式存储与水平扩展。
二、 Redis的数据结构
Redis包含5种基本数据结构,4种高级数据结构。
-
5种基本数据结构
- string
- list
- hash
- set
- sorted set
-
4种高级数据结构
- hyperloglog
- geo
- bitmap/bloomfilter
- stream
三、 Redis的启动与管理工具
-
Redis三种启动方式
- 直接启动
- 配置文件启动
- 动态参数启动
验证方式: 1. ps -ef | grep redis 2. netstat -apn | grep 端口 3. redis-cli -h ip -p port -a password ping
-
Redis的管理工具介绍
- redis-server : 启动管理Redis服务。
- redis-cli: redis的命令行工具。
- redis-benchmark: redis性能基准测试工具。
- redis-check-aof: aof数据文件检查修复工具。
- redis-check-dump: rdb数据文件检查修复工具。
- redis-sentinel: 启动管理redis哨兵服务。
-
Redis 常用配置
-
port : 端口
-
dir : 数据文件存放路径
-
logfile: 日志文件存放路径
-
daemonize: 守护进程方式启动
-
四、 Redis的持久化配置策略
Ⅰ. RDB(Redis Database)
-
覆盖式更新, 新文件替换就的RDB文件
-
效率: 内容越大, 效率越低, o(n)
-
操作方式对比:
命令 save bgsave IO类型 同步 异步 是否阻塞 是 是 复杂度 O(n) O(n) 优势 不会消耗额外内存 不阻塞客户端命令 缺陷 阻塞式 需要fork子进程,消耗内存 -
自动生成RDB策略
save 900 1 900秒内执行一次set操作 则持久化1次 save 300 10 300秒内执行10次set操作,则持久化1次 save 60 10000 60秒内执行10000次set操作,则持久化1次
注意事项:
1) save 自动配置满足任一项就会执行,数据量大情况下会阻塞Redis。
2) bgsave不会阻塞Redis, 但是会fork产生新进程。
3) rdb方式存储, 会有数据丢失的可能。
Ⅱ. AOF (Append Only File)
-
采用日志的形式来记录每个写操作,并追加到文件中。
-
aof的三种策略
1) always
每条命令都回fsync到磁盘。
2)everysec(默认)
每秒把缓冲区fsync到磁盘。
3)no
由os操作系统决定fsync到磁盘。
命令 always everysec no 优势 不丢失数据 每秒一次fsync 无需配置 缺陷 io开销过大,一般磁盘只有几百iops 丢失1秒数据 不可控 appendonly yes # 开启AOF模式 appendfilename "appendonly-6379.aof" # AOF文件名称 appendfsync everysec # aof策略模式 dir /data # 数据文件保存目录 no-appendfsync-on-rewrite yes # 在子进程重写的时候,主进程的写操作记录是否追加 (yes为不追加,保存在缓冲区,有可能会造成数据丢失,最多30秒数据; no为追加, 但可能会产生阻塞)
Ⅲ. RDB vs AOF
-
综合对比
模式 RDB AOF 启动效率 低 高 体积 小 大 恢复速度 快 慢 数据安全性 易丢失数据 安全性高(由策略决定) 备份模式 全量备份 增量备份 运行缺陷 无 可能存在 -
混合持久化
混合持久化可以弥补AOF方式的不足,采用混合持久化,重写后的新 AOF 文件前半段是 RDB 格式的全量数据,后半段是 AOF的增量数据,达到更快的重写和恢复效果,混合持久化的开关为aof-use-rdb-preamble。
五、 Redis的持久化运维问题
-
fork问题
fork执行过程中,父进程需要拷贝内存页表给子进程,如果内存占用很大,那么拷贝的内存页表会比较耗时, 整个实例会被阻塞。
解决:
1)优先使用物理机或采用高效支持fork操作的虚拟化技术。
2) 控制Redis的示例最大可用内存: maxmemory。
3)合理配置Linux内存分配策略: vm.overcommit_memory = 1。
4)降低fork频率: 例如放宽AOF重写自动触发时机, 不必要的全量复制。
-
子进程的开销与优化
1)CPU开销
RDB与AOF文件的操作, 属于CPU密集型,会产生较大的开销。
优化:
不做CPU核数绑定,不和CPU密集型应用部署。
2) 内存开销
fork会产生内存开销,在写入时会产生副本(COPY-ON-WRITE)。
优化:
关闭THP(RHEL6的特性, 系统会产生一个khugepaged进程, 把使用较小的页面换到hugepage中,会占用较多的内存)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
3) 硬盘开销
AOF更新和RDB文件的写入都会带来较多的磁盘开销
优化:
-
采用企业级SSD提升磁盘吞吐能力, 可以通过iostat,iotop或dstat工具监控磁盘是否产生瓶颈。
-
如果单机部署多实例, 可以考虑分盘存储。
4) AOF阻塞
定位方法:
1)通过Redis日志定位:
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis
2)通过终端指令定位:
>info persistence ... aof_delayed_fsync:200 ...
该指令为累积耗时, 出现问题时, 需要记录上一次的耗时做对比。
优化:
1) 将appendfsync策略改为everysec每秒进行一次刷新。
2) 如果数据量比较大, 采用集群部署模式, 分散节点压力。
-