读写分离的三种方法

读写分离的三种方法内容摘要：

| :44978 | t_girl | Sleep | 203 | | NULL | | 16 | t_girl_user | :44979 | t_girl | Sleep | 164 | | NULL | | 17 | t_girl_user | :44980 | t_girl | Sleep | 210 | | NULL | +++++++++ 8 rows in set ( sec) 现在我们来读数据。 mysql select * from t。 +++ | id | c_str | +++ | 1 | C | +++ 1 row in set ( sec) 这个数据很明显是来自 C 的。 再插入一条记录 mysql insert into t(c_str) values (39。 wangwei39。 )。 Query OK, 1 row affected ( sec) mysql select * from t。 +++ | id | c_str | +++ | 1 | C | +++ 1 row in set ( sec) C 上的数据没有变。 还是没有数据。 现在跑到 B 上看看。 mysql show processlist。 +++++++++ | Id | User | Host | db | Command | Time | State | Info | +++++++++ | 2 | system user | | NULL | Connect | 1842 | Has read all relay log。 waiting for the slave I/O thread to update it | NULL | | 5 | root | localhost | t_girl | Query | 0 | NULL | show processlist | | 12 | t_girl_user | :44975 | t_girl | Sleep | 446 | | NULL | | 13 | t_girl_user | :44976 | t_girl | Sleep | 188 | | NULL | | 14 | t_girl_user | :44977 | t_girl | Sleep | 206 | | NULL | | 15 | t_girl_user | :44978 | t_girl | Sleep | 203 | | NULL | | 16 | t_girl_user | :44979 | t_girl | Sleep | 164 | | NULL | | 17 | t_girl_user | :44980 | t_girl | Sleep | 210 | | NULL | +++++++++ 8 rows in set ( sec) mysql select * from t。 +++ | id | c_str | +++ | 1 | B | | 2 | wangwang | | 3 | wangwei | +++ 3 rows in set ( sec) 数据被成功插入到 B 这个读写分离应该看得很清楚。 其他的功能等我测试了再总结吧。 如果要知道为什么连接多了才会进行分离的话，看看 手册 mysql 读写分离 MySQL Proxy 最强大的一项功能是实现“读写分离 (Read/Write Splitting)”。 基本的原理是让主数据库处理事务性查询，而从数据库处理 SELECT 查询。 数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 Jan Kneschke 在《 MySQL Proxy learns R/W Splitting》中详细的介绍了这种技巧以及连接池问题： 为了实现读写分离我们需要连接池。 我们仅在已打开了到一个后端的一条经过认证的连接的情况下，才切换到该后端。 MySQL 协议首先进行握手。 当进入到查询 /返回结果的阶段再认证新连接就太晚了。 我们必须保证拥有足够的打开的连接才能保持运作正常。 实现读写分离的 LUA 脚本： 复制代码 代码如下 : 读写分离 发送所有的非事务性 Select 到一个从数据库 if is_in_transaction == 0 and packet:byte() == and packet:sub(2, 7) == SELECT then local max_conns = 1 local max_conns_ndx = 0 for i = 1, do local s = [i] 需要选择一个拥有空闲连接的从数据库 if == and 0 then if max_conns == 1 or max_conns then max_conns = max_conns_ndx = i end end end 至此，我们找到了一个拥有空闲连接的从数据库 if max_conns_ndx 0 then = max_conns_ndx end else 发送到主数据库 end return 注释：此技巧还可以用来实现其他的数 据分布策略，例如分片 (Sharding)。 使用 MySQL Proxy 解决 MySQL 主从同步延迟 文章分类 :数据库 MySQL 的主从同步机制非常方便的解决了高并发读的应用需求，给 Web 方面开发带来了极大的便利。 但这种方式有个比较大的缺陷在于 MySQL 的同步机制是依赖 Slave 主动向 Master 发请求来获取数 据的，而且由于服务器负载、网络拥堵等方面的原因， Master 与 Slave 之间的数据同步延迟是完全没有保证的。 短在 1 秒内，长则几秒、几十秒甚至更长都有可能。 由于数据延迟问题的存在，当应用程序在 Master 上进行数据更新，然后又立刻需要从数据库中读取数据时，这时候如果应用程序从 Slave 上取数据 (这也是当前 Web 开发的常规做法 )，就可能出现读取不到期望的数据，造成程序运行异常。 解决这个问题有多种方式，比如最简单的在所有的 insert 和 update 之后，强制 sleep 几秒钟。 这是非常粗 鲁的方式，对于更新操作不是很高的中小型系统，此方式基本能解决问题。 另外一种方式是应用程序把被更新的数据保存在本机的内存 (或者集中式缓存 )中，如果在写入数据完成后需要直接读取数据，则从本机内存中读取。 这种方式的缺点是极大的增加了应用程序的复杂度，而且可靠性并不能完全得到保障。 使用 MySQL Proxy 可以很方便的解决这个问题。 MySQL Proxy 是基于 MySQL Client 和 MySQL Server 之间的代理程序，能够完成对 Client 所发请求的监控、修改。 从 Client 角度看， 通过 Proxy访问 Server 和直接访问 Server 没有任何区别。 对于既有的程序而言，只要把直接被访问的 Server的 IP 地址和端口号换成 Proxy 的 IP 地址和端口号就可以。 MySQL Proxy 的工作原理也较简单。 在 Proxy 启动时可以指定 Proxy 所需要使用的 lua 脚本，在 lua脚本中预先实现 6 个方法： * connect_server() // 接收到 Client 的连接请求时调用 * read_handshake() // * read_auth() // 读取 Client 的认证信息时调用 * read_auth_result() // 读取认证结果时调用 * read_query() // 读取 Client 的 query 请求时调用 * read_query_result() //读取 query 结果时调用 当 Proxy 接收到 Client 请求时，在请求的不同的阶段会调用上面的不同方法。 这样 Proxy 使用者就可以根据自己的业务需 求，自由的实现这 6 个方法达到目的。 通过在 read_query()中加入代码，我们可以截取出当前的请求是 insert、 update 还是 select，然后把 insert 和 update 请求发送到 Master 中，把 select 请求发送到 Slave 中，这样就解决了读写分离的问题。 在解决了读写分离后，如何解决同步延迟呢。 方法是在 Master 上增加一个自增表，这个表仅含有 1 个的字段。 当 Master 接收到任何数据更新的请求时，均会触发这个触发器，该触发器更新自增表中的记录。 如下 图所示： mysql_proxy_write 由于 Count_table 也参与 Mysq 的主从同步，因此在 Master 上作的 Update 更新也会同步到 Slave上。 当 Client 通过 Proxy 进行数据读取时， Proxy 可以先向 Master 和 Slave 的 Count_table 表发送查询请求，当二者的数据相同时， Proxy 可以认定 Master 和 Slave 的数据状态是一致的，然后把select 请求发送到 Slave 服务器上，否则就发送到 Master 上。 如下图所示： mysql_proxy_read 通过这种方式，就可以比较完美的结果 MySQL 的同步延迟不可控问题。 之所以所“比较完美”，是因为这种方案 double 了查询请求，对 Master 和 Slave 构成了额外的压力。 不过由于 Proxy 与真实的 Mysql Server 采用连接池的方式连接，因此额外的压力还是可以接受的。 MySQL MasterMaster Replication Manager(MMM) 一 . 引言 : MasterSlave 的数据库机构解决了很多问题，特别是 read/write比较高的 ： 写操作全部在 Master结点执行，并由 Slave数据库结点定时 (默认 60s)读取 Master的 binlog 将众多的用户读请求分散到更多的数据库节点。