数据可靠+负载均衡：主从复制 + 分库分表

 

一、主从复制

原理解析：

　　从库生成两个线程，一个 I/O 线程，一个 SQL 线程；

　　 I/O 线程去请求主库的 binlog，并将得到的 binlog 日志写到 relay log(中继日志) 文件中；

　　 主库会生成一个 log dump 线程，用来给从库 I/O 线程传 binlog；

　　SQL 线程会读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

 

binlog:

　 二进制日志，记录mysql的数据更新，主要用于主从复制。

 

主从复制的方式（面试题）：

    Statement：基于 SQL 语句的复制，statement-based replication, SBR

　　优点：日志量小，节约IO，提高性能。 缺点：某些情况下会导致 master-slave中的数据不一致。

　Row：基于行的复制，row-based replication, RBR

　　优点：精准 缺点：日志量大

　Mixed：混合模式复制，mixed-based replication, MBR【推荐】

　　一般的复制使用STATEMENT模式保存binlog 对于STATEMENT模式无法复制的操作使用ROW模式保存binlog MySQL会根据执行的SQL语句选择日志保存方式。

 

主从复制的类型：

　同步复制： slave同步完成后才提交事务

　 异步复制：不关心slave是否同步便提交事务【推荐】

     半同步复制：部分slave同步完成后便提交事务

 

redolog与binlog的区别（面试题）：

　 1.redolog是存储引擎产生的，binlog是mysql server产生的。

　 2.redolog用于宕机后脏页的恢复，binlog主要用于主从复制。

 

二、读写分离

　（面试题：什么是读写分离）

　  写操作（delete/update/insert）走主库，读操作（select）走从库。

　

常用的读写分离中间件：

　　mysql-proxy：mysql官方提供的。

　　dbproxy：美团点评公司技术工程部DBA团队(北京)提供的。【推荐】

　　mycat：民间社区提供的【不推荐】

 

读写分离需要高可用，不能单点：

 

 

 

 

 

三、分库分表　　

把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的瓶颈问题。

 

水平拆分：按照不同的表(或者 Schema)来切分到不同的数据库中。【很少场景能如此做】

垂直拆分：根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库上。【基本都需要这么做】

 

拆分带来的问题？

　拆分原则难以把控

　跨库查询

　主键唯一性受到挑战

　跨库事务带来的性能损耗

 

分布式主键生成方式（面试题）：

　

UUID：

　　优点：可用性高、性能高

　　缺点：无序，不自增

 

 

中间件自增：Redis/ZK

　　优点：简单

　　缺点：可用性问题、ID可靠性较差

 

 

雪花算法： Twitter 公布的分布式主键生成算法，它能够保证不同进程主键的不重复性，以及相同进程主键的有序性。在同一个进程中，它首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。【推荐】

　　优点：相对有序，性能高

　　缺点：需要发现与容忍“时钟回拨”

 

 

数据库号段模式：一台数据库的一张表做为号段存储，每次要产生ID时，动态去申请一批次在内存中使用【推荐】

　　优点：自增有序

　　缺点：高可用与性能相对差一些