复制简介 P61
关系型数据库通常会使用一个主服务器 (master) 向多个从服务器 (slave) 发送更新,并使用从服务器来处理所有读请求。 Redis
也采用了同样的方法实现自己的复制特性,并将其用作扩展性能的一种手段。 P69
在接收到主服务器发送的数据初始副本 (initial copy of the data) 之后,客户端每次向主服务器进行写入时,从服务器都会实时地得到更新。 P69
复制 P62
对于一个正在运行的 Redis
服务器,用户可以通过发送 SLAVEOF NO ONE
命令来让服务器终止复制操作,不再接受主服务器的数据更新;也可以通过发送 SLAVEOF host port
命令来让服务器开始复制一个新的主服务器。 P69
配置选项
# 设置本机为指定服务器的从服务器
#
# slaveof <master-host> <master-port>
# 当主服务器设置了密码保护时(用 requirepass 指定的密码)
# 从服务器服务连接主服务器需要设置相应的密码
#
# masterauth <master-password>
# 当从服务器 与主服务器失去连接 或者 正在进行复制 时
# yes: 从服务器会继续响应客户端的请求(默认 yes)
# no: 除了 INFO 和 SLAVOF 命令之外的任何请求都会
# 返回一个错误 "SYNC with master in progress"
#
slave-serve-stale-data yes
# 从服务器每隔一定时间会向主服务器发送 ping
# 默认 10 秒
#
# repl-ping-slave-period 10
# ping 回复 或 主服务器批量数据传输 超时时长
# 默认 60 秒
# 确保 repl-timeout 大于 repl-ping-slave-period
#
# repl-timeout 60
从服务器连接主服务器时的步骤 P70
步骤 | 主服务器操作 | 从服务器操作 |
---|---|---|
1 | (等待命令进入) | 连接(或者重连)主服务器,发送 SYNC 命令 |
2 | 开始执行 BGSAVE ,并使用缓冲区记录 BGSAVE 之后执行所有写命令 |
根据配置选项 (slave-serve-stale-data ) 来决定是继续使用现有的数据(如果有的话)来处理客户端的命令请求,还是向客户端返回错误 |
3 | BGSAVE 执行完毕,向从服务器发送快照文件,并在发送期间继续使用缓冲区记录被执行的写命令 |
丢弃所有旧数据(如果有的话),开始载入主服务器发来的快照文件 |
4 | 快照文件发送完毕,开始向从服务器发送存储在缓冲区里面的写命令 | 完成对快照文件的解释操作,像往常一样开始接受命令请求 |
5 | 缓冲区存储的写命令发送完毕;从现在开始,每执行一个写命令,就向从服务器发送相同的写命令 | 执行主服务器发来的所有存储在缓冲区里面的写命令;并从现在开始,接受并执行主服务器传来的每个写命令 |
在实际中最好让主服务器只使用 50% ~ 65%
的内存,留下 30% ~ 45%
的内存用于执行 BGSAVE
命令和创建记录写命令的缓冲区。 P70
从服务器在进行同步时,会清空自己的所有数据。 P70
Redis
不支持主主复制 (master-master replication) P71
当一个从服务器连接一个已有的主服务器时,有时可以重用已有的快照文件: P71
- 步骤 3 尚未执行:所有从服务器都会接收到相同的快照文件和相同的缓冲区写命令
- 步骤 3 正在执行或已经执行完毕:当主服务器与比较早进行连接的从服务器执行完复制所需的 5 个步骤之后,主服务器会与新连接的从服务器执行一次新的步骤 1 至步骤 5
主从链 P71
Redis
的主服务器和从服务器没有什么特别不同的地方,所以从服务器也可以拥有自己的从服务器,并由此形成主从链 (master/slave chaining) 。 P71
不过,如果从服务器 X
拥有从服务器 Y
,那么当从服务器 X
在执行步骤 4 时,它将断开与从服务器 Y
的连接,导致从服务器 Y
需要重新连接并重新同步。 P71
当读请求比写请求重要,且读请求的数量远远超过一台 Redis
服务器可以处理的范围时,就需要添加新的从服务器来处理读请求。随着负载不断上升,主服务器可能会无法快速地更新所有从服务器,或者因为重新连接和重新同步从服务器而导致系统超载。为了缓解这个问题,可以创建一个由 Redis
主从节点 (master/slave node) 组成的中间层来分担主服务器的复制工作。 P71
通过同时使用复制和 AOF
持久化,用户可以增强 Redis
对于系统崩溃的抵抗能力。 P73
处理系统故障
验证快照文件和 AOF
文件
redis-check-aof [--fix] <file.aof>
可以检查 AOF
文件,并且可以进行修复:将第一个出错命令(大部分情况下在文件末尾)及之后的所有命令删除。 P74
redis-check-dump <dump.rdb>
可以检查快照文件。快照文件目前无法进行修复,因为快照文件本身进行了压缩。 P74
事务
Redis
事务的作用: P76
- 防止数据出错
- 在某些情况下提升性能。利用事务一次性发送多个命令,然后等待所有回复出现实现流水线 (pipeline)。通过减少客户端与
Redis
服务器之间的网络通信次数来提升Redis
在执行多个命令时的性能。
关系数据库事务与 Redis
事务的区别: P76
- 关系数据库:先向数据库服务器发送
BEGIN
,然后执行各个相互一致 (consistent) 的读写操作,最后可以选择发送COMMIT
来确认之前的修改,或者发送ROLLBACK
来放弃之前的修改。 Redis
:以特殊命令MULTI
开始,然后传入多个命令,最后以EXEC
结束,并依次执行传入的命令。Redis
事务不能以一致的形式读取数据,使得某一类型的问题难以解决,且无法实现二阶段提交。
通过使用 WATCH
, MULTI/EXEC
, UNWATCH/DISCARD
等命令,程序可以在执行某些重要操作时,通过确保自己正在使用的数据没有发生变化来避免出错。 P78
WATCH
: 使用WATCh
对键进行监视之后,直到用户执行EXEC
的这段时间里面,如果有其他客户端抢先对任何被监视的键进行了替换、更新或删除等操作,那么当用户尝试执行EXEC
时,事务将失败并返回一个错误。(之后用户可选择重试事务或者放弃事务)UNWATCH
: 可以在WATCH
执行之后、MULTI
执行之前对连接进行重置 (reset)DISCARD
: 可以在MULTI
执行之后、EXEC
执行之前对连接进行重置,即取消WATCH
并清空所有已入队命令
为什么 Redis
没有实现典型的加锁功能? P82
- 加锁是悲观锁,持有锁的客户端运行越慢,等待解锁的客户端被阻塞的时间越长
WATCH
是乐观锁,客户端不必等待取得锁,只需要在事务执行失败时重试即可,乐观锁可以提高并发能力
非事务型流水线 (non-transactional pipeline)
对于无需事务的大量操作可以使用非事务型流水线,可以避免事务消耗资源。
Python
中通过修改入参即可将事务改为非事务型流水线,而 Go
中根据具体框架的不同,可能需要手动封装流水线的处理逻辑。
性能优化
要对 Redis
的性能进行优化,首先需要弄清楚各种类型的 Redis
命令能跑多块,而这一点可以通过调用 Redis
附带的性能测试程序 redis-benchmark
得知。 P85
切记不要将输出结果看作是应用程序的实际性能,因为 redis-benchmark
不会处理执行命令所获得的命令回复,所以它节约了大量用于对命令回复进行语法分析的时间。 P86
可能影响性能的原因 P86
- 未使用流水线:可视情况适当使用流水线
- 对于每个命令或每组命令都创建了新的连接:使用连接池重用
Redis
连接 Redis
的数据结构或命令不合理(value
非常大,使用keys, hgetall
等):优化数据结构和命令
本文首发于公众号:满赋诸机(点击查看原文) 开源在 GitHub :reading-notes/redis-in-action