复制简介 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等）：优化数据结构和命令