究竟能不能,不引入数据库中间件? 糖太宗 • 2022年5月11日 下午8:08 • 技术 • 阅读 18 不少朋友经常会问我以下问题: (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官方的数据库中间件》 发布者:糖太宗,转载请注明出处:https://www.qztxs.com/archives/science/technology/5925 数据库 赞 (0) 打赏 微信扫一扫 支付宝扫一扫 糖太宗 0 0 生成海报 你的业务代码,是不是都写在了Activity里? 上一篇 2022年5月11日 下午8:07 我去,拷贝代码,居然还有这等好处? 下一篇 2022年5月11日 下午8:08 相关推荐 技术 Redis为什么又引入了多线程?难道作者也逃不过“真香定理”? 相信你一定不止一次见过Redis是单线程模式,不过说实话那只是个老版本,这个问题是一位老哥的大厂面试题,跟我分享了一下。想着自己就知道redis6.0以前一直都是单线程,到了6的版本才加入了多线程,还不是很清楚,在多方打听并且搜索之下总结了这篇文章。 一、问题概述 Redis 6.0 之后的版本抛弃了单线程模型这一设计,原本使用单线程运行的 Redis 也开... 糖太宗 2022年4月1日 20000 技术 解决某宝、某鱼等淘系App无法抓包问题 使用Charles、Fiddle等抓包工具对淘系App进行抓包时,你会发现总是抓不到包,出现请求不走Charles代理的情况。这是因为淘系app底层网络通信的协议并不是普通的http协议,而是自己实现的一套私有协议Spdy。 通过对App反编译破解后分析发现,部分接口由于使用了spdy协议,导致无法抓包。 所以我们只要通过hook将是否使用spdy返回fal... 糖太宗 2022年5月7日 231000 技术 MySQL,在线热备的内核原理! 这是一篇关于MySQL数据库,redo log,LSN,崩溃恢复,在线热备的长文,耐心读完,如果没有收获,可以捶我。 研发的童鞋每次对MySQL库表做重大操作之前,例如: (1)修改表结构; (2)批量修改或者删除数据; 都会向DBA申请进行数据库的备份。 画外音:又或者说,不备份直接操作啦? 那DBA童鞋是怎么进行MySQL备份的呢? ... 糖太宗 2022年5月11日 15000 ruby换源、安装jekyll 0x00 描述 jekyll是一个静态网站生成工具,可以通过markdown编写文档,使用模板自定义网站结构,通过sass或css自定义格式。jekyll是用ruby编写的工具,因此在安装jekyll之前需要安装ruby环境,由于官方源访问问题,需要切换国内源。 0x01 安装ruby 1 2 3 apt-get install ruby ap... 常山赵子龙 技术 2022年5月27日 27000 技术 开源蜜罐HFish使用心得4 - 溯源2 fingerprintjs FingerprintJS FingerprintJS 是一个浏览器指纹库,可查询浏览器属性并从中计算出散列的访问者标识符。与 cookie 和本地存储不同,指纹在隐身/隐私模式下保持不变,即使浏览器数据被清除。 项目地址:https://github.com/fingerprintjs/fingerprintjs 简单使用 通过调用该库,会返... 糖太宗 2022年5月27日 163001 发表回复 您的电子邮箱地址不会被公开。 必填项已用*标注*昵称: *邮箱: 网址: 记住昵称、邮箱和网址,下次评论免输入 提交