采访分布式数据访问层(Data Access Layer)作者许超前

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 分布式(Distributed)数据访问层(Data Access Layer)(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。
分布式(Distributed)数据访问层(Data Access Layer)(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题,如怎么使得切库分表透明化,如何使得缓存存取清除自动化,怎样才能更好地防止服务单点故障等等。DAL是手机之家团队近几年在开发和运营上的经验的总结以及智慧的结晶。

许超前 是手机之家一位资深的开发者和架构师, JavaEye非常荣幸的采访了他。

许超前博客: http://www.longker.org/

欢迎大家推荐更多开源项目和业界专家给我们,支持中国的IT发展,发站内短信给JavaEye管理员或者发信到webmaster@javaeye.com,谢谢。

采访分布式数据访问层(Data Access Layer)作者许超前(十四) Top

JavaEye:1.Hi,许超前,你好,非常荣幸能够采访你,首先你能够向大家介绍一下分布式(Distributed)数据访问层(Data Access Layer)吗?

许超前:简单说来,分布式数据访问层(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题,如怎么使得切库分表透明化,如何使得缓存存取清除自动化,怎样才能更好地防止服务单点故障等等。后面,我会在我的博客上以及今年的SD2China大会上做进一步的说明,有兴趣的可以留意。

JavaEye:2.分布式(Distributed)数据访问层(Data Access Layer)是什么时候诞生的,能否介绍一下发展历程?

许超前:DAL的产生是经历一番波折的。

2007 年,手机之家的用户已经接近1000万、PV也到了500万以上,正处于中小型网站向大型网站的过渡时期。那时候,我们明显感觉到我们在技术上已经遇上了瓶颈:一个是系统负载过高,经常要担心我们的数据库是不是又挂了,进而造成整个系统的瘫痪;第二个是5年积累下来的代码也已经非常难以维护,因为分层模糊,结果到处充满着数据库访问逻辑、到处充满着缓存读写逻辑,再加上表的设计不合理,造成无法简单地进行水平伸缩。总之,我们的系统已经到了不得不进行改造的地步了。

后来,老高(手机之家创始人高春辉)组了一个研发团队,旨在从根本上解决上述提到的问题。在此后一年的时间里,我们走了很多弯路,经历了很多痛苦,不过,也正是在这段时间里,产生了DAL的雏形,经过若干次改进,变成了后来的DAL1.0。DAL的产生完全是形势使然。。。到了那个时间、在那个地点、做了那件事。

DAL1.0上线后数据库的QPS明显下降,从几千降到几百。事实证明,我们找到了一条行得通的路子。所以才有DAL的后续版本的开发,才有今天的DAL2.x版本的产生。

JavaEye:3.能介绍一下手机之家网站和技术团队吗?

许超前:手机之家是一个旨在提供全方位的手机相关服务的资讯类网站。在7年的时间里,手机之家从无到有,已经发展成为极具人气、最受关注的手机产品资讯网站。有点广告的味道,不过说的都是事实,呵呵。

以下是今年3月份在Beta技术沙龙上提到的统计数据:
a. 1000w+用户
b. 3000w+帖子
c. 1.1TB+附件
d. 780w+ Page View/每天
e. 5~10w在线用户/15分

现在,用户应该是1200万了吧,其它的也有所变动。最近比较忙,没再去关注。

手机之家现在有个技术部,负责网站的日常维护事宜;我们还有个项目组,负责整个系统的架构设计及新技术的研究和探索等等。

JavaEye:4.分布式(Distributed)数据访问层(Data Access Layer)的主要特点是什么?能否简要分析一下它实现的主要技术核心?

许超前:要说特点,摘抄一下我在博客里写的关于新版DAL的项目目标,这些目标在DAL2.x里已经得到了相对较好的实现,我想这应该就是它最大的特点了吧:

一)可伸缩。
这里是指Scale Out.,即水平可伸缩。事实上,这点更应该是整个系统要考虑的目标了,而非DAL,DAL要考虑的是怎么更好地支持。举例说,我们可以一个库一个服务,甚至可以是一个表一个服务;库、表拆分后,DAL应能路由查询、合并结果,而不是让应用程序去操心这些事。

二)高可用性。
1) 我们认为出错失败是很正常的,一台机器倒下了,其它机器应继续保持系统正常运作。容错是很重要的一个要求。
2) 系统规模大了以后,很容易出现“异构“的情况,如原有模块MySQL表引擎是MyISAM的,是不支持事务的,而新上的模块又采用了InnoDB表引擎,在这种情况下,DAL应能对原有模块进行优雅降级。
3)失败恢复也是要考虑的,失败后,需要把失败前驻留在内存中的消息找回来。
4) 另外,DAL本身也在快速的迭代当中,升级是很经常的事,应能进行在线热升级(不重启原有服务)。

三)良好的性能。
对于根据Id来取记录的查询,在缓存命中的情况下,应该达到和Memcached不相上下的读取速度。在缓存不命中的情况下,则应该充分利用分库分表和并行计算的优势,最大化地提高查询的效率。对于修改型查询,挂在上面的监听器,不应该影响性能。

四)系统可监控。
资源占用情况,命中率如何,系统当前压力怎样等等,都应该是可知的。应该有报警机制,当压力到达一个阀值以后,通知相关人员进行处理。还应该有详细的错误日志,便于排查问题。

五)安全。
没有SQL注入问题;避免或尽量减少分表和索引表之间的数据不一致问题等等。

六)易于编程。
需要设计一套简单好用的API,便于应用程序的开发。API必须是自完备的,应用开发者不需要太费力就能记住的。
应用开发人员不再关心分库分表问题,不再关心缓存问题, 特别是缓存清除问题。甚至不再关心后端的数据库是MySQL,还是Oracle,或者是其它。

七)可定制、可扩展、可维护的架构设计。
像连接池组件、缓存组件、查询分析组件、消息队列组件、通讯协议等等不应该写死,应设计成可方便定制的。还应该提供足够的钩子用于扩展。只有这样,DAL 的架构才是灵活的、拥抱变化的。简单说,我们定的是机制,提供的是策略;机制是软件目标和宗旨的体现,一般是不能轻易改变的,而策略则应当是能比较简单地进行切换的。

这里面,每一点都可以说说,还是在以后的博客里,再来详细和大家讨论吧。


JavaEye:5.分布式(Distributed)数据访问层(Data Access Layer)应用的主要场景是什么?能否详细比较一下分布式(Distributed)数据访问层(Data Access Layer)和类似产品比如hibernate的区别吗?

许超前:DAL比较适用于大中型网站,对于想提高系统负载能力及响应速度的小型网站也是适用的,但可能获得的好处不如大中型网站那么明显。

DAL和Hibernate两者不具有可比性,从出发点来看就不同,DAL一开始是为了提高网站的负载能力,而Hibernate则是为了能更快地开发Java应用。手机之家采用混合编程,上层应用不一定是用Java写的,要让(非Java)程序员对每个模块涉及到的表结构都用Java实体类写一遍,不太现实。相反,我们采取了不同的思考方式,我们的程序员面向的是表和记录,而不是实体类和实体对象。虽然,DAL也有Mapping的概念,但是它的Mapping是指逻辑表到物理表的Mapping,而不是Java对象到数据库模式的Mapping。DAL的逻辑表可能对应着多个物理表,程序员看到的是逻辑表,不用关心后面有多少个物理表。

MySQL Proxy也提供了一些类似的特性,DAL与它的第一个不同在于,我们的缓存处理是内置的,我们从设计之初就特别认真地考虑缓存这块,而MySQL Proxy得自己写Lua脚本。第二个不同在于,我们针对的不仅仅是MySQL这一种数据库。而且,我们还有很多其它的事情要做。

另外,国内还有一个开源项目叫Amoeba。Amoeba关注的领域是切分,在这个领域,Amoeba对概念的抽象还是不错的。DAL更像是一个完整的系统,当然,也可以只用DAL来做切分,其它的逻辑自己编写,想拥有哪些特性都是可配置的。这样设计一个是为了易用,一拿来就能用,另一个是为了能更好的和现有的解决方案(如Hibernate)集成,虽然DAL在很多方面都可以取代它们(如Hibernate)。

最后,我相信,肯定还存在很多类似的解决方案,只是我们不曾得知。或许是过于定制化了,或许是还不够成熟。。。

JavaEye:6.目前大概有多少用户在使用分布式(Distributed)数据访问层(Data Access Layer)?

许超前:目前DAL主要用在手机之家网站上面,当然,还有其它的项目也在用。

JavaEye:7.目前分布式(Distributed)数据访问层(Data Access Layer) 开发的技术难点是哪里?

许超前:要说技术难点,我觉得有以下几点:

一)如何降低CPU负载及减少内存占用。

二)如何提高查询条件的分析速度。

三)如何更有效地路由到相应的库和表上。

四)如何提高缓存的命中率。

五)如何更有效的进行数据复制。


JavaEye:8.你每周大概花多少时间在分布式(Distributed)数据访问层(Data Access Layer)项目上面?

许超前:每周大概80个小时左右。

JavaEye:9.开发分布式(Distributed)数据访问层(Data Access Layer)带给你最大的收获是什么?

许超前:一)贵在坚持。一个长开发周期的软件,到了后面,不仅是对开发人员体力、智力的综合考验,更是对开发人员心理承受能力的考验,因为这时会有来自各方的及自发的压力。如果能坚持下去,扛过这一关,事情往往就成了一半。

二)找一些和你有共同目标的人一块共事。否则会耗费大量的沟通成本。

三)用数据说话。事务都在变化当中,几年前的经验,也许到今天就不灵了。而且很多事情并不是像我们想象得那样去发展。

四)中国不打折。

JavaEye:10.开发分布式(Distributed)数据访问层(Data Access Layer)的roadmap是什么?近期远期的开发计划计划是什么?

许超前:接下来的版本要做的事有这几个方面:

一)更多的协议开发,这样才能作为透明代理使用,比如我们的PMA也可以使用了。

二)数据库厂商中立的数据复制。

三)嵌入式API,考虑和Spring、Guice等集成,方便Java应用开发人员的使用。


JavaEye:11.你的开发环境是什么? 使用什么操作系统,和IDE?

许超前:一直用Linux操作系统,现在是Ubuntu,IDE用Eclipse。

JavaEye:12.开发分布式(Distributed)数据访问层(Data Access Layer)项目是如何推广的?未来有什么推广方面的计划吗?

许超前:DAL目前只在内部项目中使用。等足够成熟了,我们会采取一系列办法进行推广的。


JavaEye:13.通过开发开发分布式(Distributed)数据访问层(Data Access Layer)项目 ,你对中国的开源软件现状有什么看法?对国内软件开发人员做开源项目有什么感受和想法吗?

许超前:我们的IT行业起步晚,开源文化还不够深入人心,再加上我们中的大部份人还在为生计发愁,所以对开源事业上心的人还是少数。因此,和欧美发达国家比起来,我们的开源事业相对滞后。
我由衷地敬佩那些做开源项目的开发人员,如果可能,我也希望多做些开源软件和大家一块分享。


JavaEye:14.作为一个JavaEye的会员,你对JavaEye网站有什么建议和意见吗?

许超前:想办法让老人多发言,同时也给新人提供一个学习成长的地方。比如可以弄个师徒频道(有点SNS的味道),老人可以招学徒,新人可以拜师傅。

许超前 介绍 Top

许超前,男,毕业于华中师范大学计算机科学与技术系,现居住在北京。98年开始喜欢上计算机,曾有过存储、搜索、Java NIO框架、Java Cache系统、消息队列等等的研发经验。一毕业就任职于手机之家(中国手机用户最受推崇的品牌),前后已经4年了,目前担任架构师一职,负责分布式数据访问层(Data Access Layer, 简称DAL)软件的架构、设计和开发工作。

除了技术方面,爬山是最大的爱好,喜欢摄影,偶尔打打太极柔力球。

许超前博客: http://www.longker.org/

由于许超前太低调,只提供了一张背影给我们遐想    :
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
680
分享
相关文章
|
14天前
|
SQL
【YashanDB知识库】手工迁移Doris数据到崖山分布式
【YashanDB知识库】手工迁移Doris数据到崖山分布式
数据分布式存储:在海量数据面前,我们如何站稳脚跟?
数据分布式存储:在海量数据面前,我们如何站稳脚跟?
83 1
DeepSeek开源周第五弹之一!3FS:支撑V3/R1模型数据访问的高性能分布式文件系统
3FS是DeepSeek开源的高性能分布式文件系统,专为AI训练和推理任务设计,提供高达6.6 TiB/s的读取吞吐量,支持强一致性保障和通用文件接口,优化AI工作负载。
492 2
DeepSeek开源周第五弹之一!3FS:支撑V3/R1模型数据访问的高性能分布式文件系统
【YashanDB 知识库】用 yasldr 配置 Bulkload 模式作单线程迁移 300G 的业务数据到分布式数据库,迁移任务频繁出错
问题描述 详细版本:YashanDB Server Enterprise Edition Release 23.2.4.100 x86_64 6db1237 影响范围: 离线数据迁移场景,影响业务数据入库。 外场将部分 NewCIS 的报表业务放到分布式数据库,验证 SQL 性能水平。 操作系统环境配置: 125G 内存 32C CPU 2T 的 HDD 磁盘 问题出现的步骤/操作: 1、部署崖山分布式数据库 1mm 1cn 3dn 单线启动 yasldr 数据迁移任务,设置 32 线程的 bulk load 模式 2、观察 yasldr.log 是否出现如下错
基于Java的Hadoop文件处理系统:高效分布式数据解析与存储
本文介绍了如何借鉴Hadoop的设计思想,使用Java实现其核心功能MapReduce,解决海量数据处理问题。通过类比图书馆管理系统,详细解释了Hadoop的两大组件:HDFS(分布式文件系统)和MapReduce(分布式计算模型)。具体实现了单词统计任务,并扩展支持CSV和JSON格式的数据解析。为了提升性能,引入了Combiner减少中间数据传输,以及自定义Partitioner解决数据倾斜问题。最后总结了Hadoop在大数据处理中的重要性,鼓励Java开发者学习Hadoop以拓展技术边界。
97 7
|
5月前
|
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
97 5
分布式缓存有哪些常用的数据分片算法?
【10月更文挑战第25天】在实际应用中,需要根据具体的业务需求、数据特征以及系统的可扩展性要求等因素综合考虑,选择合适的数据分片算法,以实现分布式缓存的高效运行和数据的合理分布。
前端的全栈之路Meteor篇(七):轻量的NoSql分布式数据协议同步协议DDP深度剖析
本文深入探讨了DDP(Distributed Data Protocol)协议,这是一种在Meteor框架中广泛使用的发布/订阅协议,支持实时数据同步。文章详细介绍了DDP的主要特点、消息类型、协议流程及其在Meteor中的应用,包括实时数据同步、用户界面响应、分布式计算、多客户端协作和离线支持等。通过学习DDP,开发者可以构建响应迅速、适应性强的现代Web应用。
135 2
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
112 0

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等