[原创]HandlerSocket系列（一）：由来

新的技术，几乎都是由需求驱动产生的。在仔细深入研究HandlerSocket之前，我觉得有必要先了解一下它所处的历史背景及其它想解决什么样的问题。我想这应该是最关键的，也是做这方面研究和技术选型时第一个应该关注的要点。

 

先来说一下它的作者Yoshinori Matsunobu，现为DeNA公司的数据库和基础设施架构师，HandlerSocket就是Yoshinori在DeNA公司工作时开发的。DeNA是一家来自日本的社交游戏开发商，目前在日本已经算是数一数二的社交游戏公司，并且在全球展开过一系列的收购，收购了大量的美国游戏厂商，属于一个发展势头非常猛的公司，并且现有用户和活跃度都算挺高的。对于这样一个公司的应用来说，我觉得数据访问方面最关注的应该是这几个要点：海量数据、高并发和热点问题。

 

对于这样的一些典型的互联网应用在发展到一定程度了都会碰到的问题，肯定也是业界都会面临和关注的问题。所以，大家其实可以看到，从08年开始有个词开始频繁的出现，它就是“NoSQL”。从08年开始，NoSQL逐渐的火热起来，各大互联网公司都有这方面的动作，各种NoSQL产品雨后春笋般的出现。甚至于在09年年初时候，如果你关注这方面架构设计方面的人的Twitter，你可以看到很多类似下面这样的言论，比如Tim Yang说的：这年头，如果一个号称有“海量数据”的互联网公司，不做一个自己的Dynamo, 出去都不好意思跟人打招呼（注： Dynamo是 Amazon开发的一个NoSQL产品，Amazon发布了Dynamo的Paper: “Dynamo: Amazon’s Highly Available Key-value Store“。由于它提出和探讨了Scale Out和Failure Handling等很多NoSQL产品都会面临的问题，使得它与BigTable的Paper差不多并称为NoSQL 研究前必须先通读的2个Paper，这两个Paper在网上都可以很容易找到）。当然了，这是一个比较夸张的说法了，但是从侧面也可以反映出，对于具有海量数据和高并发的互联网应用来说，NoSQL是一个不错的选择。在NoSQL出现之前，大部分互联网应用采用的都是MySQL+Memcached的方案。

 

NoSQL，意为”Not Only SQL”，而不是”No SQL”，并不是要来取代关系型数据库的，而是作为关系型数据库的补充，我相信在未来很长时间内，应该是两者共同发展。因为从应用场景来看，两者是互补关系，而不是替代关系。对于NoSQL产品来说，由于具有水平伸缩性、高并发读写性能、高可用等优势，但是同样的，有这些优势也是需要付出代价的，比如绝大部分都是只支持Key-Value 操作、有限制的查询功能、不能使用类似Join等这样的功能、大部分为最终一致性模型、还没有标准化等等，而且由于都刚发布不久，稳定性方面和系统的运维也是应该慎重考虑到的。基于NoSQL产品的这些特点，对于像类似微博、Feed等这样的互联网应用来说，是非常合适的。因为这样的应用一般业务复杂度都不高，不需要复杂的Join查询等功能，可以接受最终一致性等，但是由于需要高并发读写和具有海量的数据，这样的应用最适合使用NoSQL。而对于大部分应用，NoSQL可能暂时或者以后可能都不会支持，特别是对于一些企业信息系统，关系型数据库可能是最好的选择。

 

DeNA和其他互联网应用都遇到的高并发读写、海量数据等的问题，用NoSQL是一个不错的选择。但是由于NoSQL发布的时间都相对比较短暂，稳定性方面还需要慎重考虑，同时运维方面也要有所准备。在做好各种功能测试和性能测试后，最好还是需要有能力能驾驭源代码，在出现问题的时候能更好的定位、排查和解决问题，特别是对于大型的应用来说。这一点可以从之前发生的一些事情得到验证，Digg选择Cassandra，但是后来出现了一些很严重的事故，副总甚至为此引咎辞职。Foursquare选择了Mongodb，但是在前段时间出现了几次宕机。对于新产品来说，在发展的过程中肯定会碰到各种各样的问题，但是会逐步完善和稳定下来，这需要一段时间。如果我们选择在未稳定前使用的话，最好尽量保证有能力来驾驭它们。

 

我相信肯定有一些朋友也在犯愁了，我是需要NoSQL这样的产品，但是我真的承受不起可能由于不稳定带来的一些问题，同时，运维同事们最熟悉的是传统的关系型数据库，比如MySQL、Sql Server、Oracle等，对于这些他们身经百战，但是对于大部分NoSQL产品，则都比较陌生，需要去学习和积累经验，需要比较大的运维成本。其实，有关注过NoSQL的朋友，可能也都看过了类似这样的一些文章：为什么NoSQL比传统关系型数据库性能高？ 这些文章都会大同小异的这样来分析：“由于传统的关系型数据库在处理每个请求的时候，需要做SQL解释、查询优化、解释执行、事务管理、锁管理等等一系列操作，损失了很多性能。但是往往一些对性能要求非常高的应用，比如微博、Feed等，是不需要这些操作的，NoSQL就是由于去掉了这些操作性能上有了很大的提高（当然NoSQL产品在其他方面上也有做了不少优化）”。

 

其实有些朋友可能也想过，比如对于MySQL数据库来说，从整体上来看，是分为两层：SQL层和Storage层。前面说的NoSQL抛弃掉的那些SQL解释等的操作，其实都是在SQL层的，如果把MySQL的SQL层去掉，直接跟Storage交互，性能不就能提高不少？我相信有不少人也这样想过，但是一直都没有人去做这事情。Yoshinori就是做了这样的一件事情，这个产品就是HandlerSocket。通过HandlerSocket直接跟MySQL的Storage层交互，而省去了SQL层的那些操作。Yoshinori之前是Sun/Oracle的MySQL开发和咨询顾问，所以实现这样的一个产品还是相对比较有优势。

 

作者：洪小军
出处：http://www.cnblogs.com/inrie

转载请注明出处，谢谢！