共计 2302 个字符，预计需要花费 6 分钟才能阅读完成。
为什么要引入数据库中间件，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
不少朋友经常会问我以下问题：
58 到家有没有使用数据库中间件
使用了什么数据库中间件，是自研，还是第三方
怎么实现的，是基于客户端的中间件，还是基于服务端的中间件
使用中间件后，join/ 子查询 / 集函数 / 事务等问题是怎么解决的
你是不是也有类似的疑问?
然而，“究竟为什么要引入数据库中间件”却很少有人问及。 “架构师之路”文章思路，以解决“为什么”为优先，借着近期撰写互联网分层架构系列文章，讲一讲这个核心问题：
究竟为什么要引入数据库中间件
经过连续分层架构演进，DAO 层，基础数据服务化，通用业务服务化，前后端分离之后，一个业务系统的后端结构如上：
web-view 层通过 http 接口，从 web-data 获取 json 数据 (前后端分离)
web-data 层通过 RPC 接口，从 biz-service 获取数据 (通用业务服务)
biz-service 层通过 RPC 接口，从 base-service 获取数据 (基础数据服务)
base-service 层通过 DAO，从 db 获取数据 (DAO)
db 存储数据
随着时间的推移，数据量会越来越大，base-service 通过 DAO 来访问 db 的性能会越来越低，需要开始考虑对 db 进行水平切分，一旦 db 进行水平切分，原来很多 SQL 可以支持的功能，就需要 base-service 层来进行特殊处理：
有些数据需要路由到特定的水平切分库
有些数据不确定落在哪一个水平切分库，就需要访问所有库
有些数据需要访问全局的库，拿到数据的全局视野，到 service 层进行额外处理
hellip;
更具体的，对于前台高并发的业务，db 水平切分后，有这么几类典型的业务场景及应对方案。特别强调一下，此处应对的是“前台”“高并发”“db 水平切分”的场景，对于后台的需求，将通过前台与后台分离的架构处理，不在此处讨论。
一：partition key 上的单行查询
典型场景：通过 uid 查询 user
场景特点：
通过 patition key 查询
每次只返回一行记录
解决方案：base-service 层通过 patition key 来进行库路由
如上图：
user-service 底层 user 库，分库 patition key 是 uid
uid 上的查询，user-service 可以直接定位到库
二、非 patition key 上的单行查询
典型场景：通过 login_name 查询 user
场景特点：
通过非 patition key 查询
每次只返回一行记录
解决方案 1：base-service 层访问所有库
如上图：
user-service 通过 login_name 先查全库
结果集在 user-service 再合并，最终返回一条记录
解决方案 2：base-service 先查 mapping 库，再通过 patition key 路由
如上图：
新建 mapping 库，记录 login_name 到 uid 的映射关系
当有非 patition key 的查询时，先通过 login_name 查询 uid
再通过 patition key 进行路由，最终返回一条记录
解决方案 3：基因法
关于“基因法”解决非 patition key 上的查询需求详见《分库后，非 patition key 上访问的多种解决办法》。
三、patition key 上的批量查询
典型场景：用户列表 uid 上的 IN 查询
场景特点：
通过 patition key 查询
每次返回多行记录
解决方案 1：base-service 层访问所有库，结果集到 base-service 合并
解决方案 2：base-service 分析路由规则，按需访问
如上图：
base-service 根据路由规则分析，判断出有些数据落在库 1，有些数据落在库 2
base-service 按需访问相关库，而不是访问全库
base-service 合并结果集，返回列表数据
四、非 patition key 上的夸库分页需求
关于分库后，夸库分页的查询需求，详见《业界难题，夸库分页的四种方案》。
五、其他需求 hellip;
本文写到这里，上述一、二、三、四、五其实都不是重点，base-service 层通过各种各样的奇技淫巧，能够解决 db 水平切分后的数据访问问题，只不过：
base-service 层的复杂度提高了
数据的获取效率降低了
当需要进行 db 水平切分的 base-service 越来越多以后，此时分层架构会变成下面这个样子：
底层的复杂性会扩散到各个 base-service，所有的 base-service 都要关注：
patition key 路由
非 patition key 查询，先 mapping，再路由
先全库，再合并
先分析，再按需路由
夸库分页处理
hellip;
这个架构图是不是看上去很别扭? 如何让数据的获取更加高效快捷呢?
数据库中间件的引入，势在必行。
这是“基于服务端”的数据库中间件架构图：
base-service 层，就像访问 db 一样，访问 db-proxy，高效获取数据
所有底层的复杂性，都屏蔽在 db-proxy 这一层
这是“基于客户端”的数据库中间件架构图：
base-service 层，通过 db-proxy.jar，高效获取数据
所有底层的复杂性，都屏蔽在 db-proxy.jar 这一层
当数据库水平切分，base-service 层获取 db 数据过于复杂，成为通用痛点的时候，就应该抽象出数据库中间件，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。
关于为什么要引入数据库中间件问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
