Mysql分布式解决方案

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

 

一、主从复制

原理解析:

  从库生成两个线程,一个 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:民间社区提供的【不推荐】

 

读写分离需要高可用,不能单点:

Mysql分布式解决方案

 

 

 

 

 

三、分库分表  

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

 

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

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

 

拆分带来的问题?

 拆分原则难以把控

 跨库查询

 主键唯一性受到挑战

 跨库事务带来的性能损耗

 

分布式主键生成方式(面试题):

 

UUID:

  优点:可用性高、性能高

  缺点:无序,不自增

 

 

中间件自增:Redis/ZK

  优点:简单

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

 

 

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

  优点:相对有序,性能高

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

Mysql分布式解决方案

 

 

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

  优点:自增有序

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

 

上一篇:MySQL45讲-2-一条SQL更新语句是如何执行的?


下一篇:青龙面板