数据库的读写分离

数据库的读写分离

      读写分离，基本的原理是让主数据库处理事务性增、改、删操做（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操做。数据库复制被用来把事务性操做致使的变动同步到集群中的从数据库。

       为何要分库、分表、读写分？

       单表的数据量限制，当单表数据量到必定条数以后数据库性能会显著降低。数据多了以后，对数据库的读、写就会不少。分库减小单台数据库的压力。接触过几个分库分表的系统，都是经过主键进行散列分裤分表的。这类数据比较特殊，主键就是惟一的获取该条信息的主要途径。好比：京东的订单、财付通的交易记录等。。。该类数据的用法，就是经过订单号、交易号来查询该笔订单、交易。

      以oracle为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操做，同步更新cache，每次读取先读cache在读DB。写库就一个，读库能够有多个，采用dataguard来负责主库和多个读库的数据同步。

mysql读写分离和主从复制的基本原理

      mysql的读写分离的基本原理是：让master（主数据库）来响应事务性操做，让slave（从数据库）来响应select非事务性操做，而后再采用主从复制来把master上的事务性操做同步到slave数据库中。

        读写分离就是利用mysql的主从复制完成的，A不间断的把binlog信息发送给B，保持B和A的数据一致，若是还须要在B上写的话，你须要开启主主模式。关于第三点，你若是采起的是A-B A-C A-D模式的话确定是须要A给每一个从库都须要发送binlog信息的，若是是A-B-C这种级联的模式，是只须要A给B发送一次binlog信息，而后B给C发一次。

        Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(咱们称之为 Master)复制到另外一个 Mysqlinstance(咱们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另一个线程(IO线程)在 Master 端。 MySQL 复制的基本过程以下：

       1. Slave 上面的IO线程链接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)以后的日志内容;

        2. Master 接收到来自 Slave 的 IO 线程的请求后，经过负责复制的 IO 线程根据请求信息读取指定日志指定位置以后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息以外，还包括本次返回的信息在 Master 端的 BinaryLog 文件的名称以及在 Binary Log 中的位置;

        3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候可以清楚的高速Master“我须要从某个bin-log的哪一个位置开始日后的日志内容，请发给我”

        4. Slave 的 SQL 线程检测到 Relay Log 中新增长了内容后，会立刻解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了一样的 Query，因此两端的数据是彻底同样的。

        利用mysql proxy来实现的。 MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询致使的变动同步到集群中的从数据库。 固然，主服务器也能够提供查询服务。使用读写分离最大的做用无非是环境服务器压力。

 

MySQL主从复制（Master-Slave）与读写分离（MySQL-Proxy）实践

Mysql做为目前世界上使用最普遍的免费数据库，相信全部从事系统运维的工程师都必定接触过。但在实际的生产环境中，由单台Mysql做为独立的数据库是彻底不能知足实际需求的，不管是在安全性，高可用性以及高并发等各个方面。

所以，通常来讲都是经过 主从复制（Master-Slave）的方式来同步数据，再经过读写分离（MySQL-Proxy）来提高数据库的并发负载能力 这样的方案来进行部署与实施的。

以下图所示：

 

 

mycat主从读写分离

    Mycat是一个开源的分布式数据库系统，可是因为真正的数据库须要存储引擎，而Mycat并无存储引擎，因此并非彻底意义的分布式数据库系统。Mycat是数据库中间件，就是介于数据库与应用之间，进行数据处理与交互的中间服务。对数据进行分片处理以后，从原有的一个库，被切分为多个分片数据库，全部的分片数据库集群构成了整个完整的数据库存储。

什么是MyCAT

1. 一个完全开源的，面向企业应用开发的大数据库集群
2. 支持事务、ACID、能够替代MySQL的增强版数据库
3. 一个能够视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
4. 一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
5. 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
6. 一个新颖的数据库中间件产品

mysql主从复制实现的基础上，利用mycat作读写分离，架构图以下：

二、Demo

2.1 在mysql master上建立数据库建立db1

2.2 在数据库db1建立表student

同时，由于配置好了mysql主从复制，在mysql slave上也有同样数据库和表

注意 dataHost节点的下面三个属性

balance， switchType， writeType

balance="0", 不开启读写分离机制，全部读操做都发送到当前可用的writeHost上。

balance="1"，所有的readHost与stand by writeHost参与select语句的负载均衡，简单的说，当双主双从模式(M1->S1，M2->S2，而且M1与M2互为主备)，正常状况下，M2,S1,S2都参与select语句的负载均衡。

balance="2"，全部读操做都随机的在writeHost、readhost上分发。

balance="3"，全部读请求随机的分发到writeHost下的readhost执行，writeHost不负担读压力

writeType表示写模式

writeType="0"，全部的操做发送到配置的第一个writehost

writeType="1"，随机发送到配置的全部writehost

writeType="2"，不执行写操做

switchType指的是切换的模式，目前的取值也有4种：

switchType=‘-1‘ 表示不自动切换

switchType=‘1‘ 默认值，表示自动切换

switchType=‘2‘ 基于MySQL主从同步的状态决定是否切换,心跳语句为show slave status

switchType=‘3‘基于MySQL galary cluster的切换机制（适合集群）（1.4.1），心跳语句为show status like ‘wsrep%‘。

 

 

 

参考连接：http://jayluns.iteye.com/blog/2275690

不停库不锁表在线主从配置 http://seanlook.com/2015/12/14/mysql-replicas/ mysql主从常见问题 http://www.10tiao.com/html/706/201603/403220961/1.html mysql主从延迟 http://f.dataguru.cn/thread-461916-1-1.html  深刻探究主从延迟 http://ningg.top/inside-mysql-master-slave-delay/ mysql主从不一样步如何作 http://www.jb51.net/article/33052.htm mysql 主主 http://www.cnblogs.com/ygqygq2/p/6045279.html mysql-proxy 实现读写分离 http://my.oschina.net/barter/blog/93354  mycat实现读写分离 http://www.th7.cn/db/mysql/201708/250280.shtml atlas相关 http://www.oschina.net/p/atlas mysql一主多从 http://blog.sina.com.cn/s/blog_4c197d4201017qjs.html mysql环形主从 http://ask.apelearn.com/question/11437 cobar实现分库分表 http://blog.csdn.net/huoyunshen88/article/details/37927553 mysql分库分表方案 http://my.oschina.net/ydsakyclguozi/blog/199498 mysql架构演变 http://www.aminglinux.com/bbs/thread-8025-1-1.htmlf MHA架构 http://www.dataguru.cn/thread-457284-1-1.html 比较复杂的mysql集群架构 http://ask.apelearn.com/question/17026