在WEB开发中，数据库的数据读写和传输一向是瓶颈，在此基础上的解决方案基本都是数据库连接层的设计，一个公司数据库连接层的强弱与否可以标识这个公司的全局规划的“工艺水平”到达一个什么程度了。
1.人人网
关键词：ice中间层，统一配置数据源，开发者不关心分库分表
与很多大型的网站一样，人人网的系统全部是由开源软件构建的。使用Nginx做前端接入，resin做容器，Memcached做通用 cache，MySQL做数据库，使用Linux操作系统。
除了上述的部分外，人人网还有一个与众不同的中间层。中间层以服务的形式存在，位于MySQL和resin中间，提供高并发低成本的数据访问层。
数据库用到了部分自身缓存机制，利用innodb的pool和MySQL的Query Cache。在中间用到Memcached，以及基于ICE通讯框架由自己编写的包含业务逻辑处理能力的缓存服务，在自行开发的分布式KV系统中也会充分利用内存Cache加速。
2.百度
关键词：dbproxy，服务器都是flash卡，DBA与开发者都不关心分裤分表（半自动）
百度的dbproxy利器，将MySQL的管理半自动化，HA等功能一应俱全，再加上
SSD等硬件支持，性能相当不一般。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上面做与业务更接近的缓存, 相比数据库的底层缓存很多时候更有效。
3.盛大-技术保障中心
关键词：无中间件，每个系统一个数据库，开发者严重关心分库分表
4.新浪
关键词：无中间件 分表要开发者自己做
5.金山
关键词：无中间件 分表要开发者自己做
6.腾讯
关键词：TTC(Tencent Table Cache)
TTC是提供高速数据访问服务的通用cache server。特点是采用epoll和异步状态机模式提高并发能力。TTC看上去是一个数据库缓冲层，由于资料有限，只能如此分析。
7.淘宝、支付宝
关键词：JBoss作为中间件，有数据路由层，数据库Oracle 与 MySQL
在网络上许多文档里都有提到阿里内部是有一数据路由层的，另外JBoss的使用也使得他们轻便不少（可惜当年哥在淘宝时只搞的是搜索，不使用DB）
目前淘宝和支付宝使用的Oracle数据库为Oracle 11g。借助Oracle
11g新增的PL/SQL 相关的某些新特性如网络日志分析工具，为客户和内部技术人员带来了更加快速简便的全新体验;利用Oracle
Advanced Compression技术，不仅节省大量存储空间，而且提升了查询性能。
豆瓣网：BeansDB与NoSQL的应用与发展
BeansDB主要由Server端和Client端两个部分组成。Server端用
C编写，使用Memcached的通讯协议，任何支持Memcached的Client端都可以与BeansDB的Server端同步来获取和存储数据。
在Client端方面的主要差别是分布式的逻辑实现方面。目前，BeansDB的Client端主要是豆瓣自己用Python语言的实现。Client端
的运作方式是写数据时写入多份，读的时候只读一份，用其他任何语言实现也和简单。
目前，BeansDB在豆瓣主要部署了两个集群：一个集群用于存储数据库中的大文本数据，比如日记、帖子一类；另外一个豆瓣FS集群，主要用于存储媒体文件，比如用户上传的图片、豆瓣电台上的音乐等。
注：上面的内容来自明查暗访，决无侵犯之意，旨在提供给需要统一规划整体架构的架构师一个帮助。