数据库多节点架构
1、异步复制
--默认的复制方式
--主节点写入binlog文件后就返回客户端，不考虑binlog是否完整同步到从节点，是否已完整存放到从节点的relay log 中去了
-- 优点：性能好，无阻塞
--缺点：如果主节点发生宕机，主节点上已提交的事务上位同步到从节点，如果此时强行从节点晋升为主节点，会导致新主节点数据不完整
2、全同步复制
--主节点写入binlog后就等着，知道事务在所有从库都提交后返回客户端
--好处：确保数据实时同步到了所有从库
--缺点：数据库的更新效率会差很多，增删改动作会较大的延迟
2、半异步复制
--主库提交事务后，不立即返回，而是等待至少1个从库接收到binlog，并写入relay log才会返回，从而保证从库出问题时候，至少有个从库数据是完整的
--当等待超时，会降低成异步复制，保证主库的正常更新
3、GTID复制
--GTID是（Global Transaction ID,全局事务标识）的简称，是对一个已提交事务的编号，并且全局唯一，一个事物对应一个GTID
--GTID由UUID + TID组成，UUID是MySQL示例的唯一标识；TOD则是事务在该示例上提交的顺序
4、多源复制
--多个数据源数据复制到一个节点上面去
--适用场景：
--数据分析团队可能要分析多个微服务的数据，可使用多源复制，将多个微服务的数据复制到一个数据库库中去，以方便统计分析
--数据备份，一个大型项目往往有多个微服务，多个数据库实例，可以把多个数据库复制到一个数据库实例实现数据备份
5、PXC（Percona XtraDB Cluster）
概念：
--组通信（Group Communication）：定义了数据库节点间的通信模式，保证复制数据库的一致性
--Write-Set Replication API(wsrep API):为上层提供丰富的状态信息及回调函数，实现多点写入及同步复制
--写集（Write-Set）：一个将要被复制的事务
--写集中不仅包括对事物影响的所有行的主键（组成写集的key）还包括事务产生的binlog（组成写集合的data），key-data 就是写集合
--key 用来验证和其他事务有没有冲突
--data用来验证通过后应用与提交
--数据传输方式
--SST全量传输，支持mysqldump、rsync、XtraBackup 3种方式
--IST增量传输，只支持XtraBackup
优点：
--数据同步复制，实现了强一致性，任何实例挂掉，数据都不会丢失
--数据并发复制，客户端延迟小
--部署简单，扩容方便
--多节点写入，故障切换容易
局限性：
--只支持Innodb引擎，而且所有的表都要有主键
--由于要保证数据一致性，所以多节点并发写入时，锁冲突、死锁的概率比其他模式高
--由于实现了强一致性，而且是同步写入，所以写操作要在所有节点都执行成功才算成功，所以写入效率往往取决于集群中性能最差的节点，存在短板效应
--每个节点都会发生写操作，存在扩大的问题
适用场景：
--追求强一致性
--希望多点写入
--市场正在被MySQL Group Replication抢占
6、Galera Cluster for MySQL
7、MHA（Master High Avaliability）
功能：
--故障自动切换
--保证故障切换的过程中数据丢失尽可能小
--保证故障切换后，其他从库和新的主库数据一致
原理
--如果宕机的主库人可以通过SSH链接，MHA会柏爱春从库的binlog
--根据从库的binlog位置，找到包含最新的更新的从库作为备用主库
--应用差异的relay log到其他从库，保持从库和备用主库一致
--应用从原主库上保存binlog，并将数据恢复到所有节点
--将备用主库晋升为新的主库，并让从库和新主库保持主从关系
8、MGR（MySQL Group Replication）
概念：
--由MySQL官方出品的，基于组复制概念并参考PXC、Galera Cluster for MySQL 等产品的有事，而设计的高可用集群架构
--基于PAXOS协议，解决了异步复制以及半同步复制等方式存在的数据一致性问题，非常适合金融行业使用
原理:
--主节点执行，然后广播到其他节点验证冲突并执行，如果出现冲突直接回滚
服务模式
--单主模式（推荐）
--分为PRIMARY（主）节点与SECONDARY（从）节点
--只有1个主节点，可读可写；其他节点都是从节点，只准许读操作，组内节点保持数据的一致性
--当主节点宕机或下线时，如满足多数节点存活的原则，则在内部发起宣讲，将一个从节点晋升成为主节点
选举算法：
--对组内成员的MySQL版本排序，选最低版本作为主节点
--实际项目中，应该尽量保证所有版本一致
--如果多接点同时使用最低版本，则考虑每个成员的权重
--可用 group_replication_member_weight指定，值是0-100，默认50，选值最大的节点作为主节点
--如果多个节点的权重值同时最大，通过SERVER_UUID系统变量计算
--字典排序选UUID最小的成员会成为主节点（show variables like '%SERVIER_UUID%'）
--多主模式
--多主模式下，每个节点都是PRIMARY节点，可读可写
--写操作会下发到组内所有节点，也保证组内数据的一致性
9、MMM（Multi-Master Replication Manager For MySQL）
--MySQL多主复制管理、故障切换的工具
高可用架构横向对比
1、异步复制
--优点：异步复制，性能好
--缺点：主从之间存在延迟，数据不一致，可能丢数据
--适用于：追求极值性能，对一致性要求不高的场景
2、半同步复制
--优点：主节点会等待至少1个节点返回后才会提交，提交两种模式，新模式不会丢数据，到超时时间时，会自动降级成异步复制模式
--缺点：存在等待从节点的开销，性能比异步复制要差一些
--适用于：不允许丢数据的场景
3、GTID复制
--优点：可通过GTID前半段的UUID知道事务最初是哪个数据库实例提交的
--GTID是有序的，保证一个GTID的事务在一个服务器上面只执行一次，避免重复执行导致数据库混乱及主从不一致
--运维方便，不需要指定binlog以及position
--缺点：部分SQL不支持GTID，可能要对应用做修改才行
--适用于：绝大多数场景，一般只要MYSQL支持GTID，就建议开启
4、PXC
--优点：
--使用者角度：多主模式，同步复制，多节点写，且能保证数据一致
--运维角度：搭建简单，故障切换较容易
--缺点：
--同步复制，性能会取决于集群中性能最差的节点，存在短板效应
--存在写扩大问题，节点数量不建议超过8个
--适用于：对一致性能要求非常高的场景，例如金融业务
5、MHA
--优点：
--自动故障转移，转移速度快
--故障转移时最大程度保持数据一致性
--对已有主从复制架构侵入性小
--缺点：
--自身不提供VIP配置工具，需要额外搭建
--另外功能是否强大，很大程度取决于脚本
--适用于：主从复制模式下的各种场景
6、MGR
--优点：
--既支持单主模式，有支持多主模式，且都能保持数据一致性
--借鉴PXC等技术，融合其优势，性能表现比PXC优越
--缺点：
--多主模式局限性比较多，用的时候要注意
--适用于：对一致性要求非常高的场景，取代PXC的场景