mysql读写分离

来源:互联网 发布:软件工程推荐书籍知乎 编辑:程序博客网 时间:2024/06/04 17:54

主题

  1. 什么是读写分离
  2. 读写分离配置
  3. 读写分离提高性能的原因
  4. 读写分离应用层方案选择
  5. Atlas的介绍
  6. 总结

1.什么是读写分离

基本原理:主数据库处理事务性查询,从数据库处理select查询。数据库复制被用来把事务性查询导致的变更同步到集群的从数据库中。
数据库复制也称之为主从复制。其基本的过程如下:
(1)master将改变的日志记录串行写入到二进制日志中(这些记录叫做二进制日志事件);
(2)slave将master的二进制日志事件拷贝到它的中继日志(relay log)中;
(3)slave重做中继日志中的事件,将改变反映到它自己的数据库中(读写分离会带来数据延迟的原因)。
下面是读写分离过程示意图:
读写分离日志同步示意图

2.读写分离配置

master

  • 解压- 新建mysql用户
  • 修改mysql的安装目录所有者与所属组
  • 修改mysql的配置文件,修改mysql的引擎InnoDB
  • 为mysql提供启动脚本
  • 初始化mysql数据库
  • 启动测试

slave

  • 修改mysql的配置文件,修改mysql的引擎MyISAM

具体的配置过程参考mysql的官方文档http://dev.mysql.com/doc/refman/5.7/en/replication-configuration.html

3.读写分离提高性能的原因

  • 物理服务器增加,负荷增加
  • 主从只负责各自的写和读,极大程度的缓解X锁和S锁的争用(事务隔离级别)
  • 从库配置myisam引擎,提升查询性能
  • 分摊读取。假如我们有一主N从,一分钟内有200条数据写入,2000条读取,那么,一主多从相当于从数据库承担了2000/N条读取。

4.应用层读写分离方案选择

1.replicationdriver或者使用replication协议头

  • replicationdriver 根据connection的readonly值切换master 或者slave conncetion
    官方链接地址https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-master-slave-replication-connection.html

2. 多数据源配置

  • spring提供一个AbstractRoutingDataSource类,通过ThreadLocal把一个datasource key绑定到当前线程,然后通过这个key,可以获得当前线程需要的datasource(如果salve的数量过多,采取算法,达到负载均衡)。

3.代理(与应用完全解耦)

  • mysql-proxy
  • cobar(淘宝mysql中间件)
  • Atlas(360mysql中间件,读音 ˈætləs)

5.Atlas

Atlas是一个位于应用程序与MySQL之间,它实现了MySQL的客户端与服务端协议,作为服务端与应用程序通讯,同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节,同时为了降低MySQL负担,它还维护了连接池。
这里写图片描述

Atlas配合LVS使用的架构

下图是一个可以参考的整体架构,LVS前端做负载均衡,两个Atlas做HA,防止单点故障。LVS周期性地对后端Atlas的存活检测有两种方式,一是直接去探测端口是否可连接,二是执行一个脚本,这个脚本会去尝试连接Atlas,通过脚本的返回值来决定每个后端是否可用。Atlas有两种运行状态,通常为online,可通过发信号将其置为offline。Atlas检测到来请求的IP是LVS的网卡IP时,如果处于online状态,就向LVS的检测脚本返回online,如果处于offline状态,就向脚本返回offline。比如我现在因为某种原因需要重启一台Atlas,但直接重启势必导致瞬间的SQL请求全部失败,对前端应用造成影响。因此我先发下线信号将Atlas置为offline状态,当LVS的检测脚本发现返回值是offline时,便将这台Atlas摘除,从此时开始便没有新的请求导向这台Atlas。等到已经打向这台Atlas的SQL请求处理完毕后(这是一个很短的时间),就可以安全重启Atlas而不必担心对前端造成影响了。

Atlas的使用具体参考https://github.com/Qihoo360/Atlas

6.总结

主要介绍了mysql主从分离的好处及配置和应用层方案的选择。

  • 对于读写分离的配置,可以选择网上的个人博客,照着别人试验过的方案,完全可行,如果是用于生产环境,一定要阅读官方文档;
  • 对于应用层方案,公司目前采用的是多数据源方式,目前看来运行稳定,后期如果数据量增大,从库数量增加,对于如果选择从库的,需要有一个算法,达到从库负载均衡的效果。
0 0