一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第11天，点击查看活动详情。
1 单机，单节点，单实例的问题
- 单点故障
- 容量有限
- 压力
2对于以上问题，常见的解决方案
2.1 创建数据副本
可以给redis创建数据副本，并将读操作分发都各个节点，写操作还需到主节点执行。
此举可以解决，单点故障和压力的问题
2.2 业务分发
将不同的业务数据分别放在不同的redis上，主要解决压力和容量的问题
2.3 分发业务并创建数据副本
也可对上边的结构进行横向扩展，对每个redis节点创建数据副本。
2.4 按照优先级和逻辑继续拆分
此基础上若是某个业务量庞大，也可以将集群进行继续扩展
这就是AKF
X轴方向，是全量的镜像（集群）
Y轴方向，是一业务和功能的扩展（分库分表）
Z轴方向，按照优先级和逻辑的拆分（分布式）
3 数据一致性的问题
通过AKF，当数据一变多时，必然有数据一致性的问题。
3.1 同步方式同步数据
解决方案：
强一致性，所有节点阻塞等待，直到数据全部一致。但是会破坏可用性。当一个从节点宕机后，整个集群将不可用
3.2 异步方式同步数据
异步方式，但需要容忍会丢失一部分数据
这里就要牵扯到CAP原则：
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
4 redis主从复制
redis集群使用异步的方式同步数据
主服务器：master
从服务器：slave
手动设置当前redis服务为slave。并指定master
REPLICAOF 127.0.0.1 6379
设置当前redis服务脱离集群
REPLICAOF no one
4.1 配置文件有关配置解读
4.1.1 replica-serve-stale-data
表示当一个服务作为slave启动时，同步master数据期间，是否提供服务。若为no，则阻塞等待同步完成后提供服务。
replica-serve-stale-data yes
4.1.2 replica-read-only
表示slave是否只读
replica-read-only yes
4.1.3 repl-diskless-sync
主从同步方式，
- no：先存到磁盘为RDB文件，再通过网络传输给另一个redis
- yes：直接通过网络IO将数据传输给另一个redis
repl-diskless-sync no
4.1.4 repl-backlog-size
redis描述自己更新内容的队列大小
若是一个slave宕机并重启，向master同步宕机期间的数据，根据自己已同步的数据的ID在队列里查询未能同步的数据并同步，若是自己保存的ID已经不再队列中，则全量同步，即master生成RDB文件，并发给这个slave，slave读取RDB文件。
repl-backlog-size 1mb
4.1.5 min-replicas-write
规定必须要几个slave同步成功
min-replicas-write 3
4.1.6 min-replicas-max-lag
如果一个从机的延迟值大于N,则拒绝写入数据
min-replicas-max-lag 10
