Redis :: TimeoutError：連接超時錯誤 - 郵件緩存

我們使用redis（Elasticache）作爲我們的緩存store.We由於redis連接超時而在我們的應用中遇到崩潰。我們有三個應用服務器並使用phusion乘客。在發生崩潰時，大約有200個活動連接。Redis :: TimeoutError：連接超時錯誤 - 郵件緩存

/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:55:in `rescue in _read_from_socket' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:48:in `_read_from_socket' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:41:in `gets' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:273:in `read' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:248:in `block in read' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:236:in `io' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:247:in `read' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:112:in `block in call' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:217:in `block (2 levels) in process' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:353:in `ensure_connected' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:207:in `block in process' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:292:in `logging' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:206:in `process' 
/home/chillr/deploy/chillr-api/shared/vendor/bundle/ruby/2.2.0/gems/redis-3.2.1/lib/redis/client.rb:112:in `call'

SlOWLOG命令

1) 1) (integer) 6867375 
2) (integer) 1486701507 
3) (integer) 62008 
4) 1) "eval" 
    2) "for i, name in ipairs(redis.call('KEYS', 'cache:user_transaction_logs:*:9008245678')) do redis.call('DEL', name); end" 
    3) "0" 
2) 1) (integer) 6867374 
    2) (integer) 1486701507 
    3) (integer) 61989 
    4) 1) "KEYS" 
     2) "cache:user_transaction_logs:*:9008245678" 
3) 1) (integer) 6867373 
    2) (integer) 1486701507 
    3) (integer) 61026 
    4) 1) "eval" 
     2) "for i, name in ipairs(redis.call('KEYS', 'cache:user_transaction_logs:*:8888662136')) do redis.call('DEL', name); end" 
     3) "0" 
4) 1) (integer) 6867372 
    2) (integer) 1486701507 
    3) (integer) 61006 
    4) 1) "KEYS" 
     2) "cache:user_transaction_logs:*:8888662136" 
5) 1) (integer) 6867371 
    2) (integer) 1486701507 
    3) (integer) 63070 
    4) 1) "eval"

我們使用

Elasticache緩存。
t2.medium的Phusion客運

無連接中的崩潰175..200的時間

GEM redis的（3.2.1） redis的護欄（5.0.1）

可以做些什麼

來源

2017-02-10 tes

不要在生產中使用的密鑰：https://redis.io/commands/keys –

但是我們無法迴避它在這個case.We想獲取一個用戶的所有交易from cache.Any alternatives – tes

您可以嘗試掃描或更改數據的結構，以便您可以直接查找用戶事務，例如使用將用戶標識鏈接到事務ID的集合 –

監控你的redis服務器的當前資源使用情況。暫時增加您的連接超時redis連接。

試試這個檢查表第一

https://redis.io/topics/latency

來源

2017-02-10 11:58:31

我們升級了我們的彈出式服務器。等也看到 – tes

好酷，讓我們知道結果 –

Redis :: TimeoutError：連接超時錯誤 - 郵件緩存

回答

相關問題