压测节点拓扑图：
jmeter是三节点：每个节点都是默认的1500cpu，1.5G内存
redis-provider是一个转发redis请求的代理服务，配置为：3000cpu，1.5G内存
redis是RedisSentinel部署一主两从，版本为redis-5.0.7，只有主节点接受写。
jmeter压测监控
jmeter的监控线程从200逐渐增大到500，但是吞吐量并没有明显提升，响应时间也基本没有变化。从jmeter两个slave节点的监控可以看到，cpu和内存仍有很大空闲，吞吐量没有提升，说明下游有瓶颈。
redis-provider服务监控
redis服务的cpu被提升到了3000，可以看到实际达到1500后就没有再增长了。jmeter的流量到redis-provider后cpu就压不上来了，说明cpu不是瓶颈，那就是I/O有瓶颈了，但是redis-provider服务的带宽远没有到顶。那说明下游的redis数据库有瓶颈。
redis数据库的监控
可以看到redis的CPU每次压测调用虽然使用率上升了，但是仍有80%以上的CPU资源空闲着，说明cpu也不是redis的瓶颈，IO带宽也远没有打满。但是从系统监控中看到，redis的Context Switches有飙升，和压测节点的波形基本吻合，还有一点比较特别的是三台redis中，有一台redis每秒执行的命令数是另外两台的四倍。
redis的context switches问题
原本以为context switches是线程切换导致的，但是redis使用的5.x版本仍然是单线程，6.x开始才支持multi-thread。在redis官网查了一下，context-switch是SocketIO每次调用read/write系统调用时内核态与用户态之间切换导致的。redis推荐用pipeline来减少SocketIO导致的IO性能影响。
RedisSentinel主节点接受写
RedisSentinel是主从异步同步的，只有主节点能接受写操作，所有节点都能接受读操作，所以集群中主节点会接受更多的请求。
结论
redis-provider应用CPU在2000即可达到1.4K的吞吐量，CPU不是应用的瓶颈。redis数据库的瓶颈在于SocketIO的内核态与用户态的切换，以及RedisSentinel单个主节点接受写操作导致写入速度有瓶颈。
