性能测试-Redis

功能测试：

主动更新：数据库更新的时候同时更新redis

被动更新：查询的时候更新，数据一致性比较好

一、测试注意点

1、缓存预热

如果程序初次运行，此时由于数据尚未加载到缓存，则程序的响应时间会明显变长
注意事项： 性能测试的时候 出现 非常不稳定的现象程序刚启动，它的性能 明显 低于 已经运行一段时间的
    1.1 测试缓存没有的情况， 系统性能是怎么样的？ 以及 多久才能恢复到正常的性能
        找开发 - 把数据清空，模拟干净的环境
    1.2  测试 缓存已经加载的情况， 系统运行了一段时间，各种业务场景都执行过几轮之后

2、缓存雪崩

模拟redis 挂掉，服务核心主流程是否能运行（允许慢，不能挂掉），重启redis，多长时间可以恢复缓存服务——容错性测试

3、缓存击穿

概念：如果查询的目标是不存在于系统中的数据，则缓存必然失效，缓存大量Miss，可能会导致高并发请求大量 怼到数据库，数据库 处理不过来，可能会影响系统性能，甚至导致系统崩溃

测试方法：请求数据库中不存在的数据，验证系统性能，如果吞吐量下降，说明响应了系统性能

解决方法：数据库中不存在的数据，缓存中保留一条值为null的数据，使得异常请求命中缓存。

4、缓存穿透

概念：

解决方法

二、Redis 瓶颈分析

1.1、redis 资源占用

连接redis后，输入info

Server：服务器

Clients：客户端

Memory：内存

Persistence：持久化配置信息

State：server的一些基本统计信息

   keyspace_hits:226 命中次数
   keyspace_misses:74 miss次数

Replication 获取 server 的主从配置信息

CPU 获取 server 的 CPU 使用信息
    usedcpusys 2.559564 消耗的系统CPU
usedcpuuser 0.878593 消耗的用户CPU
usedcpusys_children 0.001414 后台进程占用的系统CPU
usedcpuuser_children 0.000510 后台进程占用的用户CPU

Keyspace：获取 server 中各个 DB 的 key 的数量
cluster：获取集群节点信息，仅在开启集群后可见

     这个集群 类似 数据库 分库分表
    你要监控的服务器 不止一台

[root@VM-100-3-centos ~]# redis-cli
127.0.0.1:6379> info
# Server
redis_version:6.2.6
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:d767c00d74be2727
redis_mode:standalone
os:Linux 4.14.105-cc1e1d6+ x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:2135
process_supervised:no
run_id:4d98d5f7c709c98b5173dd3c0de6e1eb4d335c4a
tcp_port:6379
server_time_usec:1710399051990387
uptime_in_seconds:21878714
uptime_in_days:253
hz:10
configured_hz:10
lru_clock:15900235
executable:/usr/local/redis/bin/./redis-server
config_file:
io_threads_active:0

# Clients
connected_clients:2
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:24
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0

# Memory
used_memory:894728
used_memory_human:873.76K
used_memory_rss:6557696
used_memory_rss_human:6.25M
used_memory_peak:952816
used_memory_peak_human:930.48K
used_memory_peak_perc:93.90%
used_memory_overhead:850944
used_memory_startup:809840
used_memory_dataset:43784
used_memory_dataset_perc:51.58%
allocator_allocated:939016
allocator_active:1191936
allocator_resident:3706880
total_system_memory:8100679680
total_system_memory_human:7.54G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.27
allocator_frag_bytes:252920
allocator_rss_ratio:3.11
allocator_rss_bytes:2514944
rss_overhead_ratio:1.77
rss_overhead_bytes:2850816
mem_fragmentation_ratio:7.70
mem_fragmentation_bytes:5705736
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:41000
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1706699504
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:471040
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# Stats
total_connections_received:28
total_commands_processed:321
instantaneous_ops_per_sec:0
total_net_input_bytes:39598
total_net_output_bytes:256555
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:15
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:225406
evicted_keys:0
keyspace_hits:226
keyspace_misses:74
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:158
total_forks:15
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:1
dump_payload_sanitizations:0
total_reads_processed:349
total_writes_processed:322
io_threaded_reads_processed:0
io_threaded_writes_processed:0

# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:8e3d6429b68f282d137fc409d69a3b8b6d74ef8d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:5421.144797
used_cpu_user:6813.855050
used_cpu_sys_children:0.019651
used_cpu_user_children:0.003743
used_cpu_sys_main_thread:5421.141904
used_cpu_user_main_thread:6813.850376

# Modules

# Errorstats
errorstat_ERR:count=1

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=1,expires=0,avg_ttl=0
127.0.0.1:6379> 

2、有大量连接

通过info 查看有多少连接

3、响应时间

如何发现影响慢：

（1）info commandstats：查看哪些命令执行的慢

127.0.0.1:6379> info commandstats
# Commandstats
cmdstat_info:calls=1,usec=115,usec_per_call=115.00,rejected_calls=0,failed_calls=0
cmdstat_command:calls=1,usec=397,usec_per_call=397.00,rejected_calls=0,failed_calls=0
cmdstat_keys:calls=0,usec=0,usec_per_call=0.00,rejected_calls=1,failed_calls=0
cmdstat_get:calls=286,usec=1068,usec_per_call=3.73,rejected_calls=0,failed_calls=0
cmdstat_setex:calls=19,usec=140,usec_per_call=7.37,rejected_calls=0,failed_calls=0
cmdstat_exists:calls=15,usec=27,usec_per_call=1.80,rejected_calls=0,failed_calls=0
cmdstat_hello:calls=1,usec=4,usec_per_call=4.00,rejected_calls=0,failed_calls=0
127.0.0.1:6379> 

（2）redis 慢查询日志

slowlog get

127.0.0.1:6379> slowlog get
(empty array)
127.0.0.1:6379> 

响应慢的原因：（1）持久化（2）有大量过期（Redis自动删除，也要消耗资源）

三、调优分析

Redis本身的性能很好，大部分的问题在于 开发人员没有用好Redis

1、pipelining 管道批处理
    比如 将大量数据 加载到 redis就可以用 管道
2、Redis处理命令时采取的单线程，所以不需要大量 Redis连接
3、Redis的应用场景对速度要求很高，采用合理的数据类型，更快速的操作
    纯开发场景
    例如 用户信息保存场景
    采用字符串 string 类型
        set u1001 "{userid:1001,uname:tony,...}"
        每一次查询 必须从redis  查询所有的内容
        增加 网络消耗，增加处理的资源占用
    采用 hash
        类似 python 嵌套的 字典
        可以 将 用户信息 分为多个key进行存放
    通过 Redis 使用课程， 做一个额外的补充
4、尽量避免让开发使用复杂的命令
    例如 keys
    Redis 里面
        标记为 O(1) 命令，代表速度快  
        O（n)、 O(logn) 速度较慢
    如果你看到慢查询日志 里边大量的命令，都是 非 O(1)，就需要让开发人员看下是否能使用其他复杂低的命令代替

Redis 集群介绍及测试思路 - 知乎