万念俱灰，说的就是我现在的心情......
周六下午写了一下午的读书笔记，由于我的 MAC 有点问题，重启了一下......
灰飞烟灭......
读
第八章《集群》
总结
1：如何开启主从复制？
- Redis.conf 中配置 slaveof 主数据库地址 主数据库端口
- 启动一个 Redis 实例 redis-server --port 监听端口 --slaveof 主数据库地址 主数据库端口
2：如何查看主从数据库状态及其节点信息？
- INFO replication
3：设置主从后，从库可以写么？
- 不可以，如果在从库执行写操作的话，则会报错。
- 不过也可以通过修改配置 slave-read-only 使得从库可以执行写操作，不过这会使得主从数据库不一致。通常是禁止的(默认)
4：主从的原理是什么呢？是如何实现的呢？
- 当一个从数据库启动时，会向主库发送 PSYNC(Redis 2.8 之后) 命令。
- 当主库接到 PSYNC(Redis 2.8) 命令时，会[保存快照(RDB) + 缓存保存快照期间的命令]，当快照完成后，会把快照和缓存命令一块发给从库。
- 当从库接到后，会根据RDB快照和缓存命令，进行同步(也叫做复制初始化)。
5：为什么有时候主从数据不一致？
- 由于 Redis 采用了乐观复制，既乐观的认为主从数据最终是会同步的。
- 当客户端发起请求后，主数据库执行完成会立即返回结果。并将命令异步同步从数据库。
- 由于本身是异步，假如网络断开或者其他什么，就会导致主从数据不一致的情况发生。
6：如何解决主从数据不一致问题？
- Redis 在配置中提供了解决一致性的方案，合理的配置这两个选项可以降低(注意，不是解决)一致性的问题。
- min-slaves-to-write 3 是表示当有3个或者3个以上的从库更新了数据，主库才是可写的,如果不满足的话，会直接报错
- min-slaves-max-lag 10 是表示允许从库失去连接的最长时间，当从库超过这个时间时候，我们就认为这个从库已经[挂了]
7：主/从 数据库崩溃的处理办法？
- 当从库崩溃时，不会影响其他，当从库重启之后，主库会自动同步数据，所以也没有数据丢失问题。
- 主库崩溃后，情况会有一些复杂。
- 由于为了主库的性能最佳，通常会关闭 AOF/RDB 。
- 如果关闭，一定不要使用 Supervisor 等进程管理工具实现自动重启，因为当自动重启后，主库没有任何数据，当从库连接上之后，同步数据，从库数据也将清空
- 推荐使用 哨兵 机制来实现 主/从 的切换。
8：哨兵机制的简单实现？
- 这里我开了两个 redis-server 实例， 8680 端口作为 master，8681 端口作为 slave。
- 配置 哨兵 ，建立配置文件 sentinel.conf
- sentinel monitor 监控数据库名称 地址 端口 最低通过票数
- 例如： sentinel monitor mymaster 127.0.0.1 6379 1
- 启动监控：redis-sentinel /path/to/sentinel.conf
- 这时，我们杀死 master ，分析下日志
-
4451:X 20 Aug 05:17:27.444 # +monitor master mymaster 127.0.0.1 6380 quorum 1 // 主库
4451:X 20 Aug 05:18:13.972 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380 // 发现一个备库
// 杀死主库进程 4451:X 20 Aug 05:18:12.835 # +sdown master mymaster 127.0.0.1 6380 // 主观认为数据库停止了服务 4451:X 20 Aug 05:18:12.837 # +odown master mymaster 127.0.0.1 6380 #quorum 1/1 // 客观认为数据库已停止运行 4451:X 20 Aug 05:18:12.838 # +new-epoch 2
// 开始故障恢复 4451:X 20 Aug 05:18:12.839 # +try-failover master mymaster 127.0.0.1 6380 // 选择 6380 端口为主库
// 之后就是 6380 为主库，具体的细节一会在详细说
9：哨兵机制的实现原理？
- 当哨兵启动时，会和需要监控的主数据库建立两条连接。
- 一条是 订阅 __sentinel__::hello 频道，获取其他哨兵节点信息。
- 另一条需要定期发送 INFO 字段来获取，数据库本身信息。
- 当和主数据库建立完成之后，定期执行下列操作
- 10s/次 会向主数据库发送 INFO 命令
- 获取当前数据库相关信息(节点数量/节点信息/等等)
- 2s/次 会向主/从数据库的 __sentinel__::hello 频道发送自己的信息
- 1s/次 向主数据库和其他哨兵节点发送Ping命令
- 当主数据库出现问题时候
- 哨兵向主数据库发送 ping 命令，未回复，则该哨兵认为主数据库 主观下线
- 这时候会判断 quorum 参数
- 例如 sentinel monitor mymaster 127.0.0.1 6379 3
- 该配置表示，如果有三个哨兵认为主数据库主观下线
- 才会认为该主数据库 客观下线
- 当认为客观下线后，需要进行故障恢复。
- 这时，会推举领头哨兵进行故障恢复。
- 领头哨兵的选举流程为(Raft算法)
- 发现数据库主观下线的哨兵，向其他人发送命令，要求选自己为 领头哨兵
- 超过半数同意，则该哨兵成为领头哨兵进行故障恢复
10：什么样子的哨兵部署方案比较好？
- 建议为每个节点部署(主/从)哨兵。
- 保证环境一致。
- 设置 quorum 为 N/2 + 1 ,N为节点数量，这样保证一半同意，才会生效。