经过同事们的一番努力，终于把搜索更新改为基于MQ的方式了，大家(特别是增禄和大庆)辛苦了。
搜索更新早就想改了，因为种种限制，无法实施。这些限制如下：
一）手机之家采用混合编程(主要是PHP+JAVA)。
二）JAVA调用PHP显然不是好方法。
三）用PHP做异步触发很困难。
四）用PHP写驻留程序很困难。
五）要让PHP在消费消息失败时回滚很困难。
六）基于这些限制，DAL1.0最后用PHP和数据库实现了一个不太可靠的消息队列。这显然不太好。
“旧”更新方式如下图所示：
DAL升级到2.x后，之前的种种限制已经消失了，搜索更新一下子有了很大的改进空间。具体改进如下：
一）引入双队列，为的是能异步触发，从而节省内存、降低CPU占用率，进而提高负载能力。DAL2.x内置队列写消息非常快，写一条消息耗时不到1微秒(不是毫秒，了解个大概，省略测试环境)。
二）(部分)拉改成了推，“近实时“更新有了可能性。时间关系，留待下一步继续改进。
“新”更新方式如下图所示：
接下来可能会抽个时间试试以下的方式(废弃Crond，主要是为了减少更新延迟)：
注：图中提到的M3，是Massive Message Manager的简称，是我们的大庆在近期开发的作品，在此鼓励一下：）。
—The End.
DAL2.1.1是一个非常重要的版本，到此为止，当初的想法已经得到了相对较好的实现。刚来的朋友可以看这两篇Blogs：
beta技术沙龙结束，开始忙正事了，DAL2.0开发已近尾声，在这稍微说说情况，来了解一下DAL的相关词汇及来龙去脉。
总的来说，DAL是团队近几年在开发和运营上的经验的总结以及智慧的结晶。一年前，开发DAL是一件水到渠成的事；一年后，不断改进DAL则是为了在未来5~10年、甚至更长远的时期内，(在数据访问层)支撑着手机之家传统业务的快速增长以及新业务的持续开拓和稳步扩充。后者，决定了新版DAL的项目目标。
具体说来，当时定的目标是这样的：
一）可伸缩。
这里是指Scale Out.，即水平可伸缩。事实上，这点更应该是整个系统要考虑的目标了，而非DAL，DAL要考虑的是怎么更好地支持。举例说，我们可以一个库一个服务，甚至可以是一个表一个服务；库、表拆分后，DAL应能路由查询、合并结果，而不是让应用程序去操心这些事。
二）高可用性。
1) 我们认为出错失败是很正常的，一台机器倒下了，其它机器应继续保持系统正常运作。容错是很重要的一个要求。
2) 系统规模大了以后，很容易出现“异构“的情况，如原有模块MySQL表引擎是MyISAM的，是不支持事务的，而新上的模块又采用了InnoDB表引擎，在这种情况下，DAL应能对原有模块进行优雅降级。
3)失败恢复也是要考虑的，失败后，需要把失败前驻留在内存中的消息找回来。
4) 另外，DAL本身也在快速的迭代当中，升级是很经常的事，应能进行在线热升级(不重启原有服务)。
三）良好的性能。
对于根据Id来取记录的查询，在缓存命中的情况下，应该达到和Memcached不相上下的读取速度。在缓存不命中的情况下，则应该充分利用分库分表和并行计算的优势，最大化地提高查询的效率。对于修改型查询，挂在上面的监听器，不应该影响性能。
四）系统可监控。
资源占用情况，命中率如何，系统当前压力怎样等等，都应该是可知的。应该有报警机制，当压力到达一个阀值以后，通知相关人员进行处理。还应该有详细的错误日志，便于排查问题。
五）安全。
没有SQL注入问题；避免或尽量减少分表和索引表之间的数据不一致问题等等。
六）易于编程。
需要设计一套简单好用的API，便于应用程序的开发。API必须是自完备的，应用开发者不需要太费力就能记住的。
应用开发人员不再关心分库分表问题，不再关心缓存问题， 特别是缓存清除问题。甚至不再关心后端的数据库是MySQL，还是Oracle，或者是其它。
七）可定制、可扩展、可维护的架构设计。
像连接池组件、缓存组件、查询分析组件、消息队列组件、通讯协议等等不应该写死，应设计成可方便定制的。还应该提供足够的钩子用于扩展。只有这样，DAL的架构才是灵活的、拥抱变化的。简单说，我们定的是机制，提供的是策略；机制是软件目标和宗旨的体现，一般是不能轻易改变的，而策略则应当是能比较简单地进行切换的。
更加详细的资料可以参看这两个blog：
<<数据访问层开发实践>>
<<手机之家的数据访问层实践>>