- 话不多，直接上图：
- 主要来详细讲讲各个搭配
1》一主一从（成本最低）：
- 并不是用来提高程序性能的，主要是用来做数据的热备（即如果master节点挂掉的话，slave节点能充当master节点），提高程序可用性，容灾性较好。
- 不存在数据一致性问题，因为只从一个节点中读取。
- 虽然可以做热备，但是无法做数据备份（非高可用），如果不小心在master节点执行了DROP，slave则马上同步这个操作，所以也无法在slave中找回数据
2》一主多从（通常2-4个Slave）：
- 选取一个节点做master备份，如果master挂了，则有slave马上充当master节点继续进行服务（打个比方，master是皇帝，slave就是太子，如果皇帝驾崩了，太子马上担当重任）
- 选取另一个节点，专门用来做慢查询、或统计操作
3》双主：
- 使用场景通常是，你这个业务啊，大部分的并发都是写导致，实在是承载不了
- 如何保证数据不会出现重叠呢？如果ID是整型，可采用取模操作，进行分配；如果ID是字符串，可采用哈希操作，进行分配
- 弊端：
- 如果某一个节点挂掉，整个数据会造成紊乱，不到万不得已不要用
- 【masterA】后面提供服务的从库需要等到【masterB】先同步完了数据后，才能从【masterA】上同步数据，这样可能会造成一定的延时
4》级联同步：
-
- 主要用来减轻master压力，由于master既要写操作，又要被多个slave节点进行读操作，所以中间的slave进行分压操作
- 如果master挂掉了，那么剩下的slave节点自然就组成了一个天然的集群结构
5》环形多主（处理能力强，却又很危险）：
-
- 图中有所省略，其中每一个master又对应了多个slave节点
- 如果某一个master挂掉了，那么整个架构基本就崩了（如通赤壁之战中的曹操，把所有的船都连在一起）
- 来了解一下通用的架构方案：
使用Atlas Proxy来配置集群代理，不需要在业务代码中，配置多个数据源来主动选择哪个节点进行读，哪个节点进行写。
即时后期我们新增加点或更换节点ip，只需修改Atlas配置内容即可，不需要修改业务代码。
