8、Redis阻塞

ゝ一纸荒年。 2022-05-27 13:48 117阅读 0赞

## 前言 ##

通过前面那么多我们这里应该很明确知道Rdis单线程结构，在高并发的时候，如果出现阻塞，哪怕是很短时间，都将会是异常噩梦

## 1、发现阻塞 ##

当Redis阻塞发生的时候，线上应用服务应该最先感知到，这个是，应用房，会收到大量的Redis超时异常，常见的作坊是通过邮件，短信预警。借助于日志系统可以查看异常信息。以及借助Redis监控系统发现阻塞问题

## 2、内在原因 ##

上面是定位到Redis异常节点后，首先应该排除是不是redis自身原因导致

### 2.1、API或者数据结构使用不合理 ###

例如，hgetall 包含了成千上万个数据，势必会引发阻塞。不过这种是我们在项目中可以避免的使用hscan ，一般情况下标题的这种情况的发送，是慢查询或者是大对象。

#### 2.1.1、如何发现慢查询 ####

之前我们说过，默认执行超过10毫秒的，会被记录到定长的队列中，显示实际建议即使发现毫秒级以上的命令，如果命令执行时间在毫秒级别。

slowlog get n(n代表最近n条慢查询命令)

发现慢查询后，可以按照下面两个方向去调整  
1>修改为低算法命令，如hgetall改为hmget，禁用keys，sort等命令  
  
2>调整大对象，缩减大对象活把大对象拆分为多个小对象。防止一次命令操作度过多的数据

#### 2.1.2、如果发现大对象 ####

redis本身提供发现大对象的工具，对应命令如下，内部原理是采用scan操作。将历史扫描过的最大对象统计出来便于优化，根据汇总结果可以非常方便的获取到最大对象的键，以及不同类型数据结构的使用情况

redis-cli -p 6379 -h 127.0.0.1  --bigkeys

JeandeMBP:src healerjean$ redis-cli -p 6379 -h 127.0.0.1  --bigkeys
    
    # Scanning the entire keyspace to find biggest keys as well as
    # average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
    # per 100 SCAN commands (not usually needed).
    
    [00.00%] Biggest string found so far 'hello' with 5 bytes
    
    -------- summary -------
    
    Sampled 1 keys in the keyspace!
    Total key length in bytes is 5 (avg len 5.00)
    
    Biggest string found 'hello' has 5 bytes
    
    1 strings with 5 bytes (100.00% of keys, avg size 5.00)
    0 lists with 0 items (00.00% of keys, avg size 0.00)
    0 sets with 0 members (00.00% of keys, avg size 0.00)
    0 hashs with 0 fields (00.00% of keys, avg size 0.00)
    0 zsets with 0 members (00.00% of keys, avg size 0.00)
    JeandeMBP:src healerjean$

### 2.2、CPU饱和 ###

单线程的Redis处理命令只能使用一个CPU，CPU饱和是非常危险的，首先判断当前Redis的并发量是否达到极限。

redis-cli --stat

![WX20180418-112946@2x][WX20180418-112946_2x]

解释：  
\+为每秒处理请求

### 2.3、持久化阻塞 ###

#### 2.3.1、fork阻塞 ####

在RDB和AOF重写的时候，Redis主线程调用fork操作产生共享内存的子进程，由于进程完成持久化文件重写工作，如何fork操作本身耗时过长，必然会导致主线程的阻塞。表示最近一次fork的操作耗时，如果耗时很大，比如超过1秒，则需要作出优化调整。`info stats`

latest_fork_usec:658

127.0.0.1:6380> info stats
    # Stats
    total_connections_received:1
    total_commands_processed:2421
    instantaneous_ops_per_sec:0
    total_net_input_bytes:34608
    total_net_output_bytes:915107
    instantaneous_input_kbps:0.00
    instantaneous_output_kbps:0.04
    rejected_connections:0
    sync_full:0
    sync_partial_ok:0
    sync_partial_err:0
    expired_keys:0
    evicted_keys:0
    keyspace_hits:1
    keyspace_misses:0
    pubsub_channels:0
    pubsub_patterns:0
    latest_fork_usec:658
    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
    127.0.0.1:6380>

#### 2.3.2、AOF刷盘阻塞 ####

当我们开启AOF持久化功能的时候，文件刷盘的方式一般采用每秒一次，当硬盘压力过大的时候，fsync操作需要等待，知道写入完成。`info persistence`

127.0.0.1:6380> info persistence
    # Persistence
    loading:0
    rdb_changes_since_last_save:0
    rdb_bgsave_in_progress:0
    rdb_last_save_time:1523958029
    rdb_last_bgsave_status:ok
    rdb_last_bgsave_time_sec:0
    rdb_current_bgsave_time_sec:-1
    rdb_last_cow_size:0
    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
    127.0.0.1:6380>

## 2、外在原因 ##

### 2.1、CPU竞争 ###

1、进程竞争：Redis是典型的CPU密集型应用，不建议和其他多核CPU密集型服务部署到一起，当其他进程过度消耗CPU的时候，将严重影响Redis

2、绑定CPU：对于开启持久化或者复制的主节点不建议绑定CPU。否则父进程和子进程就会相互竞争

### 2.2、内存交换 ###

Redis保持高性能最重要的一个原因是它的数据保存到内存中，如果保存一部分到硬盘上，会由于读写速度相差太大而出现很大的问题：  
查看redis进程号`info server`

process_id:8313

通过进程号查找 cat /proc/8313/smaps | grep Swap  
如果Swap都是0Kb或个别是4kb，则是正常现象，说明Redis进程内存没有被交换。

127.0.0.1:6380> info server
    # Server
    redis_version:4.0.8
    redis_git_sha1:00000000
    redis_git_dirty:0
    redis_build_id:ad83a037ffc67071
    redis_mode:standalone
    os:Darwin 16.7.0 x86_64
    arch_bits:64
    multiplexing_api:kqueue
    atomicvar_api:atomic-builtin
    gcc_version:4.2.1
    process_id:8313
    run_id:d2099de68745a3bba3c7643535a5a47a8957f18b
    tcp_port:6380
    uptime_in_seconds:82858
    uptime_in_days:0
    hz:10
    lru_clock:14083679
    executable:/usr/local/redis-4.0.9_2/src/redis-server
    config_file:/usr/local/redis-4.0.9_2/redis.conf
    127.0.0.1:6380>

### 2.3、网络问题 ###

#### 2.3.1、连接拒绝 ####

![ContactAuthor][]

[WX20180418-112946_2x]: /images/20220527/0683c6ac5bc1471f9463b8f199df44dc.png
[ContactAuthor]: /images/20220527/87ae14596be142cbbc52aac4d5846e50.png