1.Redis性能测试

性能测试的基本场景很多，例如有

技术选型，例如测试Memcached和Redis；
对比单机Redis和集群Redis的吞吐量；
评估不同类型的存储性能，例如无序集合和有序集合；
对比开启持久化和关闭持久化的吞吐量；
对比调优和未调优的吞吐量；
对比不同Redis版本的吞吐量，作为是否升级的一个参考标准。

性能测试的两种方式
1. 编写代码模拟并发进行性能测试：自行编写代码进行性能测试的方式不够灵活，且很难短时间内模拟大量的并发数，不建议使用这种方式。
2. 使用redis-benchmark进行测试(Redis基准测试)
- 使用redis-benchmark -h查看基准测试的使用。

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests>] [-k <boolean>]
 -h <hostname>      Server hostname (default 127.0.0.1)
 -p <port>          Server port (default 6379)
 -s <socket>        Server socket (overrides host and port)
 -a <password>      Password for Redis Auth
 -c <clients>       Number of parallel connections (default 50)默认50
 -n <requests>      Total number of requests (default 100000)
 -d <size>          Data size of SET/GET value in bytes (default 3)
 --dbnum <db>       SELECT the specified db number (default 0)
 -k <boolean>       1=keep alive 0=reconnect (default 1)
 -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
  Using this option the benchmark will expand the string __rand_int__
  inside an argument with a 12 digits number in the specified range
  from 0 to keyspacelen-1. The substitution changes every time a command
  is executed. Default tests use this to hit random keys in the
  specified range.
 -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
 -e                 If server replies with errors, show them on stdout.
                    (no more than 1 error per second is displayed)
 -q                 Quiet. Just show query/sec values
 --csv              Output in CSV format
 -l                 Loop. Run the tests forever
 -t <tests>         Only run the comma separated list of tests. The test
                    names are the same as the ones produced as output.
 -I                 Idle mode. Just open N idle connections and wait.

基准测试的基本使用，执行redis-benchmark。

====== PING_INLINE ======
  100000 requests completed in 1.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.81% <= 1 milliseconds
100.00% <= 2 milliseconds
79302.14 requests per second
====== PING_BULK ======
  100000 requests completed in 1.29 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.83% <= 1 milliseconds
100.00% <= 1 milliseconds
77459.34 requests per second
====== SET ======
  100000 requests completed in 1.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.80% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 2 milliseconds
79239.30 requests per second
====== GET ======
  100000 requests completed in 1.19 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.72% <= 1 milliseconds
99.95% <= 15 milliseconds
100.00% <= 16 milliseconds
100.00% <= 16 milliseconds
84104.29 requests per second
====== INCR ======
  100000 requests completed in 1.17 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.86% <= 1 milliseconds
100.00% <= 1 milliseconds
85397.09 requests per second
====== LPUSH ======
  100000 requests completed in 1.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.79% <= 1 milliseconds
100.00% <= 1 milliseconds
82169.27 requests per second
====== RPUSH ======
  100000 requests completed in 1.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.71% <= 1 milliseconds
100.00% <= 1 milliseconds
81900.09 requests per second
====== LPOP ======
  100000 requests completed in 1.29 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.78% <= 1 milliseconds
99.95% <= 13 milliseconds
99.97% <= 14 milliseconds
100.00% <= 14 milliseconds
77399.38 requests per second
====== RPOP ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.82% <= 1 milliseconds
100.00% <= 1 milliseconds
80192.46 requests per second
====== SADD ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.74% <= 1 milliseconds
100.00% <= 1 milliseconds
80192.46 requests per second
====== HSET ======
  100000 requests completed in 1.21 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.86% <= 1 milliseconds
100.00% <= 1 milliseconds
82440.23 requests per second
====== SPOP ======
  100000 requests completed in 1.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.92% <= 1 milliseconds
100.00% <= 1 milliseconds
81699.35 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 1.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.69% <= 1 milliseconds
99.95% <= 13 milliseconds
99.99% <= 14 milliseconds
100.00% <= 14 milliseconds
79176.56 requests per second
====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.57% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
80128.20 requests per second
====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.91% <= 1 milliseconds
100.00% <= 1 milliseconds
80064.05 requests per second
====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.78% <= 1 milliseconds
100.00% <= 1 milliseconds
76863.95 requests per second
====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 1.20 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.85% <= 1 milliseconds
100.00% <= 1 milliseconds
83263.95 requests per second
====== MSET (10 keys) ======
  100000 requests completed in 1.27 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.65% <= 1 milliseconds
100.00% <= 1 milliseconds
78740.16 requests per second

精简测试：使用redis-benchmark -t set,get,incr -n 1000000 -q可以对Redis服务器进行精简测试

SET: 37136.07 requests per second
GET: 33415.76 requests per second
INCR: 28261.36 requests per second

-q:输出结果为精简模式。

管道测试:执行redis-benchmark -t set,get,incr -n 1000000 -q -P 10(每次执行10个Redis命令)

SET: 628535.50 requests per second
GET: 654450.25 requests per second
INCR: 647249.19 requests per second

1.1基准测试影响因素

基准测试会受到外部因素的影响从而导致性能不能达到理论上得到最高值。主要原因：

网络带宽和网速延迟。
CPU计算性能不足
在虚拟设备上运行会产生额外的消耗
普通操作和批量操作的影响

2.Redis慢查询

作用：查询出不合理的执行命令，可以让开发和运维人员规避这些命令，让服务器更加高效快捷。
相关的两条命令

slowlog-log-slower-than：用于设定慢查询的评定时间。即超过该配置项的命令将会被记录在慢查询日志中，执行单位是微秒
slowlog-max-len：用来配置慢查询日志的最大记录数。

慢查询的默认配置：

127.0.0.1:6379> config get slowlog-log-slower-than #慢查询判断时间
1) "slowlog-log-slower-than"
2) "10000"
127.0.0.1:6379> config get slowlog-max-len #慢查询最大记录条数
1) "slowlog-max-len"
2) "128"

通过config set 命令修改配置。使用slowlog show来查询慢日志。
慢查询的其他相关命令

命令	功能
slowlog get n	查询指定条数的慢日志
slowlog len	获取慢查询队列长度
slowlog reset	清空慢查询日志

3.Redis哨兵(Sentine）

打开哨兵的配置文件。vim Sentinr.conf。修改daemoinze no为yes即可。哨兵模式。

原文链接：https://blog.csdn.net/weixin_42763269/article/details/109714845