建立高可用的数据库

1、主从模式

1.1、为什么要设置主从同步

• 读写分离，减轻数据库负担。在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作
• 数据库实时备份。当系统中某个节点发生故障时，可以方便的故障切换(主从切换)。
• 高可用
• 随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。

1.2、主从形式

• 一主多从—读写分离，提供集群的并发能力(一般情况下，读数据的场景是多余写业务的场景的)
• 多主一从—从库主要用于数据库备份作用
• 双主复制
• 级联复制

1.3、实现原理

遵循两阶段提交协议，主要流程如下：

• 主库的更新SQL(update、insert、delete)被写到binlog
• 从库发起连接，连接到主库。
• 此时主库创建一个 binlog dump thread ，把 bin log 的内容发送到从库。
• 从库启动之后，创建一个 I/O 线程，读取主库传过来的 bin log 内容并写入到 relay log
• 从库还会创建一个SQL线程，从 relay log 里面读取内容，从 ExecMasterLog_Pos 位置开始执行读取到的更新事件，将更新内容写入到 slave 的db

1.4、数据高可用方案

• 双机主备：两台机器A和B，A为主库，负责读写，B为备库，只备份数据。如果A库发生故障，B库成为主库负责读写。修复故障后，A成为备库，主库B同步数据到备库A
• 一主一从：两台机器A和B，A为主库，负责读写，B为从库，负责读数据。如果A库发生故障，B库成为主库负责读写。修复故障后，A成为从库，主库B同步数据到从库A。
• 一主多从：一台主库多台从库，A为主库，负责读写，B、C、D为从库，负责读数据。如果A库发生故障，B库成为主库负责读写，C、D负责读。修复故障后，A也成为从库，主库B同步数据到从库A。
• MariaDB同步多主机：有代理层实现负载均衡，多个数据库可以同时进行读写操作；各个数据库之间可以通过 Galera Replication 方法进行数据同步，每个库理论上数据是完全一致的。
• 数据库中间件：mycat分片存储，每个分片配置一主多从的集群。

1.5、一主多从模式与级联复制模式的比较

​ 在一主多从模式下，主从间的传输延迟会小一些，但是会产生太多binlog dump 线程，会加重主库的IO 负载。

​ 若采用级联复制，主上就一个dump 线程，从主上不承担读binlog 的内容，只负责把主上的binlog 传送到从库上。要把从主的表和各种都设置成BLACKHOLE 引擎，从主应用日志产生的数据都被丢到黑洞里去，只需要从主在应用主库的binlog时产生的binlog，所以设置log_slave_updates=on，从主开启binlog，才能在从主应用主上的日志的时候把产生的binlog 传送到（二级）从库上。

2、分库分表

随着业务的增长，MySQL中保存的数据会越来越多。此时，数据库很容易成为系统性能的一个瓶颈，单机存储容量、IO、CPU处理能力都有限，当单表的数据量达到1000W或100G以后，库表的增删改查操作面临着性能大幅下降的问题。这是就可以考虑分库分表的方法优化数据库。

2.1 垂直切分

2.1.1 垂直分库

将系统拆分为多个业务，每个业务使用自己单独的数据库。

2.1.2 垂直分表

​ 垂直分表是基于数据库中的表字段来进行的。业务中可能存在一些字段比较多的表，表中某些字段长度较大，这些长字段我们又只是偶尔需要用到，这时候我们就可以考虑将表进行垂直拆分了。

​ 将某些不常用的，但是长度又很大的字段拎出来放到另外一张表。

​ MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。

2.2 水平切分

2.2.1 库内分表

库内分表就是在同一个DB上，将表按照某种条件拆分为多张表。可以按照存储的日期进行分表（一月存储的数据为1张表，二月存储的数据为一张表……），也可以按照存储的id序号进行分表（1-1000000为1张表，1000001-2000000为1张表……）。具体的分表情形以业务为准，按需分表。下图为按日分表。

2.2.2 分库分表

分库分表就是将表不仅拆分，而且拆分到不同机器上。

比如我们腾讯云上的DCDB就是这种处理方法。可以指定一张表的shardKey，然后对shardKey取hash，根据hash值将数据放到不同的数据库中， 可以解决单机物理资源的瓶颈问题。

分表分库中间件市面上主要有两种，即当当的sharding-jdbc和阿里的mycat，二者的区别对比如下：

3、分布式缓存

3.1 优化原理

当接收到查询请求后，我们先查询缓存，判断缓存中是否有数据，有数据就直接返回给应用，如若没有再查询数据库，并加载到缓存中，这样就大大减少了对数据库的访问次数，自然而然也提高了数据库性能。

注意：引入分布式缓存后系统需要考虑如何应对缓存穿透、缓存击穿和缓存雪崩的问题。

3.2 高性能

假设场景，一个请求过来，存数据库查询结果返回给用户，假设耗时 600ms。但是这个结果可能接下来几个小时都不会变了，或者变了也可以不用立即反馈给用户。那么此时咋办？

那就可以考虑使用缓存，一个 key 对应一个 value，下次再有人查，不再花费 600ms 从mysql中查询，直接从缓存里，通过一个 key 查出来一个 value，2ms 搞定。性能提升 300 倍。

就是说对于一些需要复杂操作耗时查出来的结果，且确定后面不怎么变化，但是有很多读请求，那么直接将查询出来的结果放在缓存中，后面直接读缓存就好。

3.3 高并发

假设场景，流量访问高峰期一秒请求 1 万次，对于mysql来说，负载相当大，mysql 很可能就会宕掉或者查询的效率极大下降。此时如果通过缓存，把很多数据放缓存，不用再去查询mysql，直接从缓存中读取，可以大大提高并发量。

4 后言

后续更新mycat分库分表，分布式缓存redis的博文