redis使用場景(redis七種數據類型)

這篇文章給大家聊聊關于redis使用場景，以及redis七種數據類型對應的知識點，希望對各位有所幫助，不要忘了收藏本站哦。

redis布隆過濾器使用方法

布隆過濾器是一種類似set的數據結構。

Redis布隆過濾器的基本使用

在Redis中，布隆過濾器有兩個基本命令，分別是：

bf.add：添加元素到布隆過濾器中，類似于集合的sadd命令，不過bf.add命令只能一次添加一個元素，如果想一次添加多個元素，可以使用bf.madd命令。

bf.exists：判斷某個元素是否在過濾器中，類似于集合的sismember命令，不過bf.exists命令只能一次查詢一個元素，如果想一次查詢多個元素，可以使用bf.mexists命令。

布隆過濾器的高級使用

上面的例子中使用的布隆過濾器只是默認參數的布隆過濾器，它在我們第一次使用bf.add命令時自動創建的。Redis還提供了自定義參數的布隆過濾器，想要盡量減少布隆過濾器的誤判，就要設置合理的參數。在使用bf.add命令添加元素之前，使用bf.reserve命令創建一個自定義的布隆過濾器。bf.reserve命令有三個參數，分別是：

key：鍵

error_rate：期望錯誤率，期望錯誤率越低，需要的空間就越大。

capacity：初始容量，當實際元素的數量超過這個初始化容量時，誤判率上升。

如果對應的key已經存在時，在執行bf.reserve命令就會報錯。如果不使用bf.reserve命令創建，而是使用Redis自動創建的布隆過濾器，默認的error_rate是0.01，capacity是100。

布隆過濾器的error_rate越小，需要的存儲空間就越大，對于不需要過于精確的場景，error_rate設置稍大一點也可以。布隆過濾器的capacity設置的過大，會浪費存儲空間，設置的過小，就會影響準確率，所以在使用之前一定要盡可能地精確估計好元素數量，還需要加上一定的冗余空間以避免實際元素可能會意外高出設置值很多。總之，error_rate和capacity都需要設置一個合適的數值。

redis用的多嗎

用的多

因為，Redis是一個很好的Cache工具。大型網站應用，熱點數據量往往巨大，幾十G上百G是很正常的。

由于內存大小的限制，使用一臺Redis實例顯然無法滿足需求，這時就需要使用多臺Redis（集群）作為緩存數據庫。才能在用戶請求時快速的進行響應。

所以，通常系統需要滿足，高可用，高并發，響應速度，安全，有要求時，就需要進行集群。

Java工程師是如何使用Redis的

在分布式和微服務等架構遍地開花的實踐中，Redis始終作為分布式緩存的首選，可謂經久不衰、獨樹一幟。Redis基于內存運行并支持持久化的NoSQL數據庫，是當前最熱門的NoSql數據庫之一，也被人們稱為數據結構服務器。

而為何要使用Redis呢？Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。Redis支持master-slave(主-從)模式應用。Redis支持數據持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。Redis單個value的最大限制是1GB，memcached只能保存1MB的數據。基于種種原因，Redis成為我們緩存架構的首選，而我在開啟碼農生涯時，就接觸到Redis，只是當時的使用比較簡單。

最開始時，因互聯網化團隊初建，各種所需要的中間件都需要自己搭建，包含Redis，而我們使用Docker搭建Redis集群，采用主從的Redis架構，再使用Sentinel（哨兵）模式來監控該Redis集群，使用也是通過Sentinel來使用。通過Spring或SpringBoot的哨兵連接方式連接Redis，注冊成Bean，然后使用序列化的Key-Value結構來緩存所需要的數據。而因領導的風格原因，我們也僅僅被允許采用Key-Value的基礎功能來進行Redis操作。至于其中的原因，也沒有深究。

而隨后，跳槽到現公司，其將Redis作為基礎服務進行封裝，而業務團隊僅通過加密串即可進行直接連接，其背后的可高用、主從分片、災備等均由基礎架構團隊負責。基礎架構團隊提供的操作方式，就不僅僅限于使用Key-Value的get、set、delete等方法，而幾乎完全提供了Redis的所有命令，包含inc、sadd等計數、集合操作。當然，有了這些，對程序員的要求更高，要在合適的場景中選擇恰當的命令進行操作，也不是一件容易的事。

或許，使用Redis有這樣那樣的原因，但在我看來，最重要的就兩條：其一，它能提高用戶的訪問速度，大量的降低系統響應的TP99；其二，它是主流，大家都在用，而且經過了時間的檢驗，抗住了一個又一個電商大促的業務場景。

作者：夕陽雨晴，歡迎關注我的頭條號。偶爾美文，主流Java，為你講述不一樣的碼農生活。

什么時間redis

●不需要實時更新但是又極其消耗數據庫的數據。比如網站上商品銷售排行榜，這種數據一天統計一次就可以了，用戶不會關注其是否是實時的。

●需要實時更新，但是更新頻率不高的數據。比如一個用戶的訂單列表，他肯定希望能夠實時看到自己下的訂單，但是大部分用戶不會頻繁下單。

●在某個時刻訪問量極大而且更新也很頻繁的數據。這種數據有一個很典型的例子就是秒殺，在秒殺那一刻，可能有N倍于平時的流量進來，系統壓力會很大。但是這種數據使用的緩存不能和普通緩存一樣，這種緩存必須保證不丟失，否則會有大問題。

一般地，Redis可以用來作為MySQL的緩存層。為什么MySQL最好有緩存層呢？想象一下這樣的場景：在一個多人在線的游戲里，排行榜、好友關系、隊列等直接關系數據的情景下，如果直接和MySQL正面交手，大量的數據請求可能會讓MySQL疲憊不堪，甚至過量的請求將會擊穿數據庫，導致整個數據服務中斷，數據庫性能的瓶頸將掣肘業務的開發；那么如果通過Redis來做數據緩存，將大大減小查詢數據的壓力。在這種架子里，當我們在業務層有數據查詢需求時，先到Redis緩存中查詢，如果查不到，再到MySQL數據庫中查詢，同時將查到的數據更新到Redis里；當我們在業務層有修改插入數據需求時，直接向MySQL發起請求，同時更新Redis緩存。