大數據下Redis的應用

1、Redis客戶端區別

1.1 redis常用客戶端

目前市面上比較流行的客戶端有jedis、lettuce、redisson

jedis

jedis客戶端連接方式是基于TCP阻塞方式

lettuce

lettuce內部是基于netty的多路復用異步非阻塞方式（目前業界解決高并發大數據的問題的思路）

redisson

相對于上面兩種使用得較少

在并發數量不大的情況下，兩者性能可能差不多，jedis的性能可能還優于lettuce，但當并發量的提升，jedis的超時錯誤會增加，但lettuce只是平均響應時間增加和最大響應時間會增加，lettuce是已穩定性為主的。

1.2 epoll模型-單線程的redis為什么快

redis內部使用epoll模型來提高鏈接處理能力

傳統TCP鏈接與epoll模型的本質區別

TCP鏈接存在鏈接數瓶頸，隨著連接數的增加，響應速度會明顯變慢

epoll可支持更大數量的連接數而不會對性能有明顯的影響

2、大數據下的redis的存儲方案

2.1 分片模式

分片模式是把部署多個redis節點，然后由客戶端決定數據分片規則，常見的分片規則就是以節點數量進行哈希分片

優點：

服務端不需要進行繁瑣的配置，由客戶端決定路由規則

缺點：

缺點很明顯，如果多個節點中的某個節點掛了，將丟失這一部分數據，因為客戶端還是為每個節點分配了連接，而且客戶端配置分片節點IP的時候要注意

IP列表的順序不能隨意指定順序，IP變更也會影響數據，擴容相當麻煩。

建議：如果分片節點較少可以使用分片來適當的分攤壓力

配置示例：

spring : 
           remote : 
      ecredis : 
        type : sharding 
        uri : 
                   - 192.168.1.3:6379 
                   - 192.168.1.4:6379 
                   - 192.168.1.5:6379 
                   - 192.168.1.6:6379 
                   - 192.168.1.7:6379 
        db : 1 
        maxIdle : 10 
        minIdle : 5 
        maxActive : 10 
        password : GpG4fZoxsp7cTB5f 
        keyPrefix : 'ERP:EXPORT-CENTER:' 

2.2 哨兵機制

在Redis 2.8版本開始引入，就有了哨兵這個概念，哨兵實現了自動化的故障恢復，無需關心IP是否變更。

優點：

哨兵模式是基于主從模式的，所有主從的優點，哨兵模式都具有。

主從可以自動切換，系統更健壯，可用性更高。

Sentinel 會不斷的檢查 主服務器 和 從服務器 是否正常運行。當被監控的某個 Redis 服務器出現問題，Sentinel 通過API腳本向管理員或者其他的應用程序發送通知。

  缺點：

Redis較難支持在線擴容，對于集群，容量達到上限時在線擴容會變得很復雜。

spring : 
  redis : 
    password : 123456 
    sentinel : 
      master : master 
      nodes : 47.98.217.106:26379,47.98.217.109:26380,47.98.217.109:26381 
    timeout : 20000 
    database : 0 
    jedis : 
      pool : 
        max-active : 300 
        max-wait : -1 
        max-idle : 100 
        min-idle : 20 

2.3 redis cluster集群

通過數據分片的方式來進行數據共享問題，同時提供數據復制和故障轉移功能，包含了哨兵模式的所有功能。

優點：數據按slot來分散存儲，訪問任何一個master節點都可以獲取任何分片上面的數據，任何一個master節點都可以做擴容或者新增master節點的時候，數據會自動分片同步遷移(redis集群的重新分片由redis內部的redis-trib負責執行)，服務器不需要下線。如果每個master使用了主從模式，那么當master發生故障的時候，下面的slave們會選舉一個新的master

缺點：需要使用ruby進行部署，配置相當麻煩，維護不方便

配置示例：

spring : 
  redis : 
    password : 
    cluster : 
      nodes : 192.168.1.3:6379,192.168.1.4:6379,192.168.1.5:6379 
      max-redirects : 3 
    lettuce : 
      pool : 
        max-idle : 16 
        max-active : 32 
        min-idle : 8 

2.4 cachecloud

cachecloud是一套解決方案，實現多種類型(Redis Standalone、Redis Sentinel、Redis Cluster)自動部署、解決Redis實例碎片化現象、提供完善統計、監控、運維功能、減少運維成本和誤操作，提高機器的利用率，提供靈活的伸縮

優點：

使配置更簡單，集群節點不再由客戶端維護，配置一個domain即可自動獲取節點列表

配置示例：

spring : 
           domain : cachecloud.server1.com:8080 
           remote : 
      ecredis : 
                 appid : 2 
        type : cloud 
        uri : 
        db : 1 
        maxIdle : 10 
        minIdle : 5 
        maxActive : 10 
        password : GpG4fZoxsp7cTB5f 
        keyPrefix : 'ERP:EXPORT-CENTER:' 

應用案例：

2.5 redis存儲方案選型

吞吐量數據量較少、數據安全性不高：單機模式或者分片模式

吞吐量數據量較大、數據安全性較高：哨兵模式、集群模式

吞吐量數據量大、數據安全性高、擴展性強：集群模式

3、性能優化

3.1 日志優化

Redis日志存儲模式分為兩種：RDB和AOF，RDB為實時寫入磁盤，AOF為延遲批量寫入磁盤

RDB模式：

優點：實時存儲日志，在數據恢復方面更有優勢

缺點：磁盤IO比較頻繁，會影響redis的吞吐能力

AOF模式：

優點：定時批量刷新日志到磁盤，適合高吞吐的場景，對redis性能影響較小

缺點：如果某一個時刻redis發生故障，可能會丟失內存中的數據，故障恢復的時候恢復不了這部分數據

模式選擇：

如果吞吐量較小，使用RDB即可，吞吐量較大，可以選擇AOF來提高性能，兩種方式根據具體場景來選擇

AOF配置:

appendonly yes 
#aof文件名設置 
appendfilename "appendonly-${port}.aof" 
#配置選擇 
appendfsync everysec 
dir /bigdiskpath 
#不開啟aof重寫，因為太消耗性能 
no-appendfsync-on-rewrite yes 

AOF重寫：分析當前redis中key對應的值來優化指令，來減少磁盤空間和壓力，但因為需要判斷合并邏輯，會有很大的性能開銷，一般不開啟aof重寫

# 假設服務器對鍵list執行了以下命令; 
127.0.0.1:6379> RPUSH list "A" "B" 
(integer) 2 
127.0.0.1:6379> RPUSH list "C" 
(integer) 3 
127.0.0.1:6379> RPUSH list "D" "E" 
(integer) 5 
127.0.0.1:6379> LPOP list 
"A" 
127.0.0.1:6379> LPOP list 
"B" 
127.0.0.1:6379> RPUSH list "F" "G" 
(integer) 5 
127.0.0.1:6379> LRANGE list 0 -1 
1) "C" 
2) "D" 
3) "E" 
4) "F" 
5) "G" 
127.0.0.1:6379> 

正常AOF會把前面的6條寫入命令都存入日志中，AOF重寫會先去redis獲取list的值，發現是["C","D","E","F","G"]，然后生成一條 RPUSH list "C" "D" "E" "F" "G" 來代替前面6條

3.2 緩存更新策略

redis默認情況下就是使用LRU策略的，因為內存是有限的，但是如果你不斷地往redis里面寫入數據，那肯定是沒法存放下所有的數據在內存的

除了LRU，還可以使用scan的方式進行輪詢ttl的方式清理

3.3 代碼中使用redis的一些建議

避免使用keys *這種模糊查詢，會阻塞當前線程，使用scan的方式去處理，redis客戶端建議不要使用redis desktop manager

String cursor = ScanParams . SCAN_POINTER_START ; 
ScanParams scanParams = new ScanParams (); 
// 匹配表達式 
scanParams . match ( "key*" ); 
// 每次scan的條數 
scanParams . count ( 1000 ); 
while ( true ) { 
           ScanResult << span=""> String > result = jedis . scan ( cursor , scanParams ); 
           cursor = result . getStringCursor (); 
           if ( "0" . equals ( cursor )) { 
                      break ; 
           } 
} 

hgetall也應該避免使用，使用hscan代替，但如果通過RedisTemplate回調的方式使用hscan應該注意資源的釋放，否則會出現請求到達一定次數的時候就不能發起請求的問題(客戶端hang住了)

如果set的時候同時設置expire過期時間，不要先set再expire這種方式，應該使用原子操作

set key value [EX seconds] [PX milliseconds] [NX|XX] 

對于同一個需求多次改版redis中寫入不同格式的數據，會產生兼容性問題，可以使用type命令去處理兼容，然后監控等老數據不存在之后再把判斷邏輯移除

String type = jedis . type ( "a" ); 
if ( "string" . equalsIgnoreCase ( type )) { 
  // do something 
} else if ( "list" . equalsIgnoreCase ( type )) { 
  // do something 
} 

如果redis中的數據需要做去重，可以使用set或hashmap，hashmap性能更高，但對于維護hashmap數據結構之外的數據比較多，之前測試過，100B的數據存放到hashmap，但實際占用量可能有200B~300B甚至更多，set對于數據多的情況下性能會低一點

建議：數據少的情況下用set，數據多就用hashmap，但要注意盡量減少存儲內容的長度，比如{"source":"order"}可以改成{"s":1}

去重操作不建議使用list，因為每次判斷都要從list中取數據然后再add進去，多線程操作下還是可能會出現重復問題（比如兩個線程同時lrange操作）

// 在多線程模式下會有問題 
// 假設線程A和線程B同時執行lrange 
List << span=""> String > list = jedis . lrange ( "a" , 0 , - 1 ); 
if (! list . contains ( "bbb" )) { 
                      jedis . lpush ( "bbb" ); 
} 

如果一次處理的命令很多，使用pipeline性能更好

list可以結合lpush/rpop、rpush/lpop來實現隊列功能，但不建議把list當成是MQ的功能，因為沒有記錄的狀態，無法跟蹤數據處理情況

關于redis分布式鎖，目前流行的實現方式還沒有完美的方案，使用lua腳本的版本也不是完美的，如果需求允許延時或者一定時間內不允許執行多次，setnx設置過期時間是最好的方案

4、故障轉移與數據遷移

4.1 數據遷移方案

老節點替換為新節點、新老key兼容處理

將新節點作為老節點的slave節點，等數據自動同步完成之后下架老節點，不建議使用代碼遷移，因為不同業務數據結構可能很多

不同類型的節點之間遷移的方法不同，如果單節點遷移至分片集群只能借助遷移工具來完成

如果新業務將使用新的key，要保留舊key，可以開啟兩個連接池，一個處理新key，一個處理舊key，這樣等舊key都失效的時候移除對舊key的連接就可以完全遷移到新key業務

動態擴容

必須在集群模式下才可以進行動態擴容，也可以使用cachecloud，數據會自動同步到各個節點

在數據遷移的過程中即使訪問的某個key正在遷移，數據也是可以正常返回的，不用擔心遷移過程會對數據訪問造成影響

4.2 故障轉移對于客戶端的影響

redis集群模式雖然可以在某個master節點發生故障的時候自動從slave中選舉節點當master，但類似jedis的客戶端并不支持故障轉移，也就是當集群某節點發生故障正在切換的時候，客戶端如果正在訪問故障節點，這時集群故障轉移還沒有完成，客戶端會報錯，如果需要讓客戶端也支持故障轉移，需要修改jedis客戶端源碼來實現。