【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 的架构才是灵活的、拥抱变化的。简单说，我们定的是机制，提供的是策略；机制是软件目标和宗旨的体现，一般是不能轻易改变的，而策略则应当是能比较简单地进行切换的。

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