关于redis:Redis-实战-07-复制处理故障事务及性能优化

复制简介 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

在理论中最好让主服务器只应用 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