（先对数据库操作进行读写分离，使得具有master角色的主服务器主要用于执行写操作，这样就能大大减少主服务器由于读操作而产生的负载过大的问题。读交给slave。对于多台读服务器，还要把读操作的压力分摊到不同的slave服务器上。通常来说，读写分离和多台slave服务器的读负载均衡也是两个不同的问题，也要分别进行解决。先读写分离，再将读操作平均分摊到各slave服务器）

redis和memcache差距不大，还具有更多的数据类型，还能持久化，主从复制，集群等功能

（比如库存的查询就必须在主库上进行，如果从库上就可能出现超卖的情况。因此，不是什么查询都要进行读写分离的。所以，由开发人员自行判断比较灵活）

还可以通过数据库中间层完成读写分离（如mysql proxy、maxscale、one proxy、proxySQL等）：

（通过中间层对sql语句的解析，如果是select操作，则发送到从服务器处理，非select操作，全发送到主服务器处理。对于存储过程这种无法通过调用语法分析出是读操作还是写操作的sql就只能全部由主数据库服务器去完成。由于存储过程可能很大一部分只是进行查询处理，这无疑加大了主数据库服务器的负载。虽然使用中间层很方便，但也会付出一些代价）

（由于读写分离是通过中间层自动进行的，而中间层无法区分哪些是对延迟敏感的，哪些不敏感，所以无法把对延迟敏感的查询自动分配到主库上执行，而要实现这些功能就要在查询语句中加入提示的关键字，而增加提示不得不对原来程序进行修改，这样就失去了对程序透明的好处了）

常用的读服务器负载均衡方式：

对于数据库服务器来说，读负载和写负载是两个完全不同的问题，所以，对于读负载和写负载要分开对待，因为写操作只能在master上进行，而读操作可以在master上，也可以在slave上，因此，相对写负载，解决读负载更加容易。

（lvs是工作在网络协议的四层上的，只进行流量分发，不会对数据包内容进行解析，性能强，对内存和cpu消耗低，当然，由于不会对数据进行解析，所以也不会知道数据包中sql的具体内容，自然不能做读写分离）

(lvs只分发请求，流量并不从他本身出去，所以无流量消耗，这点就保障了io性能不会受到大流量影响)

主从复制流程就不贴出来了...

在.100和.101服务器都安装lvs管理工具：

加载ipvs模块（所有参加lvs集群的三台服务器都要安装）：

lvs脚本的编写：

        先看下slave（.101服务器）上的脚本：

                （注意，这个脚本要有可执行权限）

                执行脚本：

                查看：

        同样在.102上也要执行：

                查看：

        .100上的keepalived配置：

                查看check_slave脚本：

                ......

        .100上建立lvs可操作的账号：

        未完待续......