Redis使用場景

1、字串使用場景

a) 快取功能

典型使用場景：redis作為快取層，mysql作為儲存層，絕大部分請求的資料都是從redis中獲取，由於redis具有支撐高併發的特性，所以快取通常能起到加速讀寫和降低後端壓力的作用。

b) 計數

c) 共享session

典型應用場景：使用者登陸資訊，redis將使用者的session進行集中管理，每次使用者更新或查詢登陸資訊都直接從redis中集中獲取。

d) 限速

典型應用場景：驗證碼介面訪問頻率限制，使用者登陸時需要讓使用者輸入手機驗證碼，從而確定是否是使用者本人，但是為了簡訊介面不被頻繁訪問，會限制使用者每分鐘獲取驗證碼的頻率，例如一分鐘不能超過5次。

2、雜湊使用場景

a) 快取使用者資訊

相比於使用字串序列化快取使用者資訊，雜湊型別變得更加直觀，並且在更新操作上會更加便捷。可以將每個使用者的id定義為鍵字尾，多對field-value對應每個使用者的屬性。

雜湊型別和關係型資料庫不同之處：

雜湊型別是稀疏的，而關係型資料庫是完全結構化的，例如雜湊型別每個鍵可以有不同的field，而關係型資料庫一旦新增新的列，所有行都要為其設定值(即使為null)。

關係型資料庫可以做複雜的關係查詢，而redis去模擬關係型複雜查詢開發困難，維護成本高。

三種快取使用者資訊優缺點比較：

原生字串型別：每個屬性乙個鍵

優點：簡單直觀，每個屬性都支援更新操作。

缺點：占用過多的鍵，記憶體佔用量較大，同時使用者資訊內聚性比較差，所以此種方案一般不會在生產環境使用。

序列化字串型別：將使用者資訊序列化後用乙個鍵儲存。

優點：簡化程式設計，如果合理的使用序列化可以提高記憶體的使用效率。

缺點：序列化和反序列化有一定的開銷，同時每次更新屬性都需要把全部資料取出進行反序列化，更新後再序列化到redis中。

雜湊型別：每個使用者屬性使用一對field-value，但是只用乙個鍵儲存。

優點：簡單直觀，如果使用合理可以減少記憶體空間的使用。

3、列表使用場景

a) 訊息佇列

redis的lpush+brpop命令組合即可實現阻塞佇列，生產者客戶端使用lrpush從列表左側插入元素，多個消費者客戶端使用brpop命令阻塞式的"搶"列表尾部的元素，多個客戶端保證了消費的負載均衡和高可用性。

b) 文章列表

每個使用者有屬於自己的文章列表，現在需要分頁展示文章列表。此時可以考慮使用列表，因為列表不但是有序的，同時支援按照索引範圍獲取元素。

c) 開發提示

lpush + lpop = stack(棧)

lpush + rpop = queue(佇列)

lpush + brpop = message queue(訊息佇列)

4、集合

a) 標籤(tag)

5、有序集合

a) 排行榜系統

原文：

redis使用場景

最近要去面試php程式設計師，去各家招聘 看看，都要有redis方面的知識儲備。這裡寫一篇部落格，就當是對最近學習redis的一次回顧。簡單一句話介紹redis 基於記憶體的高效的key value資料庫，把資料載入到記憶體中進行處理，定期把資料儲存到硬碟進行儲存，單執行緒。redis五大資料型別 ...

redis使用場景

redis開創了一種新的資料儲存思路，使用redis，我們不用在面對功能單調的資料庫時，把精力放在寫龐大的sql上了，而是利用redis靈活多變的資料結構和資料操作來實現。redis常用資料型別 redis最為常用的資料型別主要有以下五種 下面我們先來逐一的分析下這五種資料型別的使用和內部實現方式 ...

Redis使用場景

1 字串使用場景 a 快取功能 典型使用場景 redis作為快取層，mysql作為儲存層，絕大部分請求的資料都是從redis中獲取，由於redis具有支撐高併發的特性，所以快取通常能起到加速讀寫和降低後端壓力的作用。b 計數 c 共享session 典型應用場景 使用者登陸資訊，redis將使用者的...