spymemcached

目的 主要是了解 MemcachedClient4J实际性能,对下步优化提供依据 场景 采用跟spymecached对比测试，分别在大负荷的情况下，观察两者性能表现，主要观察指标有耗时和出错率。 测试环境 mecached服务器 数量：1 系统：centos 6.4 cpu:Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz 内存：4G mecached参数：内存512M 客户端 系统：centos 6.4 cpu:Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz 内存：4G jdk:1.6.0_38-b05 Netty : 3.7.0.Final 设置 TCP_NODELAY 为 true io worker 为 cpus 个数 测试结果 结论和分析 MemcahcedClient4J在同样的压力下表现比spymemcached较好，但差距不是很大，这也是我意料之中。memcachedClient4J所使用的netty框架是支持多线程worker，测试只有一个memcached节点，实际上所有读写处理还是由同一个worker线程处理，跟 单线程nio的 spymemcached基本处理同一个等级水平。但是netty对IO写都有一个小优化，通常的NIO写操作都是放入一个缓冲队列，等待reactor去写。在队列为空的情况下

简介 spymemcached 是一个 memcached 的客户端， 使用 NIO 实现。采用Reactor模式实现，单线程，高性能Memcached客户端。 spymemcached源码分析： http://my.oschina.net/astute/blog/93492 Reactor模式介绍 所谓reactor模式，其实是event-driven pattern在网络服务设计中的应用，以平衡CPU与IO速率，最大化CPU资源与IO资源的利用率； 先来看看经典的服务器设计： 经典网络服务接受客户端请求，响应请求过程可以抽象为以下步骤： 读取请求数据 ： read 解码数据： decode 计算：compute 编码数据：encode 发送数据：send 网络服务所有动作被抽象为这个五个步骤的handler；可能每个handler有单独线程执行，或者由一个线程顺序执行； 这种经典设计中存在以下问题： 每个连接分配一个线程，而每个连接发送请求数据较少，导致大量空闲线程； 大量线程上下文切换和锁竞争 为了解决上述问题，采用两个方法实现： 采用分治的思想，将连接划分为更小粒度的非阻塞任务：将用户连接划分为 多个用户请求，每个请求一个线程处理；减少 请求间空闲时间占用线程 采用事件处理模式，分派可执行任务；通过IO 事件触发 handler 处理

spymemcached 深入分析 author ：智深 version ： 0.7 日志： http://my.oschina.net/astute QQ ： 2548921609 ( 技术交流 ) 一、简介 spymemcached 是一个 memcache 的客户端， 使用 NIO 实现 。 分析 spymemcached 需要了解 NIO ， memcached 使用， memcached 协议，参考资料中列出了有用的资源连接。 NIO 是 New I/O 的缩写， Java 里边大家一般称为异步 IO ，实际上对应 Linux 系统编程中的事件驱动 IO （ event-driven IO ），是对 epoll 的封装。其它的 IO 模型还包括同步，阻塞，非阻塞，多路复用（ select ， poll ）。阻塞 / 非阻塞是 fd 的属性，同步会跟阻塞配合，这样的应用会一直 sleep ，直到 IO 完成被内核唤醒；同步非阻塞的话，第一次读取时，如果没有数据，应用线程会立刻返回，但是应用需要确定以什么样的策略进行后面的系统调用，如果是简单的 while 循环会导致 CPU 100% ，复杂的类似自旋的策略增加了应用编程的难度，因此同步非阻塞很少使用。多路复用是 Linux 早期的一个进程监控多个 fd 的方式，性能比较低，每次调用涉及 3 次循环遍历，具体分析见 http

spymemcached 中，一个 mc client 与某一个 mc node 之间已建立的 connection 上， 如果执行操作屡屡超时（net.spy.memcached.OperationTimeoutException）， 那么，有一个计数器专门记录超时次数（connected或reconnecting就清零）。 当某一个 mc node 的连续超时次数达到一定阈值（如 998 次）， 就会…… 关闭原来的 socket channel，并将该 mc node 放入重连队列 reconnectQueue ：lostConnection(mn)， 遍历 reconnectQueue ，逐一尝试重新建立 socket 连接 ：attemptReconnects()， 然后不管连没连上，rehash 队列中的操作：redistributeOperations(retryOps) 。（rehash 指重新计算hash值，看是否要连接其他的节点）。 这个超时次数阈值，既可以在 spring 里如下这样设置，也可以采用默认值 998 次： SpringIntegration <bean id = "memcachedClient" class = "net.spy.memcached.spring.MemcachedClientFactoryBean" > ……

火丁说 ： 『 Multiget的无底洞问题 Facebook在Memcached的实际应用中，发现了 Multiget无底洞 问 题，具体表现为：出于效率的考虑，很多Memcached应用都已Multiget操作为主，随着访问量的增加，系统负载捉襟见肘，遇到此类问题，直觉通 常都是通过增加服务器来提升系统性能，但是在实际操作中却发现问题并不简单，新加的服务器好像被扔到了无底洞里一样毫无效果。 …… 问题是很多客户端，包括 Libmemcached 在内，在处理Multiget多服务器请求时，使用的是串行的方式！也就是说，先请求一台服务器，然后等待响应结果，接着请求另一台，结果导致客户端操作时间累加，请求堆积，性能下降。 』 那么，spymemcached 是如何实现 Multiget（即getBulk）的？ 给一组 key， [1，2，3，4，5] 。 先算一下这些key都落在哪些节点上（通过 KetamaNodeLocator 的 public Iterator<MemcachedNode> getSequence(String k)。Now that we know how many servers it breaks down into.）； 此时，得到一个map： <Node1,[1,3]>;<Node2,[2,4]>;<Node3,[5]> ； 遍历这个map，从每一个

先说一下结论。 如果你没有特意在 spymemcached 的 client bean definition 里配置 useNagleAlgorithm 属性为 True， 那么 默认 spymemcached 是不启用 Nagle 算法的 。 所以默认情况下不会引发恨少在《 libmemcached的MEMCACHED_MAX_BUFFER问题 》一文中提及的“ shell脚本set 1000次8KB的item，只要3s左右，平均需要3ms。而C++版本则需要39s左右，平均耗时39ms……发现8KB的数据需要发送两次，两次write都是非常快的，但是 等memcached返回时用了很多时间，主要的时间就耗费在这个地方 ”现象。咱们业务中心可以排除这个嫌疑。 什么是 Nagle 算法？ 『 TCP/IP 协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能地利用网络带宽，TCP总是希望尽 可能地发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。 Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。 N agle算法的基本定义是 任意时刻，最多只能有一个未被确认的小段 。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”