MaxScale 关于Linux下MySQL主备集群负载均衡之读写分离 _读写分离

写在前面

分享一些MySQL(MariaDB)集群主从结构数据读写分离的笔记，关于读写分离：
一如果对于读密集型应用，可以容忍从库异步复制延迟导致的脏数据，读写分离是一种不错的负载均衡方式
如果对于脏数据零容忍，不建议这样搞，出了故障还需要考虑这个因素，不太方便定位问题
二是读写分离需要做体量评估，不能为了读写分离去读写分离，系统负载正常，完全没必要，如果扩了资源还是频繁的sql timeout，读写分离是解决方法之一
博文偏实战，内容涉及：为什么需要负载均衡？MaxScale配置主从集群的读写分离
食用方式：了解linux，MySQL
理解不足小伙伴帮忙指正

「只要足够开心,烦恼就追不上哦 ^_^ 」
一、为什么需要负载均衡？
需要负载均衡的理由：

「可扩展性」：负载均衡对某些扩展策略有所帮助，比如流量控制，例如数据库读写流量分离时从备库读数据,降低主库读的工作负载，提升写的负载能力，在比如大型的Web应用，对于搜索类请求需要最小化延迟，可以负载到最近的数据中心，对于上传来讲需要最大化吞吐量,需要负载到带宽没有占满的链路，即使跳的远一点。
「高效性」：负载均衡有助于更有效地使用资源，控制流量被路由到何处。如果服务器处理能力各不相同，这就尤为重要：你可以把更多的工作分配给性能更好的机器。
「高可用性」: 一个灵活的负载均衡解决方案能够使用时刻保持可用的服务器。
「匿名性」：客户端无须知道是否存在负载均衡设置。负载均衡器给客户端看到的只是一个代理一个虚拟服务器。
「一致性」：如果应用是有状态的（数据库事务，网站会话等），那么负载均衡器就应将相关的查询指向同一个服务器，以防止状态丢失。应用无须去跟踪到底连接的是哪个服务器。

文章插图

从集群角度考虑，MySQL做主备集群复制如果只用作备份，有些浪费，和负载均衡结合使用一种相辅相成的作用。
所以MySQL的负载均衡架构通常和数据分片及复制紧密相关。我们今天要讲的读/写分离策略即属于负载均衡的一个实现。
有些负载均衡技术本身能够实现这一点，有些需要应用自己知道哪些节点是可读的或可写的。
客户端读写分离
常见的读写分离一种是通过客户端去区分读写，比如上面那个图，写在主库，读通过负载均衡到多个从库。
在应用层面粗粒度通过配置不同数据源分离读写实现，同时还需要考虑从库异步复制导致的脏数据问题，需要监控延迟复制来决策读写的分配。可以考虑在编码层次基于查询，版本，请求时间戳，会话等做一些读写策略，不能容忍脏数据的读可以放到写节点
从库的负载可以通过DNS负载、LVS+Keepalived、硬件负载均衡器F5、TCP代理(HAproxy,Nginx)、或者在应用中管理从库负载均衡。比如做简单的数据源池做线性负载等。
服务端读写分离
另一种是通过在服务端去区分，通过MySQL Proxy的方式实现。客户端的请求都到MySQL Proxy上，如果客户端要执行查询数据的请求，则交给从服务器来处理；如果客户端要对数据进行增、删、改的操作，则交给主服务器来处理；
MySQL Proxy相关的工具有很多，有自带的mysql-proxy插件，也有MyCat等中间件，今天和小伙伴分享通过MaxScale来实现的读写分离,不管使用那种方式，个人觉得如果对于脏数据零容忍的应用更多的应该在硬件资源上面考虑，并且大多数的读写分离解决方案都需要监控延迟复制来决策读写的分配。做的不好，总感觉有点不靠谱...
【MaxScale 关于Linux下MySQL主备集群负载均衡之读写分离】二、配置主从集群的读写分离

文章插图

MariaDB MaxScale是MariaDB企业服务器、MariaDB ColumnStore和MariaDB Xpand的高级数据库代理，为它们提供企业高可用性、可伸缩性、安全和集成服务，同时抽象出底层数据库基础设施，以简化应用程序开发和数据库管理。
官方地址：https://mariadb.com/
读写分离工作原理
由 MaxScale面向客户端提供服务，收到SQL写请求时，交给master 服务器处理，收到SQL读请求时，交给slave服务器处理，这里我们已经搭建好一个主从结构的MySQL集群，关于集群搭建小伙伴可以看我之前的文章，有详细教程，所以这里只需要安装MaxScale,然后配置启动测试就OK