redis-6.redis的主从复制、CAP、PAXOS、cluster分片集群01

redis

redis单机

在redis 单机，单节点，单实例存在的问题

• 单点故障（物理机挂了）
• 容量有限
• 压力很大

解决方式

AKF

有XYZ三个轴，可以只发生一个，可以多个维度一起发生

AKF 立方体也叫做scala cube，它在《The Art of Scalability》一书中被首次提出，旨在提供一个系统化的扩展思路。AKF 把系统扩展分为以下三个维度：

X 轴：直接水平复制应用进程来扩展系统。
Y 轴：将功能拆分出来扩展系统。
Z 轴：基于用户信息扩展系统。
其实无论事redis,mysql还是kafka 都是可以基于这种概念扩充

通过akf 来解决问题就会延申出来别的问题
问题1 数据一致性问题
方案1：所有节点阻塞，直至全部数一直性，但是这种情况就会造成redis的可用性降低, 一边多就是为了解决可用性问题

方案2：容忍数据丢失可能性，直接返回主机redis ok，异步插入备redis,这种情况要容忍数据丢失

方案3：如何保证不丢呢，可以穿插中间价kafka,达到数据的最终一致性。有多种可能：在达到最终一致性之前，可能会取到不一致的数据

问题2 如果主redis 挂了呢，导致整个服务不可用
主备：客户端不参与业务，只作备用机
主从：主从复制，可以在从库取数据（强调概念）
一般对主做高可用做HA，如果主redis挂了，我们可以人工去将 备1redis 顶上去，作为主机，让备2redis 继续做副，

但是啊，兄弟们，我们他妈是程序员啊，每次出现这种故障不说麻烦不麻烦，就会很low并且还有时间恢复问题，这个时候就出现了监控程序，但是一个监控程序也会挂掉，因此监控程序自身应该也是一个一变多的集群。

多台监控程序：多台监控等着一个主，如果redis挂了，监控去发现他，因为有网络延迟存在，多台监控该怎么判断redis到底挂没挂呢？就比如 监控1 发送挂了，监控2发送挂了，监控3没没监听到，这种情况怎么办？这时不能使用强一致性，只需要一部分机器给出结果判断就行，那么！一部分是多少个？

三个监控之间会产生不同的结果，产生竞争。会产生一个问题：网络分区（脑裂），不同的客户端拿到的是不同的数据，对外表现为数据的不一致。
如果2个监控说redis挂了，1个监控说redis还活着，这2个监控的势力为2。势力为1的监控就没有决策权了。这时对外表现出的就不是一种模棱两可的状态了。
因此，当势力达到n/2+1，也就是过半的时候，就可以解决脑力问题。所以集群一般使用奇数台。
为什么是奇数台？
我们用3台和4台比较，它们都只允许挂一台。但4台比3台更容易挂一台，而且4台的价格更高。所以第4台是没有必要的。

CAP

名词解释：
主从: 客户端既可以访问主 也可以访问备
主备: 客户端只会访问主 备用机用来替换主挂的情况
CAP: 一致性 可用性 分区容错性 最多满足两个 不能全部满足

主从复制

Redis使用默认的异步复制，其特点是低延迟和高性能，是绝大多数 Redis 用例的自然复制模式。但是，从 Redis 服务器会异步地确认其从主 Redis 服务器周期接收到的数据量。
条件有限，我在一台主机上启动了三台redis

5.0 之前的主从复制操作
127.0.0.1:16379> help SLAVEOF

  SLAVEOF host port
  summary: Make the server a replica of another instance, or promote it as master. Deprecated starting with Redis 5. Use REPLICAOF instead.
  since: 1.0.0
  group: server
5.0 之后的主从复制操作
127.0.0.1:16379> help REPLICAOF

  REPLICAOF host port
  summary: Make the server a replica of another instance, or promote it as master.
  since: 5.0.0
  group: server

这个时候我在 redis16380 上面设置主库

REPLICAOF 127.0.0.1 16379

报错！以为我之前在16379 上面添加过 密码。所以导致无法链接

要在这里配置16380.conf上配置6379 的密码


重新执行上一步链接操作

16379.log

16380.log

127.0.0.1:16379> set k1 zjj
OK

默认下16380 是只读的

127.0.0.1:16380> get k1
"zjj"
127.0.0.1:16380> set k1 aaa
(error) READONLY You can't write against a read only replica.

接下来修改16381 追随 16379，这个时候验证上面所有问题，在追随的情况下，redis追随者会flushall 自己的库

127.0.0.1:16381> set k2 aaa
OK
127.0.0.1:16381> get k2
"aaa"
127.0.0.1:16381> 
127.0.0.1:16381> REPLICAOF 127.0.0.1 16379
OK
127.0.0.1:16381> 
127.0.0.1:16381> get k1
"zjj"
127.0.0.1:16381> get k2
(nil)

这个时候我shutdown 16381

127.0.0.1:16381> SHUTDOWN

16379 报16381 链接不上，这个时候我们把redis 16381重新启动起来，那么16379的数据该如何同步呢

在redis 16381 挂掉的情况下继续写入16379

127.0.0.1:16379> set k2 aaa
OK
127.0.0.1:16379> set k3 bbb
OK

重新启动16381 redis-server ./6381.conf --replicaof 127.0.0.1 6379
重启之后，仍然会将挂掉这段时间的增量同步过来。

127.0.0.1:16381> keys *
1) "k1"
2) "k3"
3) "k2"

• masterauth < master-password >

设置密码

• replica-serve-stale-data yes

当在同步过程中，或则slave和master之间已经连接已经断开了，replica是否还能提供读请求呢？
默认情况下，replica是不能提供请求的，直接返回error, 但是当开启了如下配置后，则可以使用老的数据进行响应请求。

• replica-read-only yes

默认请求下，slave是只读的，防止误操作将数据写坏，但是如果非要可写，也可通过如下配置进行开启。

• repl-diskless-sync no

对于master端：
可通过开启如下配置，开启后master将不再生成rdb文件，直接将内存数据编码后发送给replica

• repl-backlog-size 1mb

增量复制
缓冲区是否配置的越大越好呢？
如果配置的过大，比如10G，而内存实际数据可能只有100M，当replica和master之间的连接断开的足够久，然后replica重连上了master，发送了一个offset过来，然后开始了10G命令的传输，
其实这个时候如果是全量同步，可能只需要100M的数据的传输。根据此情况，缓冲区还是不要太大。

• min-replicas-to-write 3
• min-replicas-max-lag 10

如果replica和master之间连接断开，master是如何处理的呢？是无动于衷么？
默认情况下，replica和master断开后，master是不干什么的，毕竟只是一个复制品，master不在乎。但是可以通过以上配置，让master在乎。
此配置表示在10秒钟内至少有3个replica在线，和master连接正常，否则master则不接受客户端的写操作，master在这段时间内变成了只读的，这样可以让replica尽可能的和master的差距减少。但同时也影响到了master的正常请求。
详细链接：https://blog.51cto.com/happytree007/2586641

Sentinel 哨兵

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

目前 Sentinel 系统是 Redis 的 unstable 分支的一部分， 你必须到 Redis 项目的 Github 页面 克隆一份 unstable 分值， 然后通过编译来获得 Sentinel 系统。
Sentinel 程序可以在编译后的 src 文档中发现， 它是一个命名为 redis-sentinel 的程序。
你也可以通过下一节介绍的方法， 让 redis-server 程序运行在 Sentinel 模式之下。
另外， 一个新版本的 Sentinel 已经包含在了 Redis 2.8.0 版本的释出文件中。

redis 安装目录src 下面可以找到

看一下我们系统默认程序目录

[root@admin redis]  redis-sentinel 26379.conf 

port 26379
## 当前Sentinel节点监控 127.0.0.1:6379 这个主节点 ， 1 代表判断主节点失败至少需要2个Sentinel节点节点同意
sentinel monitor mymaster 127.0.0.1 16379 2

# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

## 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过10000毫秒且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 10000

可以参考：https://www.jianshu.com/p/06ab9daf921d

redis-sentinel 26379.conf 
redis-sentinel 26380.conf 
redis-sentinel 26381.conf 

将salve库晋升为主库

slaveof no one

 127.0.0.1:16379> SHUTDOWN

这里26379，26380 监听到服务变化（注意，因网络或者心跳原因要等1秒左右）

这个时候提示我