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
所以，如果不要求数据
强一致性，随意。如果要求数据强一致性：
- 并发量小的话，可以采用主从模式，只读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都正常。
