首先redis它的設計是用來做快取的，但是由於它自身的某種特性（下面會詳細討論）使得它可以用來做訊息佇列。它有幾個阻塞式的api可以使用，正是這些阻塞式的api讓他有做訊息佇列的能力。
試想一下在」資料庫解決所有問題「的思路下，不使用訊息佇列也是可以完成你的需求的。我們把任務全部存放在資料庫然後通過不斷的輪詢方式來取任務處理。這種做法雖然可以完成你的任務但是做法很粗劣。但是如果你的資料庫介面提供乙個阻塞的方法那麼就可以避免輪詢操作了，你的資料庫也可以用來做訊息佇列，只不過目前的資料庫還沒有這樣的介面。
另外做訊息佇列的其他特性例如fifo也很容易實現，只需要乙個list物件從頭取資料，從尾部塞資料即可實現。
redis能做訊息佇列得益於
他list物件blpop brpop介面以及pub/sub(發布/訂閱)的某些介面。
他們都是阻塞版的，所以可以用來做訊息佇列。
儘管redis對一些資料結構採用了壓縮法儲存，但是用記憶體量還是過高。
唯一計數是**系統中十分常見的乙個功能特性，例如**需要統計每天訪問的人數 unique visitor （也就是 uv）。計數問題很常見，但解決起來可能十分複雜：一是需要計數的量可能很大，比如大型的站點每天有數百萬的人訪問，資料量相當大；二是通常還希望擴充套件計數的維度，比如除了需要每天的 uv，還想知道每週或每月的 uv，這樣導致計算十分複雜。
在關聯式資料庫儲存的系統裡，實現唯一計數的方法就是 select count(distinct )，它十分簡單，但是如果資料量很大，這個語句執行是很慢的。用關聯式資料庫另外乙個問題是插入資料效能也不高。
redis 解決這類計數問題得心應手，相比關聯式資料庫速度更快，消耗資源更少，甚至提供了 3 種不同的方法。
redis 的 set 用於儲存唯一的資料集合，通過它可以快速判斷某乙個元素是否存在於集合中，也可以快速計算某乙個集合的元素個數，另外和可以合併集合到乙個新的集合中。
sismember key member # 判斷 member 是否存在
sadd key member # 往集合中加入 member
scard key # 獲取集合元素個數
基於 set 的方法簡單有效，計數精確，適用面廣，易於理解，它的缺點是消耗資源比較大（當然比起關聯式資料庫是少很多的），如果元素個數很大（比如上億的計數），消耗記憶體很恐怖。
redis 的 bit 可以用於實現比 set 記憶體高度壓縮的計數，它通過乙個 bit 1 或 0 來儲存某個元素是否存在資訊。例如**唯一訪客計數，可以把 user_id 作為 bit 的偏移量 offset，設定為 1 表示有訪問，使用1mb的空間就可以存放800 多萬（1024*1024*8=8388608）使用者的一天訪問計數情況。
setbit key offset value # 設定位資訊
getbit key offset # 獲取位資訊
bitcount key [start end] # 計數
bitop operation destkey key [key ...] # 位圖合併
基於 bit 的方法比起 set 空間消耗小得多，但是它要求元素能否簡單對映為位偏移，適用面窄了不少，另外它消耗的空間取決於最大偏移量，和計數值無關，如果最大偏移量很大，消耗記憶體也相當可觀。
實現超大資料量精確的唯一計數都是比較困難的，但是如果只是近似的話，計算科學裡有很多高效的演算法，其中 hyperloglog counting 就是其中非常著名的演算法，它可以僅僅使用 12 k左右的記憶體，實現上億的唯一計數，而且誤差控制在百分之一左右。
pfadd key element [element ...] # 加入元素
pfcount key [key ...] # 計數
redis直接將資料儲存到記憶體中，可通過兩種方式持久化：定時快照和基於語句的追加。
定時快照的方法是指每隔一段時間將整個資料庫的資料寫到磁碟上，很明顯，每次均是寫全部資料，代價非常高；
而基於語句的追加方法值追蹤變化的資料，這類似於mysql的binlog方法，但追加log可能過大，同時所有操作均要重新執行一遍，回寫速度慢。
儘管redis對一些資料結構採用了壓縮法儲存，但是用記憶體量還是過高。
快取（資料查詢、短連線、新聞內容、商品內容等等）。（最多使用）
2）分布式集群架構中的session分離。
4）任務佇列。（秒殺、搶購、12306等等）（先進先出）
5）應用排行榜。（可以給每個元素設定乙個打分，這樣就可以排序）
6）**訪問統計。
7）資料過期處理（可以精確到毫秒）。
1）使用lpush latest.comments命令，向list集合中插入資料
2）插入完成後再用 ltrim latest.comments 0 5000 命令使其永遠只儲存最近5000個id
這樣就可以通過乙個比較短的url來訪問相同的位址。它是將連線位址通過乙個演算法進行簡化變短。最後面這實際就是乙個key，在它的資料庫中這個key就對應乙個url。當訪問這個位址時dwz.cn中的服務對這個後面的id進行解析，從資料庫查詢出真正的位址。然後重定向訪問真正的鏈結。
在windows平台下預設的配置檔案是：redis.windows.conf，這裡面配置了非常多的資訊，一般配置保持預設，在一些特定的場景下可以自定義配置，常用到的配置項如下：
port 服務埠
bind 繫結ip其他ip不能訪問（多個ip空格隔開）
databases 資料庫數量，預設16個
daemonize設定為守護程序（linux平台）
maxmemory最大的記憶體大小（1mb、1gb、1m、1g）
maxmemory-policy達到記憶體限制後的處理策略（後面詳細說明）
注意：修改後配置檔案需要重啟redis服務才能生效。
volatile-lru：使用lru演算法刪除乙個鍵（只對設定了生存時間的鍵）
allkeys-lru：使用lru演算法刪除乙個鍵
volatile-random：隨機刪除乙個鍵（只對設定了生存時間的鍵）
allkeys-random：隨機刪除乙個鍵
volatile-ttl：刪除生存時間最近的乙個鍵
noeviction：不刪除鍵，只返回錯誤
lur（least recently used）演算法：最近最少使用
電商中的庫存管理實現 mysql與redis
庫存是電商系統的核心環節，如何做到不少賣，不超賣是庫存關心的核心業務問題。業務量大時帶來的問題是如何更快速的處理庫存計算。此處以最簡模式來討論庫存設計。以下內容只做分析，不能直接套用，歡迎各位同道前來交流指正 庫存模型 sku,num。sku是標示商品的唯一編號，num是商品的數量。訂單處理時需扣減...
mysql電商實戰筆記 電商平台專案實戰補充內容
一 mysql操作日誌 general log 能記錄mysql所有的操作日誌 包括增刪改查 不過他會耗費資料庫5 10 的效能,所以一般沒特別需要時不開啟此功能,一般在查詢問題時才開啟,完成後及時關閉 1 客戶端連線mysql 2 查詢日誌是否開啟 show variables like gene...
鹹魚筆記 認識電商
認識電商 b2b 企業對企業 b2b business to business 是指進行電子商務交易的供需雙方都是商家 或企業，公司 她 他 們使用了網際網路的技術或各種商務網路平台，完成商務交易的過程。電子商務是現代 b2b marketing 的一種具體主要的表現形式。例 阿里巴巴 慧聰網 c2...