1. 概述

测试目标

测试redis主从模式和redis集群模式下，写入master，从slave是否能够立即get到最新结果？如果get是旧的，从set之后多长时间可以get到新数据？

测试条件

• 主从模式：master和slave分别部署在两台独立的vm，配置都是4c8g
• 集群模式：3主3从，部署在一台机器，配置是4c8g
• 测试资源：redis client采用pyredis和redis-py-cluster，通过locust做压力测试，部署到另外两台机器，分别是8c16g和4c8g

2. Test Results in Master-slave Mode

2.1. test case 1

load value

• duration 10m
• 10 Users
• master cpu 11%
• slave cpu 10%
• rps 361
• median response time 2ms

result

• no errors
• report for details

2.2. test case 2

load value

• duration 10m
• 100 Users
• master cpu 50%
• slave cpu 41%
• rps 3907
• median response time 4ms

result

• max 58ms, min 2ms, average ~15ms
• probability 240/2298306=0.01%
• report for details

2.3. test case 3

load value

• duration 10m
• 500 Users
• master cpu 60%
• slave cpu 59%
• rps 7010
• median response time 36ms

result

• max 46ms, min 44ms, average 45ms
• probability 3/4399069=0.00007%
• report for details

2.4. test case 4

load value

• duration 15m
• 1000 Users
• master cpu 70%
• slave cpu 69%
• rps 9829
• median response time 75ms

result

• max 141ms, min 69ms, average ~90ms
• probability 7/8667389=0.00008%
• report for details

3. Test Results in Cluster Mode

在redis集群下，做相同的测试，对比结果。

3.1. test case 1

load value

• duration 10m
• 100 Users
• 6 instances's cpu 10-30% master, 10% slave
• rps 3889
• median response time 4ms

result

• no errors
• report for details

3.2. test case 2

load value

• duration 10m
• 500 Users
• 6 instances's cpu 30-50% master, 10% slave
• rps 6957
• median response time 40ms

result

• no errors
• report for details

3.3. test case 3

load value

• duration 10m
• 1000 Users
• 6 instances's cpu 50-60% master, 10% slave
• rps 11996
• median response time 50ms

result

• no errors
• report for details

4. 测试结论

关于读写分离

在主从模式下，slave是默认可读的，但是存在数据延迟，延迟随着并发用户数增加，先增加后降低，例如

• 10users时，slave没有数据延迟
• 100users时，slave有240个数据延迟，发生概率240/2298306=0.01%，最高
• 500和1000users时，slave在高rps的情况下，数据延迟反而分别是3和4个。猜测原因是response time的增加掩盖了数据延迟的问题，response time分别是36ms和75ms

在集群模式下，slave默认不可读的，如果要读slave，需要创建connection之后执行readonly命令，告知redis-server允许数据延迟

在集群模式下，直接读slave，会收到Redirect Error，可以参考redirect机制。采用redis-cluster-client可以避免类似问题，如果采用redis-cli，记得加-c

redis集群的哈希slot redis集群的move redirect操作

所以，如果不要求数据强一致性，随意。如果要求数据强一致性：

• 并发量小的话，可以采用主从模式，只读master，不要读slave，维护方便，且够用
• 并发很大的话，可以采用集群模式，可以连接到任一节点，随意读写，集群维护、代码开发、单request的响应时间等都会变差，但是支持高并发，最多支持1w个master节点，每个节点10GB的话，一共1TB内存

关于Redis集群

Redis集群是官方推荐的分布式解决方案，但是，生态还不健全，有待进一步发展，例如redis cluster proxy、redis cluster client、redis cluster monitor/dashboard等。

所以，各家大厂纷纷自主开发了自己的redis相关项目，以满足自己的业务需求。如果没有迫切需求，还是不建议用cluster，主从模式很经典，基本可以满足90%业务需求。

5. 测试趣闻

打铁还需自身硬

刚开始，采用locust单进程1000users压测redis，没有出现slave数据延迟。
后来，单机6个locust进程同时压测redis，还是出不来。
此时，开始怀疑是不是用户太少，master与slave同步太快？
于是，还是单机6个locust进程，共计1w个user压测，已到redis maxclients限制，还是没达到预期。
调整redis maxclients到10w，压测1.5w，还是没有slave数据延迟。
最后，感觉单机8c16g压测两个4c8g估计不行，需要采用locust分布式测试方案。
Finally，采用两台机器，配置分别是8c16g和4c8g，部署分布式locust压测达到预期，出现了slave数据延迟。

压测资源需要足够稳定

压缩cluster时候，需要更换pyredis为redis-py-cluster，否则直接报错，因为pyredis不处理redirect。
在pyredis 1000 users很轻松的情况下，redis-py-cluster居然在100 users情况下，出现locust workder missing（报错greenlet.GreenletExit，感觉这个pip包redis-py-cluster不太稳定）的情况。
曾经一度怀疑是redis-py-cluster的问题，想用它压测一下redis主从，确认问题是否能复现。（当然，我现在也没深入看redis-py-cluster，不排查其问题）
后来，4c8g的压测机卡死了。
重启之后，再压缩cluster，500users和1000users都正常。