由 dawei
Redis作为缓存使用，单进程单实例存在的问题：
ASP站长网单点故障
容量有限
压力过大
1|1Redis主从复制解决单点故障：
AKF拆分原则：
AKF拆分
x轴：全量、镜像。复制多个镜像，解决单点故障
y轴：按业务功能拆分为多个实例，同时在x轴方向同时创建多份镜像。
z轴：优先级、逻辑再拆分。比如说某个模块数据过多，可以拆分为多个Redis客户端，全量数据分为多份，每个Redis中存一部分数据。
此时虽然解决了单实例存在的三个问题，那么又会带来数据一致性问题。
解决数据一致性问题：
同步阻塞方式：
强一致性
假如说一个客户端做了一个写操作，到达主Redis，那么client将阻塞，直到主Redis通知两个备Redis都成功写入才返回结果。这时候为强一致性，带来的问题是，假如说备用Redis这时候挂掉，没有写入成功，那么主Redis等待超时之后，就返回给客户端失败，相当于服务不可用，破坏了可用性。
异步方式：
弱一致性：
弱一致性
容忍数据丢失一部分，当client发送一个写请求，Redis立刻返回OK，这时候通知备Redis去写，如果两个都写失败了，那么就会丢失数据。
最终一致性：
最终一致性
这种方式虽然数据最终会一致，但是在这期间如果有客户端去读数据，可能会造成脏读。
小知识：主备与主从的区别
主备：备机一般不参与业务，当主挂了之后，备机可以代替主去提供服务。
主从：客户端可以访问主，也可以访问从。
Redis一般使用主从复制的模式，但是此时主自己又是一个单点。
对主做HA高可用：
对主做高可用并不是说不让主出现问题，而是对外表现为没有出现问题。人工可以去把其中一个从机设置为主，让另一个从去追随它。但是人往往是不可靠的，所以需要技术或程序来实现，主要是一个程序就会有单点故障的问题，所以程序也必须是一个集群。
假如说有三个监控程序监控一个主Redis的存活状态，那么也就是说Redis的存活状态由三个监控程序说了算。
强一致性，都给出OK：假如说都给出OK，才表示Redis存活，那么必然会破坏可用性，比如说其中一个监控阻塞了，而实际Redis还存活，这相当于监控不可用，所以不可取。
一部分给出OK，另一部分不算数：那么一部分是几个呢？假如拿三个监控举例，那么就只能是1或者2。
推导过程：
1个：统计不准确，不够势力范围，因为每个都可以做主。可能会导致数据不一致，会有网络分区的问题，对外表现为同一服务拿到的数据不同，也就是脑裂。
并不是说发生脑裂不好，有个概念叫分区容忍性。比如说SpringCloud中的Eureka注册中心，假如说本来有十个服务注册到不同的Eureka中，负载的时候需要打到不同的机器上，每个负载发现的服务机器数不一致，但并不影响，对客户端来说，只要有服务可用即可。
2个：这个时候会有两台结成势力范围，两台之间互相通信，这时候给出的结果就是Redis要么存活，要么挂了，不会有中间状态。
2在3个节点成功解决脑裂问题，3在4/5个节点成功解决脑裂问题，可以得出结论，当有n个节点的时候需要n/2+1，也就是过半，一般使用奇数台。
为什么是奇数台？
3台、4台能承受的风险都是只允许1台出现问题，4台的成本更高。
4台的时候比3台更容易出现问题，即1台出现问题的概率更大。
主从复制配置：
replica-serve-stale-data yes
表示一个Redis在启动之后，并且将追随一个主Redis，在主给生成RDB文件到从Redis去load RDB文件之前，是否提供查询服务。no的话，直到全部同步完之前不提供服务。
replica-read-only yes
备机是否开启只读模式。
repl-diskless-sync no
主Redis发送RDB有两种方式，第一种方式是通过落到磁盘，从Redis再去load，第二种方式是直接通过网络发送RDB传给从Redis。这就取决于磁盘IO和网络IO哪个更快一些。配置no的话默认是走磁盘方式。
网络RDB
repl-backlog-size 1mb
主从复制，增量复制。在Redis中，除了写入RDB文件外，还维护一个小的队列。当从Redis load完RDB之后，突然挂掉了，然后服务又好了，这时候又需要去同步数据，但是此时的RDB文件已经过时，可以把RDB文件重新覆盖一遍，但是如果此时文件很大的话，又需要浪费时间。此时可以把一个偏移量给到主Redis，然后根据偏移量去获取增量数据，但是这时候取决于队列大小，默认为1MB，如果写的速度非常慢，在这期间没有超过设置的大小，那么是可以的，但是如果写的数据非常多，超过了设置的大小，那么又会走全量复制，所以要根据实际写入的数据设置合适的队列大小。
队列RDB
min-replicas-to-write 3 min-replicas-max-lag 10
可以设置最少写几个写成功，当关心数据一致性的时候，可以设置。默认是注释掉的，如果设置的话其实是在向强一致性靠拢，所以需根据实际应用场景配置。
HA高可用（x轴）:
sentinel哨兵代替人工去自动修复故障，可以是单机也可以是集群，只监控master节点，因为master节点上有slave节点信息，通过发布订阅发现其他哨兵。