乐趣区

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

jiezi

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

退出移动版