Java websocket_docker rocketmq
Java websocket_docker rocketmq
HandlerSocket是MySQL的一个Plugin，通过它可以直接跟MySQL的Storage Engine Layer(比如InnoDB）交互，而不需要通过MySQL的Parser Layer。从性能角度有很大的提升。
HandlerSocket特别适用于海量数据、高并发的具有简单业务模型的应用，比如微博、Feed。可以用来替代传统Memcached+MySQL的方式，而且性能上也接近于目前主流的NoSQL产品，所以还是有比较大的优势。但是需要清楚理性的看待这个问题，由于目前还刚发布不久，还远没有Memcached+MySQL成熟，所以，还是需要更多的功能和性能测试，更多地去研究它的源代码，这样才能更加放心的使用。现在的Memcached+MySQL的方式还是很好的方式，我觉得还将会长久下去，HandlerSocket+MySQL的出现，是给大家多了一个选择。
一、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性能
HandlerSocket作者测试HandlerSocket在查询情况下QPS为75K，Memcached为40K，MySQL为10K。但是需要注意到它的测试场景，一般的应用是很难有这样的场景的，所以说一般应用是很难达到7.5倍于MySQL的情况，但是性能的大幅度提高是不容置疑的。作者的测试场景如下： 1. 关闭MySQL的query cache：也就是MySQL的每次操作都需要执行sql解析等那一系列操作。
2. CPU Bound而非I/O Bound：InnoDB Buffer Pool设置为比较大，命中率接近100%。
所以，应该更客观的来看待测试数据。对于CPU Bound而非I/O Bound类型的应用，在InnoDB_Buffer_Pool接近100%命中率的时候，HandlerSocket可以将查询性能提高7.5倍。这一点其实不难理解，因为HandlerSocket主要性能优化点在于节省了SQL层的开销，SQL层的开销主要是CPU的开销。而如果对于一个I/O Bound的应用来说，HandlerSocket的查询性能可能就达不到7.5倍了，可能距离7.5倍有比较大的差距，所以，对于HandlerSocket的应用来说，应该尽量提高InnoDB_Buffer_Pool的大小，多多益善。
我也做过一些基准测试，基本上在插入的情况下，HandlerSocket的性能能达到同等环境的MySQL的3-5倍，数据量越大时候越明显，特别是达到5000万以后。在查询情况下，HandlerSocket是同等环境下MySQL的1.5-2倍，这跟作者的测试的7.5倍有比较大的出入，这也是上面我特别提到的，作者的测试数据是在Innodb_Buffer_Pool足够大并且命中率很高的情况，由于我做基准测试的机器条件有限，没有足够大的Buffer Pool，命中率不是很高，所以，I/O开销不小，这也验证了上面提到的，对于I/O Bound的场景，性能的提升不会特别的明显，所以应该尽量增大InnoDB_Buffer_Pool的大小，尽量接近于数据的大小。而且我在测试的时候，没有关闭Query Cache，所以对于MySQL的测试场景来说，能重用到执行计划和Cache数据等。
上面说到了，HandlerSocket具有不少的优点，性能也有很大的提升，但是也需要理性的来看待，有一些需要特别注意的事项，在做决策的时候，应该整体上的考虑，我这里简单的总结一下。 1. 应该尽量达到CPU-Bound场景，而非IO-Bound，这样才能更好的发挥出HandlerSocket的优势。具体做法是增大内存，尽量提高InnoDB_Buffer_Pool大小。
2. 由于采用合并操作，响应时间会有不同程度的增加，应该考虑好是否满足你的应用场景。可以继续关注后续版本优化策略，比如可能有些朋友会想要这样的：读取的时候不是合并操作，但是写入是合并操作，当然这样的情况读取的总体性能会有不同程度降低，不过一切不就是在权衡嘛？还是看具体应用场景。
五、HandlerSocket性能优化 前面也提到了，HandlerSocket性能相比传统MySQL有了比较显著的提高，但是要想更好的发挥出它的优势，需要做一些相关的优化。
性能优化主要从以下三方面考虑，当然除了这三方面，还有其他一些优化方式，比如优化操作系统，使用Direct IO等，这里说的这三方面是相对比较容易做到并且实现技术成本也不高的方式： 1. 硬件环境 前面也提到了，应该尽量提高Innodb Buffer Pool的大小，对应到硬件上，就是要尽量增加内存的大小，最理想的情况下是内存大小与数据大小一样。如果有资源，也可以考虑采用SSD，这有个基于SSD的测试数据（http://www.percona.com/docs/wiki/benchmark:handlersocket:ssd:start），性能还是非常给力的。
2. 客户端优化 客户端与服务端基于Socket通信，打开关闭连接、OpenIndex等操作都是比较耗费资源的操作，应该尽量避免频繁的做这些操作。所以，在客户端应该要做连接池，同时应该采用一些更好的通信模型，比如Linux下基于epoll和NIO等。比如，这个Java客户端（http://code.google.com/p/hs4j/）这方面就做得不错。
3. HandlerSocket和Innodb配置 HandlerSocket配置： //读线程的个数，推荐为逻辑CPU个数，比如超线程的应该*2 handlersocket_threads = 16 //写线程的个数，目前的版本推荐设置为1 handlersocket_thread_wr = 1 //读请求的监听端口 handlersocket_port = 9998 //写请求的监听端口 handlersocket_port_wr = 9999
Innodb配置： //Innodb Buffer Pool大小，推荐越大越好 innodb_buffer_pool_size //Innodb日志文件大小，根据需求设置，在允许的情况下越大也越好 innodb_log_file_size, innodb_log_files_in_group //mysqld进程可以打开的文件数，推荐为65535 open_files_limit = 65535 //设置为1能提高性能，但是相应的也会消耗内存，需要权衡好 innodb_adaptive_hash_index = 1
================================================================================
项目地址：
文库资料：http://wenku.baidu.com/view/c1898218a8114431b90dd88d.html
参考资料：http://www.cnblogs.com/inrie/archive/2011/01/28/1946998.html
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/172620.html原文链接：https://javaforall.cn