HandlerSocket的原理

HandlerSocket的应用场景：

MySQL自身的局限性，很多站点都采用了MySQL+Memcached的经典架构，甚至一些网站放弃MySQL而采用NoSQL产品，比如Redis/MongoDB等。不可否认，在做一些简单查询（尤其是PK查询）的时候，很多NoSQL产品比MySQL要快很多，而且前台网站上的80%以上查询都是简洁的查询业务。

MySQL通过HandlerSocket插件提供了API访问接口，在我们的基准测试中，普通的R510服务器单实例Percona/XtraDB达到了72W+QPS（纯读），如果采用更强劲的CPU增加更多的网卡，理论上可以获得更高的性能。而同等条件下Memcached仅有40W+QPS（纯读），并且在R510上Memcached单实例已经无法提升性能，因为Memcached对内存的一把大锁限制了它的并发能力。

HandlerSocket原理：

MySQL的架构是“数据库管理”和“数据管理”分离，即MySQL Server+Storage Engine的模式。MySQL Server是直接与Client交互的一层，它负责管理连接线程，解析SQL生成执行计划，管理和实现视图、触发器、存储过程等这些与具体数据操作管理无关的事情，通过调用Handler API让存储引擎去操作具体的数据。Storage Engine通过继承实现Handler API的函数，负责直接与数据交互，数据存取实现（必须实现），事务实现（可选），索引实现（可选），数据缓存实现（可选）。

（图1-1  MySQL架构）

HandlerSocket是在MySQL的内部组件，以MySQL Daemon Plugin的形式提供类似NoSQL的网络服务，它并不直接处理数据，只是侦听配置好的某个端口方式，接收采用NoSQL/API的通讯协议，然后通过MySQL内部的Handler API来调用存储引擎（例如InnoDB）处理数据。理论上，HanderSocket可以处理各种MySQL存储引擎，但是用MyISAM时，会出现插入的数据查不出来，这个实际上是构造行时第一字节没有初始化为0xff，初始化以后就没有问题，MyISAM也一样可以支持，但是为了更好地利用内存，用HandlerSocket都会搭配InnoDB存储引擎一起使用。

图1-2描述HandlerSocket具体做了哪些事情：

（图1-2  HandlerSocket原理）

因为HandlerSocket是以MySQL Daemon Plugin形式存在，所以在应用中，可把MySQL当NoSQL使用。它最大的功能是实现了与存储引擎交互，比如InnoDB，而这不需要任何SQL方面的初始化开销。访问MySQL的TABLE时，当然也是需要open/close table的，但是它并不是每次都去open/close table，因为它会将以前访问过的table cache保存下来以重复使用，而opening/closing tables是最耗资源的，而且很容易引起互斥量的争夺，这样一来，对于提高性能非常有效。在流量变小时，HandlerSocket会close tables，所以它一般不会阻塞DDL。

HandlerSocket与MySQL+Memcached的区别在哪呢？对比图1-2和图1-3，可从中看出其不同点，图1-3展示了典型的MySQL+Memecached的应用架构。因为Memcached的get操作比MySQL的内存中或磁盘上的主键查询要快很多，所以Memcached用于缓存数据库记录。若是HandlerSocket的查询速度和相应时间能与Memcached媲美，我们就可以考虑替换Memcached缓存记录的架构层。

（图1-3 典型MySQL+Memcached架构）

【编者注】

为方便读者更加全面掌握HandlerSocket的知识点，我们分三篇文章介绍：HandlerSocket的原理、HandlerSocket的性能测试报告、HandlerSocket的优势和缺陷阐述，同时帮助读者朋友做到心中有数，什么业务场景适合使用HandlerSocket存取数据，如何让HandlerSocket的优势发挥到极致。