当前位置:首页 > 问答 > 正文

数据库访问其实也没那么复杂,直接连还是间接连,各有各的道理和适用场景

来源于知乎专栏文章《架构师手记:数据库连接的明路与暗道》以及技术博客“码农翻身”的相关章节)

数据库访问其实也没那么复杂,直接连还是间接连,各有各的道理和适用场景,咱们就把它想象成去一个很热门的餐厅吃饭,你就明白其中的门道了。

直接连接:就像推门就进的路边小馆

直接连接,顾名思义,就是你的应用程序,比如一个网站的后台代码,直接拿着数据库的地址、用户名和密码,去敲数据库的门,数据库一看,哦,凭证对了,那就进来吧,然后你的程序就可以直接对数据库进行增删改查了。

这种方式特别简单直接,就像你去一家不用排队、不用预约的路边小馆子,你一推门,找个空位坐下,直接跟厨师或者服务员点菜,菜做好了直接端到你面前,中间没有传菜员,没有领位员,效率非常高。

(来源:《架构师手记:数据库连接的明路与暗道》中比喻为“单刀直入”)

这种方式的优点很明显:

  • 简单快捷: 开发起来非常快,几行代码就能连上,对于刚学编程的人或者做个小项目来说,是最自然的选择。
  • 性能好: 因为没有中间商赚差价,你的请求直接到达数据库,延迟最低,尤其是在应用程序和数据库放在同一台机器或者同一个内部网络的时候,速度飞快。

但它的缺点也同样突出,就像那小馆子:

  • 管理混乱: 如果你的系统变大了,不是一个小程序,而是有十个、一百个小程序(微服务),每个程序都直接连数据库,这就好比一百个食客同时挤进小馆子,都直接对着厨房喊,厨师肯定会忙晕,秩序大乱,数据库的连接数是有限的,这么多程序直接连,很容易把数据库“撑死”。
  • 安全风险高: 每个程序里都要写数据库的密码,万一有个程序有漏洞,黑客拿到了这个密码,就等于拿到了整个数据库的“钥匙”,所有数据都可能泄露,这就像把餐厅后门的钥匙给了很多人,很难保证安全。
  • 难以变动: 假如有一天,你觉得MySQL不好,想换成PostgreSQL,或者想给数据库搬个家,换一下地址,坏了,你得把所有直接连接这个数据库的程序代码都找出来,一个一个修改,然后重新部署,工作量巨大,还容易出错。

直接连接适合什么场景呢?(来源:技术博客“码农翻身”就是那种“小、快、灵”的项目:个人博客、毕业设计、公司内部用的、用户量不大的小工具,它的核心特点是系统简单,参与的服务少,对高并发和高可用性要求不高。

间接连接:就像高级餐厅的标准化流程

间接连接,就是在你的应用程序和数据库之间,加一个“中间人”,这个中间人通常叫做“连接池”、“代理”或者“数据访问层”,你的程序不再直接找数据库,而是找这个中间人,由它来统一管理所有对数据库的请求。

这就像你去一个高级餐厅吃饭,你进门先找领位员,他帮你安排座位;然后你看菜单,告诉服务员你要吃什么;服务员把订单送到后厨;后厨做好后,由传菜员把菜端给你,你自始至终不直接和厨师打交道。

(来源:《架构师手记:数据库连接的明路与暗道》中比喻为“经由管家”)

这种方式的好处是:

  • 管理高效: 中间人(比如连接池)会维护一批和数据库的“长连接”,重复使用,你的程序每次用完了就还回去,别人可以接着用,这样就避免了频繁创建和断开连接的开销,也防止了数据库被海量连接冲垮,高级餐厅的领位员能有效控制客流,不会让所有人都一窝蜂挤进去。
  • 安全性提升: 应用程序里不再需要存储数据库的真实密码,只需要有权限访问中间人就行,真正的数据库密码只保存在中间人那里,由运维人员严格管理,泄露的风险小了很多。
  • 灵活性强: 数据库再怎么变动,比如迁移、主从切换、甚至分库分表,你的应用程序都无需感知,你只需要告诉中间人新的规则,它就会帮你处理好一切,这就好比餐厅换了厨师或者厨房装修,你作为顾客完全感觉不到,点菜流程照旧。
  • 功能增强: 这个中间人还能干很多额外的事,比如记录所有访问日志、对慢查询进行监控、甚至对数据进行加密解密,餐厅的服务员除了传菜,还能帮你推荐菜品、解释口味。

间接连接也有代价:

  • 复杂性增加: 你需要额外部署和维护这个中间层,这本身就有技术成本和运维成本。
  • 性能略有损耗: 多经过一层,理论上会增加一点点网络延迟,但在绝大多数情况下,连接池带来的性能收益远大于这点损耗。

间接连接是现代中大型系统的标配。(来源:多家互联网大厂技术实践分享)当你的系统需要服务很多用户(高并发)、由很多个微服务组成、对数据安全和系统稳定性要求很高时,就必须采用间接连接的方式。

总结一下

所以说,数据库连接方式没有绝对的好坏,就像你不能说路边摊一定比米其林餐厅差,关键看你的需求。

  • 你想快速做个demo、搞个个人小项目,直接连接,轻装上阵,没毛病。
  • 你要构建一个企业级应用、一个支撑百万用户的平台,那就必须上间接连接,通过连接池、代理等中间件来保证系统的稳健、安全和可扩展。

理解了这两种方式背后的道理和适用场景,在实际工作中就能做出更合适的选择,而不是一味地觉得哪种方式更“高级”,技术选型,适合的才是最好的。

数据库访问其实也没那么复杂,直接连还是间接连,各有各的道理和适用场景