redise 与 mysql 交互_Redis（1.7）Redis高可用架构与数据库交互（理论篇）

【0】常用架构种类

(0.1)单机Redis

(0.2)单纯的Redis主从复制

(0.3)哨兵Sentinel+Redis主从复制集群(实现高可用自动故障转移)

(0.4)Redis Cluster 分布式数据库集群

(0.5)第三方中间件+Redis 主从复制

【1】Redis 主从复制

一般情况下，这种架构，主节点负责写数据，从节点负责读数据，主节点定期吧数据同步到从节点保证数据一致性。

常用的Redis主从拓扑：

(1)一主一从　　(2)一主多从　　(3)级联复制

【1.1】一主一从

主要是主库写，从库读。且主库不开启持久化，从库开启AOF即可。

【1.2】一主多从

实现读写分离，针对读较多的场景，主写从读，读有多个节点来分担，考虑到主库压力不建议从库超过3个，且受网络影响较大。

【1.3】级联复制

A->B->C/D，A复制到B，B复制C和D

【1.4】Redis主从复制过程

(1)基本过程

从库启动后：保存主节点信息；

主从建立连接；

从发送ping命令；

验证权限；

同步数据集；

持续复制；

(2)主从复制的缺点

【若主节点出现问题，则不能提供服务，需人工配置】

【主从复制主节点的写能力单机，能力有限】

【单机节点的存储能力有限】

【主从故障如何故障转移的问题】

1)主节点(master)0故障，从节点 slvae-1端执行 slaveof no one 后变成新主节点；

2)其他的节点成为新主节点的从节点，并从新节点辅助数据

3)需人工操作，无法实现高可用

当 master 关闭持久化时，复制的安全性

在使用 Redis 复制功能时的设置中，强烈建议在 master 和在 slave 中启用持久化。当不可能启用时，例如由于非常慢的磁盘性能而导致的延迟问题，应该配置实例来避免重置后自动重启。

为了更好地理解为什么关闭了持久化并配置了自动重启的 master 是危险的，检查以下故障模式，这些故障模式中数据会从 master 和所有 slave 中被删除：

我们设置节点 A 为 master 并关闭它的持久化设置，节点 B 和 C 从 节点 A 复制数据。

节点 A 崩溃，但是他有一些自动重启的系统可以重启进程。但是由于持久化被关闭了，节点重启后其数据集合为空。

节点 B 和 节点 C 会从节点 A 复制数据，但是节点 A 的数据集是空的，因此复制的结果是它们会销毁自身之前的数据副本。

【