原来一直没有发现大块数据小数据量下redis也会非常不稳定出现各种问题, 而且响应时间反应速度也比同环境下hbase差出不少, 文章挺好, 一直没找到分享按钮就直接贴过来了, 原文请点击: http://rdc.hundsun.com/portal/article/761.html
▲测试工具
▲系统部署
1.集群部署：
由于redis采用单线程模型，即一个实例只能使用一个核，所以这里为了充分发挥机器性能，在3台4核的集群机器上一共部署了24个redis实例,其中12个主实例12个备份实例，对所有数据启用一份备份，即每台服务器部署八个redis实例，四主四从。而Couchbase可以充分利用多核CPU，因此每个机器只部署一个实例，数据备份启用一份。
2.压测客户端部署：
OPS压测客户端部署多线程OPS测试程序，用于测试并统计OPS;ResponseTime压测客户端部署单线程ResponseTime测试程序，用于测试并统计不同压力下集群服务的响应时间。
▲测试方案
每台OPS客户端使用500/1000/2000（同步的读写操作会阻塞线程，直至提升线程数OPS无明显变化）个并发线程向集群发送读/写请求，以确保Redis/Couchbase集群发挥最大输出能力，与此同时RsponseTime压测客户端采用单线程（OPS和RsponseTime测试分客户端执行是为了避免客户端网络，客户端CPU调度等对测试结果的干扰；RsponseTime压测客户端端采用单线程是为了减少CPU时间分片对响应时间的影响）发送读/写请求并记录每个请求的响应时间，以纳秒级别的统计精度准确反映出集群在最大OPS的压力下，仍能表现出的处理速度。(OPS和响应时间统计工作，由测试代码完成)
▲测试案例
以下测试中，采用HashMap作为测试数据类型，在Redis中直接以HashMap格式存取，在Couchbase中需要将Hashmap转换为Json格式进行存取。
【 小块数据小数据量写入测试】
四台OPS客户端分别向集群发送100W个100字节大小的数据写入请求，并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据写入请求,并统计响应时间。
一、 Couchbase写入测试
四台OPS压力客户端分别启动500个并发线程和4个bucket连接数（升高和降低该数值性能表现都略有降低）分别向Couchbase集群插入100W条数据，即2000个并发线程发起400W个100字节大小的Document的插入请求，一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中，测试和统计Couchbase集群的服务处理速度。
压测前Couchbase集群的RsponseTime统计：
10.20.135.66
压测前，RsponseTime压测客户端使用单线程向集群发起一万笔写入请求，平均响应时间为0.35ms。
Couchbase控台监控情况如下：
Couchbase集群的资源消耗情况如下：
10.20.135.71
（memcached负责内存和硬盘的数据操作；beam.smp负责Couchbase其他潜在进程的监控和管理，比如跨集群备份，索引和集群操作）
10.20.135.72
10.20.135.73
OPS压测客户端的资源消耗如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
Couchbase集群资源消耗几乎达到瓶颈，且再增大压力OPS没有提升，RsponseTime倒是明显升高。因此，三台4核8G的Couchbase集群，正常情况下能提供0.35ms（有一个重要原因是Couchbase插入操作返回完整Document）的平均响应时间，在2000个并发线程发起400W个100字节大小Document的写入压力下，能够稳定提供15W的OPS，且平均响应时间只有1.95ms（多次测试后选取的一个稳定时间）。
二、Redis写入测试
四台OPS压力客户端分别启动500个并发线程和300个并发连接（再升高该数值性能表现略微下降），分别向Redis集群插入100W条数据，即2000个并发线程发起400W个100字节大小的数据写入请求，一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中，测试和统计Redis集群的服务处理速度，测试结果如下：
压测前Redis集群的RsponseTime统计：
压测前，RsponseTime压测客户端使用单线程向集群发起一万笔写入请求，平均响应时间为0.21ms。
Redis集群的资源消耗情况如下：
10.20.135.71
（4个Redis主节点对外暴露提供读写服务，4个从节点提供备份服务；因此查询测试中只有4个Redis进程消耗资源）
10.20.135.72
10.20.135.73
OPS压测客户端统计如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
虽然OPS压测客户端和Redis集群的资源消耗都没有逼近满负荷，但再增大压力的情况下OPS不升反降，RsponseTime更是明显增长。因此，三台四核八G的Redis集群正常使用情况下能提供0.21ms的平均响应时间，在百万量级100字节大小的数据块写入请求下能够稳定提供20W的OPS，且平均响应时间只有2.09ms。
三、 测试小结
正常使用情况下，Redis和Couchbase都可以提供亚毫秒级别的处理速度，但Redis集群的响应速度（0.21ms）比Couchbase集群（0.35ms）几乎快一倍。在2000个并发线程发起400W个100字节大小数据写入压力下，Redis集群能稳定提供20W的OPS，Couchbase集群能提供稳定15W的OPS，平均响应时间方面两者相当。继续增大压力的话，Redis的RsponseTime增长速度大于Couchbase，即Redis在较大压力下的处理速度下降较快。
【小块数据大数据量写入测试】
每台OPS客户端向集群发送500W个100字节大小的数据写入请求，并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据写入请求,并统计响应时间。
一、 Couchbase写入测试
四台OPS压力客户端分别启动500个并发线程和4个bucket连接数向Couchbase集群插入500W条数据，即2000个并发线程发起2000W个100字节大小的Document的写入请求，一台RsponseTime压测客户端在OPS压测过程中，测试和统计Couchbase集群的服务处理速度，测试结果如下：
Couchbase控台监控情况如下：
Couchbase集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端的资源消耗如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
Couchbase集群资源消耗几乎达到瓶颈，且再增大压力OPS没有提升，RsponseTime倒是明显升高。因此，三台4核8G的Couchbase集群，正常情况下能提供0.35ms的平均响应时间，在2000个并发线程发起2000W个100字节大小Document的写入请求压力下，能够稳定提供14W的OPS，平均响应时间达到3.81ms。
二、 Redis写入测试
四台OPS压力客户端分别启动500个并发线程和300个并发连接（再升高该数值性能表现略微下降），分别向Redis集群插入500W条数据，即2000个并发线程发起2000W个100字节大小的数据插入请求，一台RsponseTime压测客户端在OPS压测过程中，测试和统计Redis集群的服务处理速度，测试结果如下：
Redis集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端资源消耗如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
Redis集群和OPS压测客户端的资源消耗并未达到瓶颈，但再增大压力OPS没有提升，RsponseTime倒是明显升高。因此，三台4核8G的Redis集群，正常情况下能提供0.21ms的平均响应时间，在2000个并发线程发起2000W个100字节大小Document的写入请求压力下，能够稳定提供16W的OPS，但平均响应时间达到6.43ms。
三、测试小结
在2000个并发线程发起2000W个100字节大小Document的写入请求压力下，Redis集群能稳定提供16W的OPS，Couchbase集群能提供稳定14W的OPS，而平均响应时间方面Redis集群（6.43ms）明显长于Couchbase集群（3.81ms），即此时两者所提供的OPS相当，但Couchbase集群的请求处理速度已明显反超Redis集群。
【大块数据小数据量写入测试】
每台OPS客户端向集群发送50W个10KB大小的数据写入请求，并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据写入请求,并统计响应时间。
一、 Couchbase写入测试
六台OPS压力客户端分别启动1000个并发线程和4个bucket连接数向Couchbase集群插入50W条数据，即6000个并发线程发起300W个10KB大小的Document的插入请求，一台RsponseTime压测客户端在OPS压测过程中，测试和统计Couchbase集群的服务处理速度，测试结果如下：
Couchbase控台监控情况如下：
Couchbase集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端的资源消耗如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
Couchbase集群资源消耗未达到机器瓶颈，但OPS压测客户端都达到满负荷，因为没有额外机器完成极限测试，测试结果仅能表明单台8核8G OPS压测客户端只能发起一千OPS左右的10K数据块写入请求。因此，三台4核8G的Couchbase集群，正常情况下能提供0.35ms的平均响应时间，在6000个并发线程发起300W个10KB大小Document的写入请求压力下能够稳定提供6K以上的OPS，平均响应时间只有1.16ms，可见压力主要集中在客户端。
二、 Redis写入测试
六台OPS压力客户端分别启动1000个并发线程和300个并发连接数分别向Redis集群插入50W条数据，即6000个并发线程发起300W个10KB大小的数据插入请求，一台RsponseTime压测客户端在OPS压测过程中，测试和统计Redis集群的服务处理速度，测试结果如下：
Redis集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端资源消耗如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：出现大量超时等写入异常
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
在百万级别10KB大小的数据写入操作下，集群资源消耗极不稳定。Redis集群出现了混乱，首先是错误执行了主从切换，又因为OOM被操作系统杀死（可手动设置内存使用上限），且平均响应时间达到4.27ms。因此，在未经足够优化的条件下，Redis集群在大数据块的写入操作下，显得并不稳定。
三、测试小结
在6000个并发线程发起300W个10KB大小Document的写入请求压力下，Couchbase集群能够稳定提供6K以上的OPS，平均响应时间只有1.16ms，而Redis集群显得极不稳定且平均响应时间长达4.27ms。因此，在大数据块的写入操作下，Couchbase集群显得更高效更可靠。
【 小块数据大数据量读取测试】
每台OPS客户端向集群发送1000W个100字节大小的数据读取请求，并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据读取请求,并统计响应时间。
一、 Couchbase读取测试
六台OPS压力客户端分别启动500个并发线程和4个bucket连接数分别从Couchbase集群读取1000W条数据，即3000个并发线程发起6000W个100字节大小的Document的读取请求，一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中，测试和统计Couchbase集群的服务处理速度，测试结果如下：
压测前Couchbase集群的RsponseTime统计：
10.20.135.66
Couchbase控台监控情况如下：
Couchbase集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端的资源消耗如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
虽然Couchbase集群没有达到满负荷，但此时平均响应时间已长达7.04ms，继续追加压力会造成响应时间的快速增长，再一味追求OPS已经没有意义，且尝试追加一台OPS客户端后OPS提升并不明显。
因此在拥有2000W条100字节数据的Couchbase集群中，正常情况下读取操作的响应时间只有0.35ms，3000个线程并发进行总计6000W次的100字节的数据查询操作，Couchbase集群能稳定提供51W以上的OPS，但平均响应时间长达7.04ms。
二、 Redis读取测试
六台OPS压力客户端分别启动500个并发线程和300个并发连接数分别从Redis集群读取1000W条数据，即3000个并发线程发起6000W个100字节大小的数据读取请求，一台RsponseTime压测客户端在OPS压测过程中，测试和统计Redis集群的服务处理速度，测试结果如下：
压测前Redis集群的RsponseTime统计：
10.20.135.66
Redis集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端资源消耗如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
虽然Redis集群没有达到满负荷，但此时平均响应时间已长达9.12ms，继续追加压力会造成响应时间的快速增长，再一味追求OPS已经没有意义，且尝试追加一台OPS客户端后OPS提升并不明显。
因此在拥有2000W条100字节数据的Redis集群中，正常情况下读取操作的响应时间只有0.74ms，3000个线程并发进行总计6000W次的100字节的数据查询操作压力下，Redis集群能稳定提供18W以上的OPS，但平均响应时间长达9.12ms。
三、 测试小结
在2000W条100字节数据的规模下，Redis和Couchbase仍然可以为读取请求提供亚毫秒级别的处理速度，但Couchbase集群的处理速度（0.35ms）反超Redis集群（0.74ms）一倍。在3000个线程并发进行总计6000W次的100字节的数据查询操作压力下，Redis集群能稳定提供18W的OPS，Couchbase集群能提供稳定51W的OPS，平均响应时间方面两者差异不大。继续增大压力的话，OPS无明显增长Redis的RsponseTime增长速度大于Couchbase，即Redis在较大压力下的处理速度下降较快。
【大块数据小数据量读取测试】
每台OPS客户端向集群发送200W个10KB大小的数据读取请求，并统计OPS;RsponseTime压测客户端向集群发送1W个10KB大小的数据读取请求,并统计响应时间。
一、 Couchbase读取测试
六台OPS压力客户端分别启动500个并发线程和4个bucket连接数（升高和降低该数值性能表现都略有降低）分别从Couchbase集群读取200W条数据，即3000个并发线程发起1200W个10KB大小的Document的读取请求，一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中，测试和统计Couchbase集群的服务处理速度，测试结果如下：
压测前Couchbase集群的RsponseTime统计：
10.20.135.66
Couchbase控台监控情况如下：
Couchbase集群的资源消耗情况如下：
10.20.135.71
10.20.135.72
10.20.135.73
OPS压测客户端的资源消耗如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
OPS压测客户端统计如下：
10.20.135.57
10.20.135.58
10.20.135.67
10.20.135.68
10.20.135.69
10.20.135.70
RsponseTime压测客户端统计如下：
10.20.135.66
测试结果分析：
Couchbase集群资源消耗未达到机器瓶颈，但即使再增加压力OPS也不会有明显增加，平均响应时间倒是明显增长。因此，三台4核8G的Couchbase集群，正常情况下能为客户端读取操作提供0.68ms的平均响应时间，在300W条10KB大小数据块的规模下，3000个并发线程发起1200W个10KB大小的Document的读取请求压力下，Couchbase集群能够稳定提供9W以上的OPS，平均响应时间只有2.79ms。
【测试总结】
经过以上测试，我们可以得到以下结论：
▲小块数据，小数据量下
Redis以更小的资源消耗提供了更高的OPS和更快的服务速度，因其接口设计不同，相较Couchbase还减少了网络传输。因此，Redis更适合作为一个更轻更快的组件集成到整个系统中。
▲小数据块，大数据量下
Redis以更低的资源消耗提供了和Couchbase相当的数据写入OPS，但此时的服务速度已经明显落后于Couchbase；数据读取操作上Couchbase以更低的响应时间提供了几乎三倍于Redis的OPS（配置了View Index，4.0以后的N1QL能进一步提高查询性能）。因此对于拥有一定的数据规模，且写少查多的场景，Couchbase无疑是更加合适的选择。
▲大块数据，小数据量下
在同样未经优化的情况下，Redis集群不发生崩溃已经是幸事(后续我们会推出针对性的优化建议以及实测报告)，如果你需要进行整页缓存，图片或文件存储，又没有足够的精力去完成集群优化管理和异常分析处理，建议选择Couchbase。
▲大块数据，大数据量下
二选一的情况下，直接选择Couchbase。