CAP原理、Redis集群理论基础

这里是目录标题

• • 1. 单机/单节点/单实例会存在哪些问题？
  • 2. 如何解决单机带来的问题？
  • 3. 多节点带来的数据一致性问题
  • 4. 解决X轴单点故障的问题
  • • • 1. Redis主从复制
      • 2. Redis高可用 (Sentinel)
  • 5. 解决Y轴容量的问题

1. 单机/单节点/单实例会存在哪些问题？

1. 单点故障(X)
2. 容量有限(Y)
3. IO压力/并行压力(Z)

2. 如何解决单机带来的问题？

AKF可扩展立方体：https://www.jianshu.com/p/d08d0c14810f

1. X：从单体系统或服务，水平克隆出许多系统，通过负载均衡平均分配请求
2. Y：面向服务分割，基于功能或者服务分割，例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分，每一组服务再进行X轴的扩展
3. Z：面向查找分割，基于用户、请求或者数据分割，例如可以将不同产品的SKU分到不同的搜索服务，可以将用户哈希到不同的服务等

3. 多节点带来的数据一致性问题

CAP定理：http://www.ruanyifeng.com/blog/2018/07/cap.html

下面的内容实际上就是对CAP定理的相关阐述

1. 强一致性，所有节点同步阻塞直到数据全部一致

只有所有节点都一致，才会返回成功给client，如果某节点写数据失败，就会返回失败。如果总是返回失败给客户端，就会破坏可用性

2. 弱一致性，容忍一部分数据丢失

主节点写成功即返回成功给client，通过异步方式把数据备份到备用节点，如果备节点都没有写成功，且主节点挂了，这时就无法恢复数据

3. 最终一致性，使用kafka等技术解决上述两个问题

4. 主节点也是一个单点

• 对主节点高可用，即当主节点挂了，备机/从机可以变成主机 -----> 自动的故障转移
• 监控程序集群，如果有 n/2+1 台监控程序认为主节点是ok的，那么就认为主节点ok，反之亦然
• 监控节点之间需要通信主节点状态
  

4. 解决X轴单点故障的问题

1. Redis主从复制

官方文档：http://redis.cn/topics/replication.html

1. Redis的主从复制用的是3.2中的弱一致性方案，其特点是低延迟和高性能

2. 主从复制常用配置
   关于配置的详细解释请参阅：https://blog.csdn.net/Ives_WangShen/article/details/109140771

• slave-serve-stale-data
• slave-read-only
• repl-diskless-sync
• repl-backlog-size
• min-slaves-to-write
• min-slaves-max-lag

2. Redis高可用 (Sentinel)

理论基础见4.4的图解
所有知识点都在官方文档上有详细解释：http://redis.cn/topics/sentinel.html

• 哨兵通过在主节点上pub/sub和其他哨兵通信
• 哨兵的配置文件在源码目录

5. 解决Y轴容量的问题

(TODO)