(先对数据库操作进行读写分离,使得具有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可操作的账号:
未完待续......
转载于:https://blog.51cto.com/5660061/2390556