2 redis 慢查詢、pipeline優化、發佈訂閱、特殊類型

時間 2019-12-01

標籤 redis 查詢 pipeline 優化發佈訂閱特殊類型欄目 Redis 简体版

原文原文鏈接

Redis命令的生命週期

客戶端向Redis服務器發送命令
命令請求在請求隊列中排隊等待處理
執行命令
返回命令結果

Redis慢查詢

慢查詢發生在生命週期的第三階段，是指僅僅執行命令階段比較慢被稱爲慢查詢。
客戶端超時不必定是慢查詢，可是慢查詢時是客戶端超時的一個可能因素。

Redis慢查詢相關配置

1. slowlog-max-len

它決定了慢查詢日誌最多能保存多少條日誌，slow log自己是一個內存中的FIFO隊列，當隊列大小超過slowlog-max-len時，最舊的一條日誌將被刪除，而最新的一條日誌加入到slow log中。java

默認值：128
支持動態配置

2.slowlog-log-slower-than

它決定要對執行時間大於多少微妙（microsecond ， 1秒=1,000,000 微妙）的查詢進行記錄git

默認值：10000redis
slowlog-log-slower-than = 0 ，記錄全部命令算法
slowlog-log-slower-than < 0 , 不記錄任何命令服務器
支持動態配置網絡

慢查詢相關命令

1.slowlog get [n]

含義：獲取慢查詢列表中的慢查詢信息
- n：獲取出多少條慢查詢數據信息

2.slowlog len

含義：獲取慢查詢隊列長度

3.slowlog reset

含義：清空慢查詢隊列

慢查詢信息字段

字段1：惟一性的日誌標識符（Integer）
字段2：被記錄命令的執行時間點，已UNIX時間戳格式表示（Integer）
字段3：查詢執行時間，以微秒爲單位
字段4：完整的執行命令

慢查詢運維經驗

slowlog-log-slower-than不要設置過大，默認10ms，一般設置1ms運維
- 由於Redis的qps是萬級別的，即每秒應能執行10000次請求
- 當一條命令執行1ms時，那每秒只能執行1000次請求
slowlog-max-len不要設置地太小，一般設置1000左右ide
須要理解命令的生命週期性能
按期持久化慢查詢google
- 由於慢查詢只存儲於內存中，一宕機慢查詢數據就會丟失
- 經過按期slowlog get將慢查詢數據轉存到MySQL或者ES中

pipeline的好處

省略因爲單線程致使的命令排隊時間，一次命令的消耗時間=一次網絡時間 + 命令執行時間
比起命令執行時間，網絡時間極可能成爲系統的瓶頸
pipeline的做用是將一批命令進行打包，而後發送給服務器，服務器執行完按順序打包返回。
經過pipeline，一次pipeline（n條命令）=一次網絡時間 + n次命令時間

命令	N個命令操做	1次pupeline（n個命令）
時間	n次網絡+n次命令	1次網絡+n次命令
數據量	1條命令	n條命令

pipeline-Jedis使用

//沒有使用pipieline的狀況下
public void testWithoutPipeline() {
    Jedis jedis = new Jedis("127.0.0.1" , 6379);
    for(int i = 1 ; i <= 10000 ; i++ ) {
        jedis.hset("hashKey-" + i , "field-" + i , "value-" + i);
    }
}

//使用pipeline的狀況下
public void testPipeline() {
    Jedis jedis = new Jedis("127.0.0.1" , 6379);
    for(int i = 0 ; i < 100 ; i++ ) {
        Pipeline pipeline = jedis.pipelined();
        for(int j = i * 100 ; i < (i+1) * 100 ; j++ ) {
            pipeline.hset("hashKey-" + j , "field-" + j , "value-" + j);
        }
        pipeline.syncAndReturnAll();
    }
}
複製代碼

pipeline VS M操做（mget、mset）

M操做在Redis隊列中是一個原子操做，pipeline不是原子操做
pipeline與M操做都會將數據順序的傳送與順序地返回

pipeline注意事項

每次pipeline攜帶數量不推薦過大，不然會影響網絡性能
pipeline每次只能做用在一個Redis節點上

發佈訂閱的角色與通訊模型

1.角色

發佈者（publisher）
訂閱者（subscriber）
頻道（channel）

2.通訊模型

RedisServer中能夠建立若干channel
一個訂閱者能夠訂閱多個channel
當發佈者向一個頻道中發佈一條消息時，全部的訂閱者都將會收到消息
Redis的發佈訂閱模型沒有消息積壓功能，即新加入的訂閱者收不到發佈者以前發佈的消息
當訂閱者收到消息時，消息內容以下
- 第一行：固定內容message
- 第二行：channel的名稱
- 第三行：收到的新消息

發佈訂閱的API

1.publish channel message

含義：向指定的channel中發佈消息

2.subscribe channel1 [channel2...]

含義：訂閱給定的一個或多個渠道的消息

3.unsubcribe [channel1 [channel2...]]

含義：取消訂閱給定的一個或多個渠道的消息

###4.psubscribe pattern1 [pattern2...]

含義：訂閱一個或多個符合給定模式的頻道

###5.punsubscribe [pattern1 [pattern2...]]

含義：退訂全部給定模式的頻道

6.pubsub channels

含義：列出至少有一個訂閱者的頻道

###7.pubsub numsub [channel...]

含義：列出給定頻道的訂閱者數量

發佈訂閱-Jedis

//訂閱
public void testSubscribe() {
    Jedis jedis = new Jedis("127.0.0.1" , 6379);
    jedis.subscribe(new JedisPubSub() {
        @Override
        public void onMessage(String channel, String message) {
            System.out.println("receive channel ["+channel+"] message ["+message+"]");
        }
    } , "aliTV" , "googleTV");
}

//發佈
public void testPublish() {
    Jedis jedis = new Jedis("127.0.0.1" , 6379);
    jedis.publish("aliTV" , "I am xuyinan");
    jedis.publish("googleTV" , "My age is 27");
}
複製代碼