从应用层面来实现数据库负载均衡
问题的由来：
以前维护的系统经常宕机，究其原因是开发管理不善，造成程序质量不佳。撇开制度管理的原因不谈（那是技术人员无法解决的），其表象原因有二：一、授权程序设计不佳，造成整个系统运行缓慢；二、有很多程序中有几个大表的join语句，只要这种程序多跑几个，管你是什么IBM小型机通通垮掉。
问题的解决方案：
我曾想把所有系统翻一遍，但由于成本原因不可行。后来上了BIGIP，算是解决了中间件的负载问题，但中间件的负载一解决，所有的压力都集中到数据库，经常是数据库的问题造成整个系统垮掉。其表象原因为有很多程序中有几个大表的join语句，只要这种程序多跑几个，管你是什么IBM小型机通通垮掉。直到我离开维护岗，这个问题也没解决。现如今闲下来，我总在想，能用什么便宜的方法来实现数据库负载均衡，使得一些病入膏肓的系统能死得慢一点。
1、多写少读。
其实，数据库之所以压力大，主要是读取的原因造成的。因为写入总是很快的，主要是频繁的多表联合查询造成数据库资源消耗。那么除了在数据表中增加冗余字段来避免联合查询外，有没有比较好的办法来解决呢？
假如能有2个或多个数据库，都有一样的表，互为镜像，那么应用程序在写入数据时可以写入多个数据库，读的时候可以按系统别或压力值来分别读取不同的数据库，那么相当于把查询的压力分散开，便于问题的定位和负载均衡，可这带来一个问题，那就是如何保证这多个数据库的表的记录都是一样的？
假如我们在应用和数据库之间再加入一层，把所有的写入请求都向这一层转发，这一层我们姑且称之为负载控制层，当负载控制层向多个数据库写入时，发现其中一个数据库有问题，所有操作立即回滚，以保证所有数据库的数据一致。
并且在这一层有日志功能，如发生断电或其它灾难性故障，可根据日志来前滚或后滚，保证所有数据库数据一致。
读取数据库的时候就不通过这一层来转发了，直接在应用底层根据对照表或数据库压力表来决定读哪一个数据库，这样可以保证系统架构不会太复杂。
这只是我临时想到的一些东西，有不妥之处，欢迎大家指正。