IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

2012年数据库技术大会 百度和淘宝介绍的中间件对比

MySQLOPS 数据库与运维自动化技术分享 2012-04-26 23:38:05 累计浏览 3,997 次
本机暂存

2012年4月13号开幕的DTCC(数据库技术大会)云集了各方豪杰,尤其今年的MySQL专场爆满,本人由于晚到一小会就已经没有位置了,站着听了几场。给我感觉干货还是比较多,分享时间也比较长,但是真正消化的时间太少,有些项目可能这次才拿出来分享,对于那些不是很理解主题的人在这么短的时间弄清楚有点难,所以也建议各位分享者可以在开幕之前提前透露一部分分享信息。今年嘉宾有以往的淘宝、阿里巴巴、支付宝,还有新生代的百度、腾讯、京东、新浪微博等相关企业的分析专场,这些企业最少都能抱着开发的心态去分享给所有技术人,分享多少就不必太在意。

和各位去现场的很多人一样,都想了解其他公司是如何使用某种技术、某种架构、做了何种改进、开发成本\周期。淘宝、百度、万里开源(商业)自己开发的数据库中间件都能足够吸引很大一部分的注意力。他们提出数据库中间件的业务背景是“大数据量、高并发、高负载、低可用、高成本、高延迟”等其中任何一种或多种情况。所以也建议各种小企业不要动不动就要自己开发数据库中间件,

百度Topic开发的中间件实现的功能:

  1. 实现集群读写分离,
  2. 实现MySQL连接池,
  3. 实现负载均衡,
  4. 实现访问控制,
  5. 可集群化部署、运维

百度Topic数据库中间层的关键要求是:对数据库应用透明,实现高并发、低延迟。

  1. 首先对于中间件来讲不应该存在并发连接瓶颈,所以在设计中间件的时候可以采用进程并发的设计,当然进程并发会有个最大值达到最高性能,当达到最大值时,该如何处理之后应用程序过来的请求?在这部分“集群”的属于意味着一堆机器做主从复制,并不是MySQL Cluster。
  2. 应用程序在读/写请求时读写分离策略能够尽量利用集群中各点得优势,以读为主的应用使用读写分离策略能得到显著效果,在以写为主的应用就尽量让写请求分布在多台机器上,可以使用异步更新数据库的方法来尽量处理短时间内大量的写请求。在一次写请求之后立刻进行读该数据的请求,这种情况为了避免延迟产生的问题,可以在主库上读取。
  3. 负载均衡策略是基于数据库当前连接数来实现的,在新建连接时选取集群中同类角色中“当前连接数/权重”最小的数据库,在MySQL集群中有实例挂掉时,由Dbproxy将该实例权重置为无限大,Dbproxy需要有心跳检测的功能和自动切换。
  4. 由于中间件在创建连接的时候消耗一定的资源,所以要保证不频繁创建连接,引入了中间件连接池,在这期间可能会遇到这样的问题,某个用户建立的连接都被cache了,但是新来得连接是以其他用户身份登录的,这个用户权限比连接cache中的用户权限要小,所以不能直接使用连接池内的连接,在百度Topic应用的了三种hash策略,保证取到的连接可以正确使用,read/write、用户权限、连接属性,如client_found_rows。当然在引用中我们可以不用考虑这部分,只考虑不同应用直接分配几个长连接就可以了,尽量适用自己环境就可以了,不用考虑太通用了。
  5. 当业务确实有高并发的情况,必须要考虑控制好并发数,并且在达到最大并发数的时候要如何处理,百度topic的处理方式是让所有等待请求进入各自的进程队列。由于集群的数量众多,每个机器进行管理的话,消耗太多资源,所以要考虑到集中式部署,实现配置信息热加载、支持连接多个数据库集群、自身压力信息准确输出、流量控制

淘宝开发的tddl分为3层:Matrix层、GROUP 层、Atom层。实现功能包括:路由规则、数据迁移、动态扩容、合并结果、读写分离、负载均衡(利用节点权重)、自动切换(读、写)、动态新增slave节点、动态修改用户名\密码、执行次数统计\限制、动态阻止某个SQL执行、集群复制。Tddl这个数据层架构比较复杂,淘宝最终实现中间件组件解耦。目前应该已经比较成熟了,某些功能实现细节无法了解,有兴趣的人可以参考淘宝分布式存储与中间件TDDL

万里开源使用的Sqlproxy分布式数据库中间件实现功能:基于MySQL通信协议、解决大数据量、高负载下的数据分布和读写分离、自动处理网络故障和软件故障、基于Replication实现自动数据冗余。与百度Topic中间件共同点是:读写分离、自动切换、集群之间的Replication

以上列出三个公司的中间件,可能有些出入,对比发现中间件中共同实现的功能有:路由规则、故障转移、集群复制、读写分离。其中路由规则实现有路由表、hash、B-tree方法,路由表实现比较简单、只能进行唯一搜索,但是也要考虑单点、负载问题,游戏行业可以使用该方法,在扩展节点的时候不必进行数据迁移。Hash方法实现缺点是在增加数据节点的时候需要迁移部分数据、只能进行唯一搜索,优势是不会有单点问题,因为是通过hash算法映射的,在效率上也比路由表高。B-tree效率不高,但能实现范围查找。故障转移需要做心跳检测与主从自动切换。读写分离大部分公司有条件的公司自己会独立开发读写分离的中间件,没有条件的公司可以自己用程序简单实现,也可以使用amoeba和MySQLProxy,前者在淘宝平台生产线上,后者都建议不要使用,效率不理想,而且目前还是alpha版本。技术大会结束之后,我相信很多公司也开始倒腾中间件了,技术人也开始在公司推进这项技术,希望各大公司能够真正将这些中间件开源出来,分享给我们IT人员

同分类推荐文章

  1. 使用deepseek进行Oracle恢复,引起重大故障 (2026-06-22 10:56:00)
  2. 接手一个只差临门一脚的数据库恢复 (2026-06-18 00:13:09)
  3. 我做了一个 AI 版的 StarRocks 升级风险扫描工具,直接帮我定位到一个风险 (2026-06-15 01:00:00)

查看更多 数据库 文章 →

建议继续学习

  1. 架构师的思考 (累计阅读 10,521)
  2. 豆瓣的Url结构方式一览 (累计阅读 7,935)
  3. nginx自定义模块编写-根据post参数路由到不同服务器 (累计阅读 7,349)
  4. MHA自动Failover过程解析 (累计阅读 4,152)
  5. 级联多个应用 (累计阅读 3,604)
  6. 深入理解 GRE tunnel (累计阅读 3,528)
  7. 规则引擎简介 (累计阅读 3,474)
  8. Redis高可用性之Failover过渡方案 (累计阅读 3,269)
  9. 浅析Linux Kernel 哈希路由表实现(二) (累计阅读 3,029)
  10. windows下设置路由 (累计阅读 2,779)