上文介绍了为什么会产生HandlerSocket，是什么需求驱动这个产品产生的。本文主要从整体架构上做一些介绍，包括对它的一些主要优缺点和具体的应用场景。

一、HandlerSocket整体架构

HandlerSocket设计为MySQL的一个plugin，作为mysqld进程的daemon存在，与Client通过TCP/IP交互，进行CRUD相关的操作。基于此原因，不仅可以通过HandlerSocket操作存储层，还可以通过传统的MySQL的方式来操作。这样就可以实现：简单快速的操作通过HandlerSocket来实现，而对于一些复杂的操作，还是通过传统的MySQL方式来实现。

HandlerSocket的结构图如下（图片来自作者Blog）：

这里分两条主线来分析上图：
1. MySQL Client -> MySQL Upper Layer -> Storage Engine Layer
这是传统的使用MySQL的方式，MySQL客户端通过3306端口与Upper层交互，在Upper层做SQL解析、打开表、查询计划优化、关闭表等操作，然后提交到Storage层。

2. HandlerSocket Client -> HandlerSocket daemon plugin -> Storage Engine Layer
这是采用HandlerSocket的方式，通过比较MySQL Upper Layer和HandlerSocket daemon plugin，可以明显看出，HandlerSocket减少了很多操作，这正是性能得以提高的最重要的关键点。这里使用的是9998和9999两个端口，9998作为读的端口，不能做写入操作，9999为写的端口，可以做读取操作，但是不建议使用，因为在9999端口做读取操作，从性能角度看，比起在9998端口上差一些。

下图更具体的列出了调用关系和结构：

注意目前版本的HandlerSocket暂时只支持Innodb，相信后续版本肯定会支持其他的Storage Engine。

二、HandlerSocket特点
HandlerSocket相比MySQL及其其他的NoSQL产品，具有一些优势：

1. 由于省去了MySQL的SQL层相关的操作，大大的减少了CPU开销。

2. 采用合并操作的方式，合并多个请求同时执行，减少了CPU开销和降低I/O操作次数。关于这个其他的一些NoSQL产品也有这样的机制，比如Mongodb。

3. 由于基于简单的文本协议，能节省不少网络流量，提高网络吞吐量。大部分的NoSQL产品都有这个优势，不少是兼容Memcached协议，当然更多的是采用专有的协议。

4. 能同时使用传统MySQL和HandlerSocket的方式访问MySQL数据库，互相不冲突。这个优势其实挺突出的，是HandlerSocket 的核心竞争力之一。

5. 支持较大的并发连接，可以通过my.cnf的handlersocket_threads来配置连接数。

6. 还可以继续使用MySQL的Master-Slave、Replication等成熟的机制，系统运维与传统的MySQL运维一致。这也是HandlerSocket相比其他NoSQL产品具有的最大的优势。

7. 避免有双重缓存，比如对于Memcached+MySQL的应用来说，在Memcached和MySQL中都存有数据，需要双倍的内存资源，同时也可能会有数据不一致的问题。而采用HandlerSocket则可以避免这样的问题。具体的在接下来的应用场景里介绍。

8. 具有较高的读写性能，在CPU Bound的场景中，读取性能一般是同等环境下MySQL的3-7.5倍。同时写入性能也能达到3-5倍。

具有这些优势的同时，也要看到它目前存在的待改进或者应该注意的问题：
1. 由于采用合并操作的方式，这样做牺牲了响应时间，响应时间相比MySQL来说大一些。

2. 没有安全相关的保证，绝大部分NoSQL产品都有这样的问题。由于采用这样产品的应用的数据一般都不是核心数据，比如不会涉及到账户信息、用户信息等的，所以，安全性方面的暂时应该都不是什么大问题。

3. 在I/O Bound的场景中，性能的提升可能不是很明显。在这种场景下，性能的提升主要依靠的是合并操作，减少I/O操作次数，但是提高的幅度有限。

4. 由于2010年11月份刚发布，目前版本还有部分Bug待修复，比如通过HandlerSocket做Update操作后，没有清除Query Cache，这可能出现数据不一致的情况。

5. 目前只支持5.1和5.5的Innodb存储引擎，以后应该会支持其他存储引擎。

三、HandlerSocket应用场景
HandlerSocket目前已经在DeNA的生产环境上使用，据作者介绍，运行状态很不错，节省了不少Memcached和MySQL Slave服务器，同时网络传输量也减少了。到目前为止还没有发现什么性能问题，比如响应时间比较长等。

纵观目前绝大部分大型互联网应用，基本上采用的都是Memcached+MySQL的方式。这是一种很成熟并且很有效的方式，基本都成了标准方式。由于HandlerSocket在Innodb Buffer Pool命中率很高的情况下性能不会逊色于Memcached，所以在这种情况下，可以采用HandlerSocket+MySQL来替代Memcached+MySQL。这样有以下几个优势：
1. 采用Memcached+MySQL，需要保存两份数据：Memcached和MySQL本身的缓存，需要双倍的内存资源。而HandlerSocket+MySQL的方式，只需要保存一份缓存数据。

2. 采用Memcached+MySQL，需要保持Memcached与MySQL的数据一致性，有时候可能会出现数据不一致的情况，而如果用HandlerSocket+MySQL就没这情况。

3. 采用Memcached+MySQL，还有一个这样的应用都非常小心和特别注意的问题，就是雪崩效应。新应用上线的时候需要先做好各种预热，尽量减少瞬间超级大的I/O压力。前段时间新浪微博出现一次比较严重的故障，据不完全可靠消息证实，就是雪崩效应引起的，当时有部分Memcached服务器出现故障或者失效，导致DB服务器压力瞬间增大，支撑不住。当然了，HandlerSocket应用不是不需要预热，也是需要的，但是在面对这样的问题的时候，它的支撑能力比起MySQL+Memcached的能力强。

通过以上说明，可以看出，HandlerSocket特别适用于海量数据、高并发的具有简单业务模型的应用，比如微博、Feed。可以用来替代传统Memcached+MySQL的方式，而且性能上也接近于目前主流的NoSQL产品，所以还是有比较大的优势。但是需要清楚理性的看待这个问题，由于目前还刚发布不久，还远没有Memcached+MySQL成熟，所以，还是需要更多的功能和性能测试，更多地去研究它的源代码，这样才能更加放心的使用。现在的Memcached+MySQL的方式还是很好的方式，我觉得还将会长久下去，HandlerSocket+MySQL的出现，是给大家多了一个选择。 

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

转载请注明出处，谢谢！