Redis與Java - 實踐

時間  2019-11-15
標籤 redis java 實踐 欄目 Redis 简体版
原文   原文鏈接

Redis與Java - 實踐

標籤 ： Java與NoSQLjavascript

Transaction

Redis事務(transaction)是一組命令的集合,同命令同樣也是Redis的最小執行單位, Redis保證一個事務內的命令執行不被其餘命令影響.css

`MULTI`
    SADD user:1:following 2
    SADD user:2:follower 1
`EXEC`

vs. RDBMS

事務操做 MySQL Redis
開啓 start transaction MULTI
語句 DML 普通命令
取消 rollback DISCARD
執行 commit EXEC
  • MySQL的rollback與Redis的DISCARD有必定的區別.
    假設如今已經成功執行了事務內的前2條語句, 第3條語句出錯:
    1. MySQLrollback後,前2條的語句影響消失.
    2. Redis能夠分爲兩種狀況:
      • 語法錯誤: 事務中斷, 全部語句均得不到執行;
      • 運行錯誤: (如語法正確,但適用數據類型不對: 像ZADD操做List), EXEC會執行前2條語句, 並跳過第3條語句.
        這樣的部分紅功會致使數據不一致, 而這一點須要由開發人員負責, 好比提早規劃好緩存key的設計.

樂觀鎖與WATCH

悲觀鎖(Pessimistic Lock): 很悲觀,每次讀寫數據都認爲別人會修改,因此每次讀數據都會上鎖,這樣若是別人也想讀寫這條數據就會阻塞, 直到加鎖的人把鎖釋放. 傳統的RDBMS中用到了不少這種鎖機制, 如行鎖、表鎖、讀鎖、寫鎖等.
樂觀鎖(Optimistic Lock): 顧名思義很是樂觀, 每次讀寫數據時候都認爲別人不會修改,因此再也不上鎖,但在更新數據時會判斷一下在此期間有沒有人更新了這條數據, 這個判斷過程可使用版本號等機制實現, 而Redis默認就對樂觀鎖提供了支持 –WATCH命令.html

WATCH命令能夠監控一個/多個key, 一旦其中有一個被修改/刪除, 則以後的事務就不會執行,如用WATCH命令來模擬搶票場景:java

SET ticket 1        # 如今假設只有一張票了
`WATCH` ticket      # 監控票數變化
`MULTI`
    DECRBY username 400
    DECR ticket
        [DECR ticket]   # 如今假設有另一個用戶直接把這張票買走了
`EXEC` -> `(nil)`  # 則這條事務執行就不會成功

小結

  • WATCH命令的做用只是當被監控的key值修改後阻止事務執行,並不能阻止其餘Client修改. 因此一旦EXEC執行失敗, 能夠從新執行整個方法或使用UNWATCH命令取消監控.mysql

  • 樂觀鎖適用於讀多寫少情景,即衝突真的不多發生,這樣能夠省去大量鎖的開銷. 但若是常常產生衝突,上層應用須要不斷的retry,反卻是下降了性能,因此這種狀況悲觀鎖比較適用.nginx

Expire & Cache

Redis可使用EXPIRE命令設置key的過時時間, 到期後Redis會自動刪除它.git

命令 做用
EXPIRE key seconds Set a timeout on key.
TTL key Get the time to live for a key
PERSIST key Remove the expiration for a key

除了PERSIST命令以外,SET/GETSET爲key賦值的同時也會清除key的過時時間.另外若是WATCH監控了一個擁有過時時間的key,key到期自動刪除並不會被WATCH認爲該key被修改.github

  • 緩存DB數據
    爲了提升網站負載能力,常須要將一些訪問頻率較高但對CPU/IO消耗較大的操做結果緩存起來,並但願讓這些緩存過時自動刪除, 下面咱們就使用Redis緩存DB數據, 場景介紹能夠參考:Memcached - In Action:緩存DB查詢數據.
/** * @author jifang. * @since 2016/6/13 20:08. */
public class RedisDAO {

    private static final int _1M = 60 * 1000;

    private static final DataSource dataSource;

    private static final Jedis redis;

    static {
        Properties properties = new Properties();
        try {
            properties.load(ClassLoader.getSystemResourceAsStream("db.properties"));
        } catch (IOException ignored) {
        }

        /** 初始化鏈接池 **/
        HikariConfig config = new HikariConfig();
        config.setDriverClassName(properties.getProperty("mysql.driver.class"));
        config.setJdbcUrl(properties.getProperty("mysql.url"));
        config.setUsername(properties.getProperty("mysql.user"));
        config.setPassword(properties.getProperty("mysql.password"));
        dataSource = new HikariDataSource(config);

        /** 初始化Redis **/
        redis = new Jedis(properties.getProperty("redis.host"), Integer.valueOf(properties.getProperty("redis.port")));
    }

    public List<Map<String, Object>> executeQuery(String sql) {
        List<Map<String, Object>> result;
        try {
            /** 首先請求Redis **/
            String key = sql.replace(' ', '-');
            String string = redis.get(key);

            // 若是key未命中, 再請求DB
            if (string == null || string.trim().isEmpty()) {
                ResultSet resultSet = dataSource.getConnection().createStatement().executeQuery(sql);

                /** 得到列數/列名 **/
                ResultSetMetaData meta = resultSet.getMetaData();
                int columnCount = meta.getColumnCount();
                List<String> columnName = new ArrayList<>();
                for (int i = 1; i <= columnCount; ++i) {
                    columnName.add(meta.getColumnName(i));
                }

                /** 填充實體 **/
                result = new ArrayList<>();
                while (resultSet.next()) {
                    Map<String, Object> entity = new HashMap<>(columnCount);
                    for (String name : columnName) {
                        entity.put(name, resultSet.getObject(name));
                    }
                    result.add(entity);
                }

                /**寫入Redis**/
                String value = JSON.toJSONString(result);
                redis.set(key, value, "NX", "PX", _1M);
            } else {
                result = JSON.parseObject(string, List.class);
            }
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
        return result;
    }

    public static void main(String[] args) {
        RedisDAO dao = new RedisDAO();
        List<Map<String, Object>> execute = dao.executeQuery("select * from user");
        System.out.println(execute);
    }
}

當服務器內存有限時,若是大量使用緩存並且過時時間較長會致使Redis佔滿內存; 另外一方面爲了防止佔用內存過大而設置過時時間太短, 則有可能致使緩存命中率太低而使系統總體性能降低.所以爲緩存設計一個合理的過時時間是很糾結的, 在Redis中能夠限制可以使用的最大內存,並讓Redis按照必定規則的淘汰再也不須要的key: 修改maxmemory參數,當超過限制會依據maxmemory-policy參數指定的策略來刪除不須要的key:redis

maxmemory-policy 規則說明
volatile-lru 只對設置了過時時間的key使用LRU算法刪除
allkey-lru 使用LRU刪除一個key
volatile-random 只對設置了過時時間的key隨機刪除一個key
allkey-random 隨機刪除一個key
volatile-ttl 刪除過時時間最近的一個key
noevication 不刪除key, 只返回錯誤(默認)

Sort

Redis的SORT命令能夠對List、Set、Sorted-Set類型排序, 而且能夠完成與RDBMS 鏈接查詢 相似的任務:算法

SORT key    [BY pattern] 
            [LIMIT offset count] 
            [GET pattern [GET pattern ...]] 
            [ASC|DESC] 
            [ALPHA] 
            [STORE destination]
參數 描述
ALPHA SORT默認會將全部元素轉換成雙精度浮點數比較,沒法轉換則會提示錯誤,而使用ALPHA參數可實現按字典序比較.
DESC 降序排序(SORT默認升序排序).
LIMIT 指定返回結果範圍.
STORE SORT默認直接返回排序結果, STORE可將排序後結果保存爲List.

注: SORT在對Sorted-Set排序時會忽略元素分數,只針對元素自身值排序.

BY

不少狀況下key實際存儲的是對象ID, 有時單純對ID自身排序意義不大,這就用到了BY參數, 對ID關聯的對象的某個屬性進行排序:

[BY pattern]

pattern能夠是字符串類型key或Hash類型key的某個字段(表示爲鍵名 -> 字段名).若是提供了BY參數, SORT將使用ID值替換參考key中的第一個*並獲取其值,而後根據該值對元素排序.

SORT mi.blog:1:my BY mi.blog:*:data->time DESC
  • 注意:
    • 當pattern不包含*時, SORT將不會執行排序操做;
    • 當ID元素的參考key不存在時,默認設置爲0;
    • 若是幾個ID元素的pattern值相同,則會再比較元素自己值排序.

GET

GET參數不影響排序過程,它的做用是使SORT返回結果再也不是元素自身的值,而是GET參數指定的鍵值:

[GET pattern [GET pattern ...]]

同BY同樣, GET參數也支持String類型和Hash類型, 並使用*做爲佔位符.

SORT mi.blog:1:my BY mi.blog:*:data->time GET mi.blog:*:data->content GET mi.blog:*:data->time

注: GET參數獲取自身值須要使用#: GET #

性能

SORT的時間複雜度爲O(N+M*log(M)):

where N is the number of elements in the list or set to sort, and M the number of returned elements. When the elements are not sorted, complexity is currently O(N) as there is a copy step that will be avoided in next releases.
  • 因此開發過程當中使用SORT須要注意:
    1. 儘量減少待排序key中元素數量(減少N);
    2. 使用LIMIT參數限制結果集大小(減少M);
    3. 若是待排序數據量較大,儘量使用STORE將結果緩存.

Message

1. 消息隊列

消息隊列就是」傳遞消息的隊列」,與消息隊列進行交互的實體有兩類, 一是生產者: 將須要處理的消息放入隊列; 一是消費者: 不斷從消息隊列中讀出消息並處理.

使用消息隊列有以下好處:
鬆耦合: 生產者和消費者無需知道彼此的實現細節, 只需按照協商好的 消息格式讀/寫, 便可實現不一樣進程間通訊,這就使得生產者和消費者能夠由 不一樣的團隊使用 不一樣的開發語言編寫.
易擴展: 消費者能夠有多個,且能夠分佈在不一樣的Server中, 下降單臺Server負載, 橫向擴展業務.

Redis提供了BRPOP/BLPOP命令來實現消息隊列:

命令 描述
BRPOP key [key ...] timeout Remove and get the last element in a list, or block until one is available
BLPOP key [key ...] timeout Remove and get the first element in a list, or block until one is available
BRPOPLPUSH source destination timeout Pop a value from a list, push it to another list and return it; or block until one is available

注: 若Redis同時監聽多個key, 且每一個key均有元素可取,則Redis按照從左到右的順序去挨個讀取key的第一個元素.

2. 消息訂閱

前面的BRPOP/BLPOP實現的消息隊列有一個限制: 若是一個隊列被多個消費者監聽, 生產者發佈一條消息只會被其中一個消費者獲取. 所以Redis還提供了一組命令實現「發佈/訂閱」模式, 一樣可用於進程間通訊:

「發佈/訂閱」模式也包含兩種角色: 發佈者與訂閱者. 訂閱者能夠訂閱一個/多個頻道, 而發佈者可向指定頻道發送消息, 全部訂閱此頻道的訂閱者都會收到此消息.

命令 描述
PUBLISH channel message Post a message to a channel
SUBSCRIBE channel [channel ...] Listen for messages published to the given channels
UNSUBSCRIBE [channel [channel ...]] Stop listening for messages posted to the given channels
PSUBSCRIBE pattern [pattern ...] Listen for messages published to channels matching the given patterns
PUNSUBSCRIBE [pattern [pattern ...]] Stop listening for messages posted to channels matching the given patterns
  • MessagesQueue
/** * @author jifang * @since 16/7/11 下午2:36. */
public class MessageQueue<T> {

    private Jedis redis;

    private String chanel;

    public MessageQueue(Jedis redis, String chanel) {
        this.redis = redis;
        this.chanel = chanel;
    }

    public Long publish(T message) {
        String json = JSON.toJSONString(message);
        return redis.publish(chanel, json);
    }

    public void subscribe(final MessageHandler<T> handler) {
        redis.subscribe(new JedisPubSub() {
            @Override
            public void onMessage(String channel, String message) {
                for (Type type : handler.getClass().getGenericInterfaces()) {
                    if (type instanceof ParameterizedType) {
                        ParameterizedType pType = (ParameterizedType) type;
                        Type handlerClass = pType.getActualTypeArguments()[0];
                        T result = JSONObject.parseObject(message, handlerClass);
                        handler.handle(result);
                    }
                }
            }
        }, chanel);
    }
}
public interface MessageHandler<T> {
    void handle(T object);
}

注: 發送的消息不會持久化,一個訂閱者只能接收到後續發佈的消息,以前發送的消息就接收不到了.

持久化

Redis支持兩種持久化方式: RDB與AOF. RDB: Redis根據指定的規則「定時」將內存數據快照到硬盤; AOF:Redis在每次執行命令後將命令自己記錄下來存放到硬盤.兩種持久化方式可結合使用.

RDB

  • 快照執行過程:
    • Redis使用fork()函數複製一份當前進程副本;
    • 父進程繼續接收並處理客戶端請求, 而子進程將全部內存數據寫入磁盤臨時文件;
    • 當子進程將全部數據寫完會用該臨時文件替換舊的RDB文件, 至此一次快照完成(能夠看到自始至終RDB文件都是完整的).

Redis會在如下幾種狀況下對數據進行快照:

  • 根據配置規則
    配置由兩個參數構成: 時間窗口M和改動key個數N; 當時間M內被改動的key的個數大於N時, 即符合自動快照條件:
save 900 1
save 300 10
save 60 10000
  • 用戶執行SAVE/BGSAVE/FLUSHALL命令:
    除了讓Redis自動快照, 當進行服務重啓/手動遷移以及備份時也須要咱們手動執行快照.
命令 描述
SAVE SAVE命令會使Redis同步地執行快照操做(過程當中會阻塞全部來自客戶端的請求, 所以儘可能避免線上使用)
BGSAVE 在後臺異步執行快照操做,Redis還可繼續響應請求
FLUSHALL FLUSHALL會清空全部數據,不管是否觸發了自動快照條件(只要有配置了),Redis都會執行一次快照
LASTSAVE 獲取最近一次成功執行快照時間
  • 執行復制
    當設置了主從模式, Redis會在複製初始化時執行快照,即便沒有配置自動快照條件.

經過RDB方式實現持久化, Redis在啓動後會讀取RDB快照文件, 將數據從硬盤導入內存, 但若是在持久化過程當中Redis異常退出, 就會丟失最後一次快照之後更改的全部數據.

RDB其餘配置參數

dir ./                  # 設置工做目錄,RDB文件(以及後面的AOF文件)會寫入該目錄
dbfilename dump.rdb     # 設置RDB文件名
rdbcompression yes      # 導出RDB是否壓縮
rdbchecksum yes         # 存儲和加載RDB校驗完整性
stop-writes-on-bgsave-error yes     # 後臺備份進程出錯時,主進程中止寫入.

AOF

AOF將Redis執行的每一條命令追加到硬盤文件中.而後在啓動Redis時逐條執行AOF文件中的命令將數據載入內存.

Redis默認沒有開啓AOF, 須要以以下參數啓用:

appendonly yes
no-appendfsync-on-rewrite  yes: # 正在導出RDB快照的過程當中,中止同步AOF.

AOF重寫

開啓AOF後, Redis會將每一條有可能更改數據的命令寫入AOF文件,這樣就致使AOF文件愈來愈大,即便有可能內存中實際存儲的數據並沒多少. 所以Redis每當達到必定條件就自動重寫AOF文件,這個條件能夠在配置文件中設置:

auto-aof-rewrite-percentage 100 # 比起上次重寫時的大小,AOF增加率100%時重寫
auto-aof-rewrite-min-size 64mb  # AOF大小超過64M時重寫

此外, 咱們還可使用BGREWRITEAOF命令手動執行AOF重寫.

硬盤數據同步

執行AOF持久化時, 因爲操做系統緩存機制, 數據並無真正寫入磁盤,而是進入了磁盤緩存, 默認狀況下系統每30S執行一次同步操做, 將緩存內容真正寫入磁盤, 若是在這30S的系統異常退出則會致使磁盤緩存數據丟失, 若是應用沒法忍受這樣的損失, 可經過appendfsync參數設置同步機制:

# appendfsync always # 每次執行寫入都執行同步
appendfsync everyse     # 每秒執行一次同步操做
# appendfsync no # 不主動進行同步, 而是徹底由操做系統執行.

集羣

1. Replication

複製(replication)中,Redis的角色能夠分爲兩類, Master:能夠執行讀/寫操做,當寫操做致使數據修改時會自動將數據同步給Slave; Slave:通常是隻讀的,並接受Master同步過來的數據(Slave自身也能夠做爲Master存在, 如圖):

  • replication複製時序
    • Slave啓動後向Master發送SYNC命令;Master收到後在後臺保存RDB快照, 並將快照期間接收到的全部命令緩存.
    • 快照執行完, Master將快照文件與全部緩存的命令發送給Slave;
    • Slave接收並載入快照, 而後執行全部收到的緩存命令,這一過程稱爲複製初始化.
    • 複製初始化完成後,Master每接收到寫命令就同步給Slave,從而保證主從數據一致.
  • 經過Redis的複製功能能夠實現如下應用:
    • 讀寫分離:
      經過複製可實現讀寫分離, 以提升服務器的負載能力, 能夠經過複製創建多個Slave節點, Master只進行寫操做, 而由Slave負責讀操做, 這種一主多從的結構很適合讀多寫少的場景.
    • Slave持久化
      持久化是一個相對耗時的操做, 爲了提升性能, 能夠經過複製功能創建一個/多個Slave, 並在Salve中啓用持久化, Master禁用持久化. 當Master崩潰後:
      1. 在Slave使用SLAVEOF NO ONE命令將Slave提高成Master繼續服務;
      2. 啓用以前崩潰的Master, 而後使用SLAVEOF將其設置爲新Master的Slave, 便可將數據同步回來.

注意: 當開啓複製且Master關閉持久化時, Master崩潰後必定不能直接重啓Master, 這是由於當Master重啓後, 由於沒有開啓持久化, 因此Redis內的全部數據都會被清空, 這時Salve從Master接受數據, 全部的Slave也會被清空, 致使Slave持久化失去意義.

關於Redis複製的詳細介紹以及配置方式可參考博客:Redis研究 -主從複製.

2. Sentinel

當Master遭遇異常中斷服務後, 須要手動選擇一個Slave升級爲Master, 以使系統可以繼續提供服務. 然而整個過程相對麻煩且須要人工介入, 難以實現自動化. 爲此Redis提供了哨兵Sentinel.

Sentinel哨兵是Redis高可用性解決方案之一: 由一個/多個Sentinel實例組成的Sentinel系統能夠監視任意多個Master以及下屬Slave, 並在監控到Master進入下線狀態時, 自動將其某個Slave提高爲新的Master, 而後由新的Master代替已下線的Master繼續處理命令請求.

  • 如圖: 若此時Master:server1進入下線狀態, 那麼Slave: server2,server3,server4對Master的複製將被迫停止,而且Sentinel系統也會察覺到server1已下線, 當下線時長超過用戶設定的下線時長時, Sentinel系統就會對server1執行故障轉移操做:
    此處輸入圖片的描述
    • Sentinel會挑選server1下屬的其中一臺Slave, 將其提高爲新Master;
    • 而後Sentinel向server1下屬的全部Slave發送新的複製指令,讓他們成爲新Master的Salve, 當全部Salve都開始複製新Master時, 故障轉移操做完成.
    • 另外, Sentinel還會繼續監視已下線的server1, 並在他從新上線時, 將其設置爲新Master的Slave.

關於Redis哨兵的詳細介紹以及配置方式可參考博客:Redis Sentinel(哨兵)：集羣解決方案.

3. Cluster

Cluster是Redis提供的另外一高可用性解決方案:Redis集羣經過分片(sharding)來進行數據共享, 並提供複製與故障轉移功能.

一個 Redis 集羣一般由多個節點組成, 最初每一個節點都是相互獨立的,要組建一個真正可工做的集羣, 必須將各個獨立的節點鏈接起來.鏈接各個節點的工做可使用CLUSTER MEET命令完成: 

CLUSTER MEET <ip> <port>

向一個節點發送CLUSTER MEET命令,可使其與ip+port所指定的節點進行握手,當握手成功時, 就會將目標節點添加到當前節點所在的集羣中.

  • 案例
    假設如今有三個獨立的節點 127.0.0.1:7000 、 127.0.0.1:7001 、 127.0.0.1:7002:
    此處輸入圖片的描述
    • 經過向節點 7000 發送CLUSTER MEET 127.0.0.1 7001命令,可將節點7001添加到節點7000所在的集羣中:
      此處輸入圖片的描述
    • 繼續向節點7000發送CLUSTER MEET 127.0.0.1 7002命令,一樣也可將節點7002也拉進來:
      此處輸入圖片的描述
    • 至此, 握手成功的三個節點處於同一個集羣:
      此處輸入圖片的描述

關於Redis-Cluster的詳細介紹以及更多配置方式可參考博客:redis-cluster研究和使用.

管理

1. 數據庫密碼

經過在配置文件中使用requirepass參數可爲Redis設置密碼:

requirepass œ∑´®†¥¨ˆøπ

這樣客戶端每次鏈接都須要發送密碼,不然Redis拒絕執行客戶端命令:

AUTH œ∑´®†¥¨ˆøπ

2. 重命名

Redis支持在配置文件中將命令重命名, 以保證只有本身的應用可使用該命令:

rename-command FLUSHALL qwertyuiop

若是但願禁用某個命令,可將命令重命名爲空字符串.

3. 工具

  • SLOWLOG
    當一條命令執行超過期間限制時,Redis會將其執行時間等信息加入耗時統計日誌, 超時時間等可經過如下配置實現:
slowlog-log-slower-than 10000   # 超時限制(單位微秒)
slowlog-max-len 128             # 記錄條數限制

  • MONITOR : 監控Redis執行的全部命令

    注意: MONITOR命令很是影響Redis性能, 一個客戶端使用MONITOR會下降Redis將近一半的負載能力. Instagram團隊開發了一個基於MONITOR命令的Redis查詢分析工具redis-faina, 可根據MONITOR的監控結果分析出最經常使用的命令/訪問最頻繁的key等信息, 詳細可參考博客:關於 Redis 的性能分析工具 Redis Faina.

  • 其餘經常使用管理工具

TIME        # 系統時間戳與微秒數
DBSIZE      # 當前數據庫的key數量
INFO        # Redis服務器信息
CONFIG GET  # 獲取配置信息
CONFIG SET  # 設置配置信息
CONFIG REWRITE  # 把值寫到配置文件
CONFIG RESTART  # 更新INFO命令信息
CLIENT LIST # 客戶端列表
CLIENT KILL # 關閉某個客戶端
CLIENT SETNAME  # 爲客戶端設置名字
CLIENT GETNAME  # 獲取客戶端名字
DEBUG OBJECT key    # 調試選項,查看一個key的信息
DEBUG SEGFAULT      # 模擬段錯誤,使服務器崩潰
OBJECT (refcount|encoding|idletime) key
參考&拓展
高可用、開源的Redis緩存集羣方案
Twemproxy——針對MemCached與Redis的代理
Redis 3.0正式版發佈，正式支持Redis集羣
Redis應用實踐：小紅書海量Redis存儲之道
Redis內存優化實踐
視頻: Raft 教程
使用Redis做爲時間序列數據庫：緣由及方法
Redis複製與可擴展集羣搭建
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程