Redis高階使用消息隊列分布式鎖排行榜等(高階用法)

更新時間：2024年03月21日 15:37:40 作者：奮力向前123

在大多數(shù)傳統(tǒng)的web系統(tǒng)中,使用Redis一般都是作為緩存使用,在大數(shù)據(jù)查詢時作為緩解性能的一種解決方案,這篇文章主要介紹了Redis高階使用消息隊列分布式鎖排行榜等,需要的朋友可以參考下

一、前言

在大多數(shù)傳統(tǒng)的web系統(tǒng)中，使用Redis一般都是作為緩存使用，在大數(shù)據(jù)查詢時作為緩解性能的一種解決方案。博主的的系統(tǒng)中使用Redis也主要使用到緩存的作用，還有做了注冊中心，分布式事務。其他的強大的功能，沒有運用上。下面看一張圖，看看Redis高階還能用到哪些常見的場景。

二、Redis高階用法

1.消息隊列：Redis的列表數(shù)據(jù)結(jié)構(gòu)非常適合作為簡單的消息隊列。消息發(fā)布者可以使用LPUSH命令向隊列中添加消息，而多個消息訂閱者則可以通過阻塞線程使用BRPOP命令從隊列中取出消息。需要注意的是，Redis官方并不提供可靠消費/發(fā)布的機制，因此需要自行實現(xiàn)故障轉(zhuǎn)移、隊列持久化、隊列監(jiān)控和流量控制等功能。
2.Lua腳本：Redis支持使用Lua腳本在服務器端執(zhí)行一系列命令。這有助于減少客戶端與服務器之間的網(wǎng)絡開銷，并且可以實現(xiàn)復雜的原子操作。
3.事務：Redis支持事務，可以將一系列命令作為一個原子操作來執(zhí)行。這通過MULTI、EXEC、DISCARD和WATCH等命令來實現(xiàn)，確保在事務執(zhí)行期間，中間步驟不會被其他客戶端打斷。
4.分布式鎖：Redis可以利用SET命令的NX（不覆蓋）參數(shù)來實現(xiàn)分布式鎖。獲取鎖的客戶端可以執(zhí)行臨界區(qū)的代碼，而其他客戶端則需要等待鎖的釋放。

public String lock(String key, int timeOutSecond) {
    for (; ; ) {
        String stamp = String.valueOf(System.nanoTime());
        boolean exist = redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
        if (exist) {
            return stamp;
        }
    }
}
public void unlock(String key, String stamp) {
    redisTemplate.execute(script, Arrays.asList(key), stamp);
}

排行榜：Redis的有序集合數(shù)據(jù)結(jié)構(gòu)（zset）非常適合用來實現(xiàn)排行榜功能。例如，可以通過zadd命令添加分數(shù)和成員，然后使用zrevrange命令獲取排名最高的成員。
HyperLogLog：這是Redis用于基數(shù)統(tǒng)計的算法。當輸入元素的數(shù)量或體積非常大時，HyperLogLog所需的計算空間總是固定的且很小。通過pfadd命令添加元素，然后使用pfcount命令獲取基數(shù)統(tǒng)計結(jié)果。
過期鍵管理：Redis可以為鍵設置過期時間，過期后鍵會自動被刪除。這對于緩存系統(tǒng)特別有用，可以避免長時間占用內(nèi)存。

redis的數(shù)據(jù)結(jié)構(gòu)豐富，一般不會在功能性上造成困擾。但隨著請求量的增加，SLA要求的提高，我們勢必會對Redis進行一些改造和定制性開發(fā)。

高可用挑戰(zhàn)

redis提供了主從、哨兵、cluster等三種集群模式，其中cluster模式為目前大多數(shù)公司所采用的方式。

但是，redis的cluster模式，有不少的硬傷。redis cluster采用虛擬槽的概念，把所有的key映射到 0～16383個整數(shù)槽內(nèi)，屬于無中心化的架構(gòu)。但它的維護成本較高，slave也不能夠參與讀取操作。

它的主要問題，在于一些批量操作的限制。由于key被hash到多臺機器上，所以mget、hmset、sunion等操作就非常的不友好，經(jīng)常發(fā)生性能問題。

redis的主從模式是最簡單的模式，但無法做到自動failover，通常在主從切換后，還需要修改業(yè)務代碼，這是不能忍受的。即使加上haproxy這樣的負載均衡組件，復雜性也是非常高的。

哨兵模式在主從數(shù)量比較多的時候，能夠顯著的體現(xiàn)它的價值。一個哨兵集群，能夠監(jiān)控成百上千個集群，但是哨兵集群本身的維護是比較困難的。幸運的是，redis的文本協(xié)議非常簡單，在netty中，甚至直接提供了redis的codec。自研一套哨兵系統(tǒng)，加強它的功能，是可行的。

冷熱數(shù)據(jù)分離

redis的特點是，不管什么數(shù)據(jù)，都一股腦地搞到內(nèi)存里做計算，這對于有時間序列概念，有冷熱數(shù)據(jù)之分的業(yè)務，造成了非常大的成本考驗。為什么大多數(shù)開發(fā)者喜歡把數(shù)據(jù)存放在MySQL中，而不是Redis中？除了事務性要求以外，很大原因是歷史數(shù)據(jù)的問題。

通常，這種冷熱數(shù)據(jù)的切換，是由中間件完成的。我們上面也談到了，Redis是一個文本協(xié)議，非常簡單。做一個中間件，或者做一個協(xié)議兼容的Redis模擬存儲，是比較容易的。

比如我們Redis中，只保留最近一年的活躍用戶。一個好幾年不活躍的用戶，突然間訪問了系統(tǒng)，這時候我們獲取數(shù)據(jù)的時候，就需要中間件進行轉(zhuǎn)換，從容量更大，速度更慢的存儲中查找。

這個時候，Redis的作用，更像是一個熱庫，更像是一個傳統(tǒng)cache層做的事情，發(fā)生在業(yè)務已經(jīng)上規(guī)模的時候。但是注意，直到此時，我們的業(yè)務層代碼，一直都是操作的redis的api。它們使用這眾多的函數(shù)指令，并不關(guān)心數(shù)據(jù)到底是真正存儲在redis中，還是在ssdb中。