mysql读写分离和组复制_数据库主从复制，读写分离，负载均衡，分库分表分别表达的什么概念？...

谢邀，这是个好问题，而且这个问题好在即使概念非常容易理解，但是这几个不同的概念细节太多太多，而且理解了概念，自己要用，又需要做很多的调研评估和开发工作。作为在这个领域爬坑多年的人，我这里就先介绍下概念，再提供几个开源工具和云服务吧。

先来说这些架构解决的问题吧，传统数据库如Mysql(以下工具也会以Mysql为主)，存在的问题就是单机部署，单进程，这样就存在一些问题：资源利用不灵活，有可能cpu的性能还有富余，但是磁盘已经顶不住读压力或写压力了，有可能磁盘的性能还有富余，但是cpu的性能已经顶不住了。还有可能cpu和磁盘都很富余，但是写入的数据量太大，直接撑爆磁盘上限。

资源有最大上限，cpu最多用到比如64核的机型，磁盘最高几百T，再高的话不好意思，没有更屌的机器了，但是用户的数据和查询是没有上限的。

连接池资源的上限，为何要把连接池单独提出来说，原因就是业务量一大，

容灾类的问题，虽然事务可以保证重启后数据不丢，但是业务线上跑，重启等不起。

而这个问题所提的几个概念，正是对如上传统数据库痛点的解决方法。主从复制(replication)，解决的是容灾类的问题，容灾需要保证数据库切换的实时性和数据的一致性，一致性的强弱还催生了几种不同的复制模式(asynchronous, semisynchronous, group replication)

读写分离(read write spliting)，是一种业务类应用解决读流量单机无法承受的方式，学名叫 scale out ，读写分离类的业务是架设在主从复制的基础上

负载均衡 ( load balance)，也是一个非数据库的概念，但是在数据库层面，如果有一个通用的中间层，那么也适用。

这三者的关系基本可以参考这几幅图：

这幅图的load balance做在了业务层，而读写的路由逻辑由业务层在控制。

这幅图，则由一个通用的中间层解决了读写分离的问题，顺便也做了数据库的负载均衡，从这里看出读写分离是数据库负载均衡的一种解决方式

那么第三步，如何使用这些特性呢，这几个特性是好的，但是要使用这些特性，会同时带来很多的问题，而且先提前声明一句，目前没有完美的解决方案，问题如下：之前只要管启动数据库进程还有挂掉重启即可，现在还得设置好复制通道，设置容灾方式，如何切换，如何回切

读写分离还需要配置中间层，中间层要感知复制通道的方向，感知复制拓扑，还得在切换主从的时候把写切换过去

最后到了介绍现成工具的时间了，主要推荐以下三款proxy类工具：

Haproxy，Maxscale以及Sqlproxy

提供的方法大同小异，有的能够通过proxy来建立复制通道，通过proxy来容灾，自包含，可以大大简化运维类的工作量。比较推荐使用Proxy模式来做读写分离，而不是业务中间件的形式(如TDDL)，因为业务中间件的侵入性比较高，容灾和复制通道仍然需要依赖运维手工，而现在比较好的proxy类读写分离工具，很多都是自包含的，可以自动建立复制通道。

最后，至于分库分表，这是一个更大的命题了，可以参考我的专栏文章：浅谈分布式数据库该如何学习和实践 上篇