使用dbproxy来处理高并发数据库请求

大规模Web应用系统, 几乎都会遇到数据库瓶颈问题. 在早期, 通过数据库配置优化, 表优化, 索引优化等软件方法, 可以解决一些问题. 马上, 数据库瓶颈迫使不得不把MySQL和Apache单独部署到不同的机器, 形成Web服务器(Web Server)和数据库服务器(DB Server)的物理分离, 这样就能解决大部分的问题. 但是, 在继续发展时, 一台Web服务器和一台数据库服务器也不能满足高并发的访问量了.

这时, 问题首先是计算能力的问题, 也就是硬件不够用的问题. 所以, 需要上多台Web服务器和多台数据库服务器.

有时候, 网站可以纵向切分, 这样, 任何两台服务器(一台Web Server + 一台DB Server)单独配置, 便能运行一个应用. 比如某两台运行着论坛程序, 某两台运行着新闻程序.

很多情况下, 并不能纵向切分, 每一台的Web Server的角色和功能都是一样的, 没有差别, DB Server也是一样. 理想的情况下, 同种压力的SQL语句平均分布到每一台DB Server, 那就能解决高并发数据库请求问题了

dbproxy的作用便是如此: 合理地分配数据库请求给所有的DB Server, 使得在请求的数量等于或者小于所有DB Server的计算能力总和时, 服务能够正常运行.

第一种方式的dbproxy: Web Server上的数据库客户端(如PHP脚本)拥有选择DB Server的智能.

这种方式实现简单, 完全用Web脚本实现, 脚本自己判断应该连接其中的一台或者几台DB Server, 请决定把SQL请求发给谁. 这种方式因为性能问题, 所以应用不是很广.

第二种方式的dbproxy: SQL代理进程

类似HTTP代理服务器, 这种方式的dbproxy独立运行, 所以客户端请求将不再直接和DB Server连接, 而是通过它中转. 这样的dbproxy, 首先要拥有解析协议(也即SQL)的能力, 这也带来一个特点, dbproxy可以与后端的MySQL连接, 但却接收前端(如PHP脚本)发来的Oracle数据库的SQL请求.

当然, dbproxy的主要功能还是在SQL分发方面. 另外, 还可以在dbproxy上面做与业务更接近的缓存, 相比数据库的底层缓存很多时候更有效.