这里是目录标题
1. 单机/单节点/单实例会存在哪些问题?
- 单点故障(X)
- 容量有限(Y)
- IO压力/并行压力(Z)
2. 如何解决单机带来的问题?
AKF可扩展立方体:https://www.jianshu.com/p/d08d0c14810f
- X:从单体系统或服务,水平克隆出许多系统,通过负载均衡平均分配请求
- Y:面向服务分割,基于功能或者服务分割,例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分,每一组服务再进行X轴的扩展
- Z:面向查找分割,基于用户、请求或者数据分割,例如可以将不同产品的SKU分到不同的搜索服务,可以将用户哈希到不同的服务等
3. 多节点带来的数据一致性问题
CAP定理:http://www.ruanyifeng.com/blog/2018/07/cap.html
下面的内容实际上就是对CAP定理的相关阐述
- 强一致性,所有节点同步阻塞直到数据全部一致
只有所有节点都一致,才会返回成功给client,如果某节点写数据失败,就会返回失败。如果总是返回失败给客户端,就会破坏可用性
- 弱一致性,容忍一部分数据丢失
主节点写成功即返回成功给client,通过异步方式把数据备份到备用节点,如果备节点都没有写成功,且主节点挂了,这时就无法恢复数据
- 最终一致性,使用kafka等技术解决上述两个问题
- 主节点也是一个单点
- 对主节点高可用,即当主节点挂了,备机/从机可以变成主机 -----> 自动的故障转移
- 监控程序集群,如果有 n/2+1 台监控程序认为主节点是ok的,那么就认为主节点ok,反之亦然
- 监控节点之间需要通信主节点状态
![]()
4. 解决X轴单点故障的问题
1. Redis主从复制
官方文档:http://redis.cn/topics/replication.html
-
Redis的主从复制用的是3.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)