分布式理论
CAP原则
在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）
最多只能同时三个特性中的两个，三者不可兼得
-
一致性：数据在多个副本之间能够保持一致
-
可用性：系统提供的服务一直处于可用的状态，每次请求都能获得正确的响应
-
分区容错性：在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务
BASE
BASE是Basically Available（基本可用） 、Soft-state（软状态） 和Eventually Consistent（最终一致性）三个短语的缩写。
BASE理论是对CAP中AP的一个扩展：1.通过牺牲强一致性来获得可用性2.当出现故障允许部分不可用但要保证核心功能可用3.允许数据在一段时间内是不一致的,但最终达到一致状态
-
基本可用：分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用
-
软状态：允许系统中的数据存在中间状态（CAP 理论中的数据不一致）
-
最终一致：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态
Mysql集群
优点：
-
性能提升：通过将负载分散到多个服务器，集群可以显著提升数据库的读、和写的性能
-
高可用性：集群模式提供冗余和故障转移机制
-
扩展性：集群可以通过添加更多节点，来水平扩展系统的容量、和处理能力
-
数据一致性：通过复制、和同步技术，集群模式可以确保数据在多个节点间的一致性
主从复制模式
一个主(Master)多从(Slave)，主负责写操作，从负责读操作，从库的数据从主库同步复制支持一台主库同时向多台从库进行复制，从库同时也可以作为其他从服务器的主库，实现链状复制主从复制可分为异步复制、同步复制和半同步复制三种
复制流程
-
master 记录 binary log 二进制日志
在每个事务完成数据更新之前，master 在二进制日志记录这些改变。
MySQL 将事务串行地写入二进制日志，完成后，master 通知存储引擎提交事务。 -
slave 将 master 的 binary log 拷贝到它自身的中继日志
-
slave 开始一个工作线程：I/O 线程
-
I/O 线程在 master 上打开一个普通的连接，然后开始 binlog dump process
-
binlog dump process 从 master 的二进制日志中读取事件
-
I/O 线程将这些事件写入中继日志
-
-
SQL slave 重做中继日志
- SQL 线程从中继日志读取事件，并重放其中的事件，更新 slave 的数据，使其与 master 中的数据一致
复制种类
-
异步复制：
-
实现：
-
主库写 binlog、从库 I/O 线程读 binlog 并写入 relaylog、从库 SQL 线程重放事务这三步之间是异步的
-
主库不需要关心备库的状态，主库不保证事务被传输到从库
-
如果主库崩溃，某些事务可能还未发送到从库，切换后可能导致事务的丢失
-
优点：可以有更高的吞吐量
-
缺点：是不能保持数据实时一致
-
-
同步复制
-
实现：
-
主库在提交事务前，必须确认事务在所有的备库上都已经完成提交
-
主库是最后一个提交的，在提交前需要将事务传递给从库并完成重放、提交等一系列动作
-
优点：任何时候主备库都是一致的，主库的崩溃不会丢失事务
-
缺点：由于主库需要等待备库先提交事务，吞吐量很低
-
-
半同步复制
- 实现：
- 主库在提交事务时先等待，必须确认至少一个从库收到了事件（从库将事件写入 relaylog，不需要重放和提交，并向主库发送一个确认信息 ACK）
- 主库收到确认信息后才会正式提交
- 优点：
- 有较高的吞吐量
- 有较好的安全性
- 缺点：
- 只适合在网络条件较好且地理上距离不远的环境部署，否则可能会因为网络延迟大幅降低主库性能
-
GTID
是已提交事务的一个编号，是事务的全局唯一编号,由 server_uuid：sequence_Number 组成
server_uuid：是 MySQL 实例的全局唯一标识；存放在$datadir/auto.cnf。
sequence_Number：是 MySQL 内部的事务编号，在一个 MySQL 实例中不会重复。
-
实现：
-
当一个事务在主库端执行并提交时，产生 GTID，一同记录到 binlog 日志中
-
binlog 传输到 slave，并存储到 slave 的 relaylog 后，读取 GTID 设置为 gtid_next 变量
-
sql 线程从 relaylog 中获取 GTID，然后对比 slave 端的 binlog 是否有该 GTID
-
如果有记录，说明该 GTID 的事务已经执行，slave 会忽略
-
如果没有记录，slave 就会执行该 GTID 事务，并记录该 GTID 到自身的 binlog
-
优点：
-
可以快速的确定事务最初是在哪个实例上提交的
-
一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次
-
不需要指定二进制文件名和位置
-
缺点：
-
主从库的表存储引擎必须一致
-
不允许一个SQL同时更新一个事务引擎和非事务引擎的表
-
不支持create table….select 语句复制
读写分离、分库分表
- 读写分离
通过主从复制实现，将写操作集中在主库（Master），读操作分散到多个从库（Slave）。可以使用 MyCAT 、或 ShardingSphere 等中间件，来实现读写分离。
- 分库分表
垂直拆分：表数量多，将表拆到其他库
水平拆分：表记录多，将表记录拆到其他表通过将这两种方法组合使用，可以有效地分散数据库的读写负载，同时实现水平扩展。
)