Mysql第四章 分库分表，读写分离，主从架构

一 分库分表

1 为什么要分库分表

在双十一的时候，网站的流量逐渐增加的情况下，传统的主从架构在上亿并发量的情况下，一个主表吞吐容量不够，业务越来越大，单表数据超出了数据库支持的容量，一个nginx并发量只有五万多，tomcat更是只有几千个

2 分库分表的几种方式

分库分表相当于把单机PC上存不下的数据，转化为了分布式PC，放到多台电脑上

2.1 垂直拆分

2.1.1 表的垂直拆分

一个概述表，一个详情表
根据业务去拆分表，把user表拆分为拆分成user_base表和user_info表，use_base负责存储登录，user_info负责存储基本用户信息

2.1.2库的垂直拆分

根据业务拆分，电商系统，拆分为订单库、会员库、商品库

2.1.2 垂直拆分的特点

1.每个库（表）的结构都不一样
2.每个库（表）的数据至少一列一样
3.每个库（表）的并集是全量数据
4.拆分后业务清晰，专库专用按照业务拆分
5.数据维护简单，按照业务不同，放到不同的机架上

2.2 水平拆分

2.2.1 表的水平拆分

如图把users表拆分成users1表和users2表，以userId拆分，进行取模，偶数放到users1表，奇数放到users2表

2.2.2 库的水平拆分

按会员库拆分，拆分成会员1库，会员2库，以userId拆分，userId尾号0-5为1库，6-9为2库，还有其他方式，进行取模，偶数放到1库，奇数放到2库
王者荣耀里面的分库，确是按照那个注册时间这个主键来拆分的，比方说从1号库到500号库

2.2.3 水平拆分的特点

• 每个表的结构都不一样，按照行来拆分，用户表里头，比方说有VIP用户，有普通用户，把这两个人居住的地方隔开，一个人一个时刻只有一个位置，但这两个表的并集，是所有的数据
• 优点：单库单表的数据保持在一定量，读取速度变快

•      提高了系统的稳定性，改着不是那么方便了
  

• 缺点： 库和表很难一起扩容

3 分库分表的技术选型

分库分表的开源框架

jdbc 直连层：shardingsphere、tddl
proxy 代理层：mycat，mysql-proxy（360）

3.1 JDBC直连层

可以跨数据库，但是只能在java语言里头编译

3.2 proxy代理层

不能跨数据库，但是可以支持多种语言

二 读写分离

1 读写分离的架构与数据一致性问题

• 读写分离主要应用于单机操作系统中，主要为了让数据库的读和写分配到不同的节点上，主数据库负责写操作，从服务器负责读操作。
• 一般采用一主多从的模式，可以大幅度提高读性能，小幅度提高写性能，这样架构实现起来非常的简单
• 读写分离负面影响：主从同步延迟，写完主数据库后，主数据同步到从库是需要时间的，时间差会导致数据一致性的问题
• 解决策略：
  – 延迟读取，既然存在延迟导致数据不一致，那么我就等系统刷新数据一致之后再读取
  – 强制同步，采用一致性工具，强制把读请求发到主数据库里
  

2 如何实现读写分离

• 部署多台服务器，选择其中一台作为主数据库，另外几台作为从数据库
• 主数据库和从数据库之间的数据是实时同步的，这就是我们常说的主从复制
• 系统将写请求发给主数据库处理，写请求发给从数据库处理
• 应用和数据之间加一个代理层，应用程序所有的数据都交给代理层处理，代理层负责分离读写请求，将他们路由到对应的数据库中

3 主从复制原理

mysql binlog 二进制日志文件记录了一些

• DDL，数据定义语言，DATA DEFINDINE LANGUAGE
• DML，数据操作语言 DATAmanagement LANGUAGE
  因此我们同步了二进制日志，也就同步了数据到另一个库里头

 1. 主库将数据库中数据的变化写入到 binlog
 2. 从库连接主库
 3. 从库会创建一个 I/O 线程向主库请求更新的 binlog
 4. 主库会创建一个 binlog dump 线程来发送 binlog ，从库中的 I/O 线程负责接收
 5. 从库的 I/O 线程将接收的 binlog 写入到 relay log 中。
 6. 从库的 SQL 线程读取 relay log 同步数据本地（也就是再执行一遍 SQL ）。

三 主从架构的搭建

1 Mysql复制原理

2 具体执行过程

2.1 系统架构图

2.1.1 软件准备

一个装有Mysql8.0的虚拟机，一个mycat中间件

2.1.2 和虚拟机的安装大同小异