聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长
IT技术精华
设为首页
加入收藏
订阅本站
IT技术文章精选
2024
每日Shell
关于
热门搜索:
IT技术
Linux
系统
算法
架构
数据库
优化
python
分布式
php
您的位置:
首页
» 技术文章 » 正文
究竟能不能,不引入数据库中间件?
2021-07-30 23:11
浏览: 2982291 次
我要评论
(0 条)
字号:
大
中
小
#中间件
2
#数据库
11
#架构
35
#架构师
1
不少朋友经常会问我以下问题:
(1)快狗打车
有没有使用
数据库中间件?
(2)使用了什么
数据库中间件,是自研,还是第三方?
(3)怎么实现的
,是基于客户端的中间件,还是基于服务端的中间件?
(4)使用中间件后,join/子查询/集函数/事务等
问题是怎么解决的?
(5)…
你是不是也有类似的疑问?
“究竟
为什么
要引入数据库中间件”却很少有人问及,今天和大家聊聊:
究竟为什么要引入数据库中间件
?
经过连续分层架构演进,
DAO层
,
基础数据服务化
,
通用业务服务化
,
前后端分离
之后,一个业务系统的后端结构如上:
(1)web-view层通过http接口,从web-data获取json数据(前后端分离);
(2)web-data层通过RPC接口,从biz-service获取数据(通用业务服务);
(3)biz-service层通过RPC接口,从base-service获取数据(基础数据服务);
(4)base-service层通过DAO,从db获取数据(DAO);
(5)db存储数据;
随着时间的推移,
数据量会越来越大
,base-service通过DAO来访问db的
性能会越来越低
,
需要开始
考虑
对db进行水平切分
,一旦db进行水平切分,
原来很多SQL可以支持的功能,就需要base-service层来进行特殊处理
:
(1)有些数据需要
路由到特定
的水平切分库
(2)有些数据不确定落在哪一个水平切分库,就需要
访问所有库
(3)有些数据需要访问全局的库,拿到
数据的全局视野
,到service层进行额外处理
(4)…
更具体的,对于前台高并发的业务,db水平切分后,有这么几类典型的业务场景及应对方案。特别强调一下,此处应对的是
“前台”“高并发”“db水平切分”
的场景,对于后台的需求,将通过前台与后台分离的架构处理,不在此处讨论。
第一,partition key上的单行查询。
典型场景
:通过uid查询user。
场景特点
:
(1)通过
patition key
查询;
(2)每次只返回
一行
记录;
解决方案
:base-service层通
过patition key来进行库路由。
如上图:
(1)user-service底层user库,分库patition key是uid;
(2)uid上的查询,user-service可以直接定位到库;
第二,非patition key上的单行查询。
典型场景
:通过login_name查询user
场景特点
:
(1)通过
非patition key
查询;
(2)每次只返回
一行
记录;
解决方案1
:base-service层
访问所有库。
如上图:
(1)user-service通过login_name先查全库;
(2)结果集在user-service再合并,最终返回一条记录;
解决方案2
:base-service
先查mapping库
,
再通过patition key路由。
如上图:
(1)新建mapping库,记录login_name到uid的映射关系;
(2)当有非 patition key的查询时,先通过login_name查询uid;
(3)再通过patition key进行路由,最终返回一条记录;
解决方案3
:基因法
关于“基因法”解决非patition key上的查询需求详见《
用uid分库,uname上的查询怎么办?
》。
第三,patition key上的批量查询。
典型场景
:用户列表uid上的IN查询。
场景特点
:
(1)通过
patition key
查询;
(2)每次返回
多行记录;
解决方案1
:base-service层
访问所有库
,结果集到base-service合并。
解决方案2
:base-service
分析路由规则,按需访问。
如上图:
(1)base-service根据路由规则分析,判断出有些数据落在库1,有些数据落在库2;
(2)base-service
按需访问相关库,而不是访问全库;
(3)base-service合并结果集,返回列表数据;
第四,其他需求…
本文写到这里,上述一、二、三、四其实都不是重点,base-service层通过各种各样的奇技淫巧,能够解决db水平切分后的数据访问问题,只不过:
(1)base-service层的
复杂度提高了;
(2)数据的获取效率降低了;
当需要
进行db水平切分的base-service越来越多以后
,此时分层架构会变成下面这个样子:
底层的
复杂性会扩散
到各个base-service,所有的base-service都要关注:
(1)patition key路由;
(2)非patition key查询,先mapping,再路由;
(3)先全库,再合并;
(4)先分析,再按需路由;
(5)跨库分页处理;
(6)…
这个架构图是不是看上去很别扭?
如何让数据的获取更加高效快捷呢?
数据库中间件
的引入,势在必行。
这是“基于服务端”的数据库中间件架构图:
(1)base-service层,就像访问db一样,访问db-proxy,高效获取数据;
(2)所有底层的复杂性,都屏蔽在db-proxy这一层;
这是“基于客户端”的数据库中间件架构图:
(1)base-service层,通过db-proxy.jar,高效获取数据;
(2)所有底层的复杂性,都屏蔽在db-proxy.jar这一层;
结论
:
当
数据库水平切分,base-service层获取db数据过于复杂,成为通用痛点
的时候
,就应该抽象出数据库中间件,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。
任何脱离业务的架构设计,都是耍流氓
。
“为什么”比“怎么样”更重要
。
若有收获,随手帮
转
哟。
推荐文章
:
《
每秒100W次的计数,架构这样设计
》
《
数据库软件架构,到底要设计些什么
》
《
MySQL官方的数据库中间件
》
标签:
知识来源:
mp.weixin.qq.com/s/?id=19054d796e76e6d2fa91e64e90f21fbc&source_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%2FfGIXDxe6fIN2bhYbwP5g_A
本文链接:
究竟能不能,不引入数据库中间件?
打印
复制链接
上一篇:
阿里研究员关涛(观滔):当下的大数据体系是什么?| ArchSummit
下一篇: 没有了
网友评论
已有
0
条评论,
我也要评论
发表评论
用户名:
*
电子邮箱:
*
(保密)
网站网址:
验证码:
申请头像
添加评论内容
Ctrl+Enter 快捷回复
每天为热爱学习的工程师/架构师/技术经理/CTO更新最新最优质的IT技术精华文章,帮助你突破年薪百/千万。
➨GitHub:
https://github.com/taogogo
➨关注微博:
http://weibo.com/taogogo
随机推荐
又想跳槽了,那这个问题你考虑了没有?
求你了,开会别玩手机,行吗?
几个吓尿了的公众号,前几个你不可能没听过
实战 Spring Cloud Gateway 之限流篇
20 张图击溃,跳表!
LeetCode ,YYDS!
Paradigm CTF 2021 比赛环境
你真的了解微服务吗?
伴鱼机器学习预测服务:设计篇
标签云
IT技术
Linux
系统
算法
架构
数据库
优化
python
分布式
php
App
opensource
面试
大数据
数据
术→技巧
java
教程
Web开发
Linux & Unix
Technical
程序设计
原创
机器学习
技术
docker
SQL Server
Javascript
Cache
程序开发
nginx
Working case
默认分类
..experience
编程
oracle
安全
杂项
Redis
操作系统
网友评论已有0条评论, 我也要评论