Mysql分布式架构解决超卖问题

目录

分布式事务保证高可用 串行化级别

一、配置mysql主从模式的原因

二、Mysql主从复制的原理

三、Mysql主从复制的过程

四、MySQL支持的复制类型与MySQL复制应用类型

分库分表

垂直分库

水平分表

跨库join的问题

分布式存储 mysql

分库分表 进一步扩展读写性能

消息队列

Mysql 超卖方案

---

分布式事务保证高可用 串行化级别

• 允许多个独立事务资源，参与到一个全局事务中，要求原子性，存储级别必须设置为 串行化级别
• 由XA事务实现，XA事务由一个或多个资源管理器、一个事务管理器、一个应用程序组成，采用二阶段提交协议，2PC
• 内部XA事务，事务提交时，准备阶段，先将事务xid写入。再进行二进制日志binlog写入，如果事务提交前，MYSQL数据库拓机，重启后会先检查UXID事务是否已提交，若没有再进行一次提交操作

一、配置mysql主从模式的原因

1）Mysql内建的复制功能是构建大型、高性能应用程序的基础。在实际企业应用环境当中，单台mysql数据库是不足以满足日后业务需求的。

　　譬如当服务器发生故障，而没有备份服务器来提供服务时，业务就必须得停止，这样会对企业带来巨大的损失。

2）为了提高数据库服务器的稳定性，加快数据处理的效率，保护数据免受意外的损失，我们采用mysql的主从复制方式，分离对数据库的查询和更新操作，使用从服务器上备份的数据保证来数据的安全性和稳定性

二、Mysql主从复制的原理

1）MySQL 的 Replication 是一个异步的复制过程，从一个 MySQL instace(我们称之为 Master)复制到另一个MySQL instance(我们称之 Slave)

在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql 线程和IO 线程)在 Slave 端，另外一个线程(IO 线程)在 Master 端。 

2）在执行这个主从复制之前，首先必须打开 Master 端的Binary Log(MySQL-bin.xxxxxx)功能，否则无法实现。

　　在启动 MySQL Server 的过程中使用“log-bin” 参数选项

　　在 my.cnf 配置文件中的 MySQLd 参数组中增加“log-bin” 参数项

三、Mysql主从复制的过程

3.1、主从复制详细过程

　　1） Slave 上面的IO 线程连接上 Master，并请求从指定二进制日志文件的指定位置(或者从最开始的日志)之后的日志内容。

　　2） Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。

　　　　返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 BinaryLog 中的位置。

　　3）Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的RelayLog （中继日志文件）文件的最末端，并将读取到的Master 端的bin-log 的文件名和位置记录到master-info 文件中，

　　　　以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我” 。

　　4）Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。

　　　　这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。

 

四、MySQL支持的复制类型与MySQL复制应用类型

4.1、MySQL支持的复制类型 sql复制

　　1）基于语句的复制statement：  在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于SQL语句的复制，效率比较高。一旦发现没法精确复制时，会自动选着基于行的复制。   

　　2）基于行的复制row：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持

　　3）混合类型的复制mixed: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制

4.2、MySQL复制应用类型

　　1）数据分布 (Data distribution )

　　2）负载平衡(load balancing)

　　3）读写分离(split reading and writting)

　　4）高可用性和容错性 (High availability and failover )

分库分表

索引+分库分表实现数据高性能读

垂直分库

按照业务模块来划分出不同的数据库；避免过早优化；用户服务的用户数据库，看架构师水平

水平分表

将表中不同的数据行按照一定规律分布到数据库不同的表；不建议

水平分库分表 类似mysql+redis

拆分出来的表保存在不同的数据库

使用的“冷热数据分离”（将一些使用较少的历史数据迁移到其他的数据库中。而在业务功能上，通常默认只提供热点数据的查询）

缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈

跨库join的问题

如果有多个join的，要么是设计不合理，要么是技术选型有误

首先要考虑下垂直分库的设计问题，如果可以调整，那就优先调整

1.全局表

所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。

2.字段冗余

“订单表”中保存“卖家Id”的同时，将卖家的“Name”字段也冗余

3.数据同步

定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询

4.系统层组装

调用不同模块的组件或者服务，获取到数据并进行字段拼装

分布式存储 mysql

业务拆分，提高吞吐量，稳定性

主从复制，扩展读，最终一致性

采用Dual-master架构，设置stabdby Master，解决单点Master故障问题，方便停机维护

正常情况下，仍旧是只有主master负责写，standby负责读，避免数据写入的冲突，防止数据不一致情况

当停机维护时，修改配置文件（read only），standby同步完成后，接管开始写入数据

拓机时，需要复制未同步的二进制日志到standby，直到同步后才能够接收写

 

分库分表 进一步扩展读写性能

提升读性能，分表：订单表，以用户分成256张，userid%256；提升写性能，分库

分库+分表：对于 userid = 262145的访问，256个库，每个库1024个表

temp = 262145 %（库数量256 * 每个库的表数量1024）= 1

库id = temp / 每个库表数量 = 0

表id = temp % 每个库表数量 = 1

将被路由到第 0 个库，第 1 个表

缺点：1.跨表的事务变为分布式事务，关联查询复杂2.必须要用路由字段userid；3.扩容导致路由策略变更，需要数据迁移

解决：1.结合搜索引擎，构建一张经常被关联的大表；2.Hbase，借助region server天然支持分布式并发读写

Hbase、redis

消息队列

安全 https 对称加密，通信过程进行加密

分布式系统稳定性分析

日志分析

访问量、最耗时的页面、404请求占比

集群监控：

CPU利用率、磁盘、内存、网络、qps【每秒查询数】、rt【响应时间】、tps【每秒事务数】

首页在缓存中静态化、依赖管理与优雅降级、核心链路开关

Mysql 超卖方案

分库分表时，下单和减库存不在同一个事务中，导致超卖；

分离实际库存与页面的浏览库存，保证下单和减库存在同一个事务中

适合innodb的行锁，myisam是表锁，性能差；但是行锁也不够快，可用连接数会被沾满导致数据库拒绝服务

利用innodb行锁，库存分成多行记录，即分拆行锁，库存10000被拆分成5行库存2000的记录