linux新增、更換源
文章目錄
2020年面試必備的Java後端進階面試題總結了一份複習指南在Github上,內容詳細,圖文並茂,有需要學習的朋友可以Star一下!
GitHub地址:
接下來看看每個資料結構常用的指令有哪些,我們用一張表比較清晰的展示:
場景一:商品庫存數
從業務上,商品庫存資料是熱點資料,交易行為會直接影響庫存。而 Redis 自身 String 型別提供了:
- set goods_id 10; 設定 id 為 good_id 的商品的庫存初始值為 10;
- decr goods_id; 當商品被購買時候,庫存資料減 1。
依次類推的場景:商品的瀏覽次數,問題或者回復的點贊次數等。這種計數的場景都可以考慮利用 Redis 來實現。
場景二:時效資訊儲存
Redis 的資料儲存具有自動失效能力。也就是儲存的 key-value 可以設定過期時間:set(key, value, expireTime)。
比如,使用者登入某個 App 需要獲取登入驗證碼, 驗證碼在 30 秒內有效。那麼我們就可以使用 String 型別儲存驗證碼,同時設定 30 秒的失效時間。
Redis 在儲存物件(例如:使用者資訊)的時候需要對物件進行序列化轉換然後儲存。
還有一種形式,就是將物件資料轉換為 JSON 結構資料,然後儲存 JSON 的字串到 Redis。
對於一些物件型別,還有一種比較方便的型別,那就是按照 Redis 的 Hash 型別進行儲存。
例如,我們儲存一些網站使用者的基本資訊, 我們可以使用:
這樣就儲存了一個使用者基本資訊,儲存資訊有:{name : 小明, phone : “123456”,sex : “男”}
當然這種類似場景還非常多, 比如儲存訂單的資料,產品的資料,商家基本資訊等。以淘寶購物車為主
1.原生:
- set user: 1:name james;
- set user:1:age 23;
- set user:1:sex boy;
優點: 簡單直觀,每個鍵對應一個值
缺點: 鍵數過多,佔用記憶體多,使用者資訊過於分散,不用於生產環境
2.將物件序列化存入
redis set user:1 serial ize (userInfo);
優點: 程式設計簡單,若使用序列化合理記憶體使用率高
缺點: 序列化與反序列化有一定開銷,更新屬性時需要把userInfo全取出來進行反序列化,更新後再序列化到redis
3.hash儲存:
hmset user:1 name james age 23 sex boy
優點: 簡單直觀,使用合理可減少記憶體空間消耗
缺點: 要控制ziplist 與hashtable兩種編碼轉換,Mhashtable會消耗更多記憶體。
list 是按照插入順序排序的字串連結串列。可以在頭部和尾部插入新的元素(雙向連結串列實現,兩端新增元素的時間複雜度為 O(1)) 。
場景一:訊息佇列實現
目前有很多專業的訊息佇列元件 Kafka、RabbitMQ 等。 我們在這裡僅僅是使用 list 的特徵來實現訊息佇列的要求。在實際技術選型的過程中,大家可以慎重思考。
list 儲存就是一個佇列的儲存形式:
- lpush key value; 在 key 對應 list 的頭部新增字串元素;
- rpop key;移除列表的最後一個元素,返回值為移除的元素。
場景二:最新上架商品
在交易網站首頁經常會有新上架產品推薦的模組, 這個模組是儲存了最新上架前 100 名。
這時候使用 Redis 的 list 資料結構,來進行 TOP 100 新上架產品的儲存。
Redis ltrim 指令對一個列表進行修剪(trim),這樣 list 就會只包含指定範圍的指定元素。
start 和 stop 都是由 0 開始計數的,這裡的 0 是列表裡的第一個元素(表頭),1 是第二個元素。
set 也是儲存了一個集合列表功能。和 list 不同,set 具備去重功能。當需要儲存一個列表資訊,同時要求列表內的元素不能有重複,這時候使用 set 比較合適。與此同時,set 還提供的交集、並集、差集。
例如,在交易網站,我們會儲存使用者感興趣的商品資訊,在進行相似使用者分析的時候, 可以通過計算兩個不同使用者之間感興趣商品的數量來提供一些依據。
獲取到兩個使用者相似的產品, 然後確定相似產品的類目就可以進行使用者分析。
類似的應用場景還有, 社交場景下共同關注好友, 相似興趣 tag 等場景的支援。
常用於排行榜,如視訊網站需要對使用者上傳視訊做排行榜,或點贊數與集合有聯絡,不能有重複的成員