专访:采用分布式数据访问层

最新推荐文章于 2024-07-12 14:58:51 发布

foxcai

最新推荐文章于 2024-07-12 14:58:51 发布

阅读量1.1k

点赞数

文章标签： hibernate access layer 数据库手机 memcached

　　【IT168 报道】 分布式(Distributed)数据访问层(Data Access Layer)(以下简称DAL)是综合MySQL Proxy、Memcached、集群等等技术优点而构建的一个软件系统。目的是为了解决在构建大中型网站时遇到的和数据访问有关的诸多问题，如怎么使得切库分表透明化，如何使得缓存存取清除自动化，怎样才能更好地防止服务单点故障等等。DAL是手机之家团队近几年在开发和运营上的经验的总结以及智慧的结晶。

　　许超前是手机之家一位资深的开发者和架构师, JavaEye非常荣幸的采访了他。许超前博客：http://www.longker.org/
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个小时左右。