[原创]HandlerSocket系列（二）：架构、特点及其(2)

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应用场景

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的出现，是给大家多了一个选择。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-36767-2.html