一、主从架构
为什么要主从架构？
- 如果主服务器出现问题，可以快速切换到从服务器提供的服务
- 可以在从服务器上执行查询操作，降低主服务器的访问压力
- 可以在从服务器上执行备份，以避免备份期间影响主服务器的服务
主从方案
- M-S：一主一从，主提供读写，从只提供读。
- M-S-S-S：一主多从，主提供读写，从只提供读。
- M-M-M-S：多主一从，主提供读写，从只提供读，多系统数据汇总场景下使用。
主从复制方式
同步复制(Fully synchronized)
这种复制方式能保证主从数据的强一致性，期间存在一步失败会触发之前的操作进行回滚，但是这种同步复制方式性能低下。
异步复制（Asyn）
mysql默认的复制方式，性能较好，但这种方式不能保证主从数据的强一致性，存在从数据库数据丢失的情况。
半同步复制
半同步复制该方式相当于在异步复制与同步复制两种方式间折了一个中。
主从复制原理
二、高可用架构方
MMM高可用方案
MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一 套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)
优点
- 高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数 据库写操作，保证数据的一致性。
- 配置简单，容易操作。
缺点
- 需要一台备份服务器，浪费资源
- 需要多个虚拟IP
- agent可能意外终止，引起裂脑。
MHA方案
MHA服务，有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)。在 MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据 库服务器。
优点
- 不需要备份服务器
- 不改变现有环境
- 操作非常简单
- 可以进行日志的差异修复
- 可以将任意slave提升为master
缺点
- 需要全部节点做ssh秘钥
- MHA出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。
- 自带的脚本还需要进一步补充完善，且用perl开发，二次开发困难。
分库分表
将一个表拆分多张表(库内分表与分库分表)
拆分原因
- 数据量大。
- 微服务业务粒度拆分。
- 提升性能。
注意：尽量不要去做分库分表，除非真的有需要。
拆分方式
横向拆分
- 数据量庞大：树高过高，导致磁盘io次数增加。
纵向拆分
- 拆库
- 根据业务拆分
拆分后产生的问题
- 跨库join问题
- 主键重复问题。
- 分页查询
- 关联查询
- sum、distince等函数操作
注意：多主一从集群把数据统一后再操作可以解决。
分库分表组件
- shardingsphere（京东数科）在apache孵化
- Mycat（阿里巴巴-基于cobar）不是阿里的
- Tddl
- Atlas （奇虎360）
如何保证DB&缓存的最终强一致性
如何保证数据库操作与这些行为的一致性，就成为一个难题。以数据库与redis缓存的 一致性为例：操作数据库成功了，可能会更新redis失败；反之亦然。很难保证二者的完全 一致。
遇到这种看似无解的问题，最好的办法是换一种思路去解决它：不要同时去更新数据库 和其他组件，只是简单的更新数据库即可。
如果数据库操作成功，必然会产生binlog。之后，我们通过一个组件，来模拟的mysql 的slave，拉取并解析binlog中的信息。通过解析binlog的信息，去异步的更新缓存、索引 或者发送MQ消息，保证数据库与其他组件中数据的最终一致。
