目录
分布式事务保证高可用 串行化级别
一、配置mysql主从模式的原因
二、Mysql主从复制的原理
三、Mysql主从复制的过程
四、MySQL支持的复制类型与MySQL复制应用类型
分库分表
垂直分库
水平分表
跨库join的问题
分布式存储 mysql
分库分表 进一步扩展读写性能
消息队列
Mysql 超卖方案
1)Mysql内建的复制功能是构建大型、高性能应用程序的基础。在实际企业应用环境当中,单台mysql数据库是不足以满足日后业务需求的。
譬如当服务器发生故障,而没有备份服务器来提供服务时,业务就必须得停止,这样会对企业带来巨大的损失。
2)为了提高数据库服务器的稳定性,加快数据处理的效率,保护数据免受意外的损失,我们采用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” 参数项
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,所以两端的数据是完全一样的。
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的,要么是设计不合理,要么是技术选型有误
首先要考虑下垂直分库的设计问题,如果可以调整,那就优先调整
1.全局表
所谓全局表,就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询,我们可以将这类表在其他每个数据库中均保存一份。同时,这类数据通常也很少发生修改(甚至几乎不会),所以也不用太担心“一致性”问题。
2.字段冗余
“订单表”中保存“卖家Id”的同时,将卖家的“Name”字段也冗余
3.数据同步
定时将指定的表做同步。当然,同步本来会对数据库带来一定的影响,需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询
4.系统层组装
调用不同模块的组件或者服务,获取到数据并进行字段拼装
业务拆分,提高吞吐量,稳定性
主从复制,扩展读,最终一致性
采用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【每秒事务数】
首页在缓存中静态化、依赖管理与优雅降级、核心链路开关
分库分表时,下单和减库存不在同一个事务中,导致超卖;
分离实际库存与页面的浏览库存,保证下单和减库存在同一个事务中
适合innodb的行锁,myisam是表锁,性能差;但是行锁也不够快,可用连接数会被沾满导致数据库拒绝服务
利用innodb行锁,库存分成多行记录,即分拆行锁,库存10000被拆分成5行库存2000的记录