Redis 典型應用

1、redis實現投票： 使用hash儲存一篇文章的資訊（儲存實體物件資訊） 使用incr產生自增id 使用zset來儲存排序列表、根據index進行分頁 使用文章id作為member、根據商務規則計算score 使用set來分組

2、redis管理叢集應用伺服器的session會話： Cookie會話：所有http認證機制，都會使用Cookie來作為每次request的認證資訊儲存，即用Cookie實現session。 兩種Cookie： 簽名Cookie（signed）： 包含使用者資訊和簽名（signature）。 簽名，使用md5資訊摘要的機制，來驗證是否被篡改。 令牌Cookie（token） 使用一串隨機位元組走位token，伺服器根據token在資料庫中找到相關使用者資訊。 兩種方式優缺點： token Cookie體積小，節省頻寬。但佔用伺服器儲存。並且對資料庫訪問效能要求高。 簽名Cookie，體積大，驗證簽名機制費力、存在安全性漏洞
3、redis實現購物車： 不再在Cookie中儲存資訊。 而是儲存在redis中： 以使用者token為key，以目前使用者購物車中的商品及其數量構成的hash【抽象為一個購物車】為value，作為redis索引值對來實現
4、網頁緩衝：。。怎麼結合SpringMVC，實現網頁緩衝 將request和返回的content作為redis 字串key-value進行緩衝。 需要篩選可快取的請求。 設定到期時間expire

5、資料行緩衝： 是指：將資料行序列化為json，以行ID為key，作為字串key-value緩衝 資料行更新機制： 兩個有序集合： 調度（schedule）：member為行ID，score為時間戳記，記錄下一次執行緩衝的時間 因為根據時間戳記排序，每次從隊首擷取要當前要緩衝的行ID。 延時（delay）：member為行ID，score為時間間隔，記錄delay值，用於控制緩衝頻率（是否緩衝、下一次什麼時間緩衝） 可以設定delay<=0，則刪除緩衝，不再調度。 其實delay集合可以用hash實現吧。 一個守護進程負責相關工作的運行【類似引擎】
6、網頁分析： 決策哪些商品應該進行redis緩衝最佳化：比如，設定一個記錄商品瀏覽次數的zset，瀏覽一次則該商品score -1。這樣，獲得一個商品熱度熱門排行榜

redis 構建twitter後端

1、redis建模： 使用者資訊（user hash）： 【user：${userId} hash】使用者資訊hash 【user：id： string】使用者資訊id自增計數器 敏感資訊不儲存在此處。（密碼、郵箱等） 【users： hash】使用者名稱login.lower()作為key-value的登入使用者資訊hash 可用於檢查使用者名稱是否已被註冊 狀態資訊（status hash）（即說說、動態） 【status：${statusId} hash】狀態資訊hash。。。類似的實體物件資訊hash，都有相應的id自增計數器

時間軸（ timeline）： 首頁時間軸（home timeline） 【home：${userId}=statusId~timestamp  zset】使用者的首頁時間軸 由自己和following 的使用者，以及只能推薦的使用者發表的status組成。 個人時間軸（profile timeline）

關注列表 粉絲列表（followers list） 【followers：${userId}=userId~timestamp zset】關注目前使用者的人列表。。。timestamp是關注的時間
正在關注列表（following list） 【following：${userId}=userId~timestamp zset】目前使用者正在關注的人列表
2、關注、取關 修改關注列表：followers zset、following zset 修改user hash中followersCount、followingCount這些統計資訊 將被粉絲（取關者）的profile timeline中的若干最新狀態資訊，加入到粉絲的home timeline中。 注意，使用者的home timeline，應該保留最新的HOME_TIMELINE_SIZE數量的status。而不應無限追加。
3、status發布 發布status後更新followers的home timeline的方式分兩種： followers較少時（1000以內）： 直接更新所有followers的home timeline 較多時： 使用【延遲任務】推送給所有followers 關注度的二八原則： followers超過1000的只佔很少一部分。
4、twitter類社交網站，其他常見特性： 私人使用者。關注這類使用者，需要審批機制 收藏 使用者間私聊 評論、點贊、轉寄 @使用者。。。#話題 投訴機制 使用者分組


5、流API——不知所云 一般流式API指的是鏈式編程，即chain。而此處指的是stream。 社交網站的一些動作如發表狀態、刪除狀態等，要瞭解網站的狀態，就要為這些動作【廣播事件】，然後由【事件監聽器】監聽處理這些事件。 本節通過redis的發布訂閱（Publish/Subscribe）模式實現廣播和監聽 流式資料 使用http分塊（chunked）傳輸，將訊息用流（stream）的形式返回給訂閱的用戶端
6、註冊新使用者時，鎖住使用者名稱： 鎖住目前使用者名，保證註冊過程中該使用者名稱不再被別人搶注。如果擷取鎖失敗，表示，該使用者名稱已經被別人鎖住，正在註冊。
7、外部索引鍵關聯除了要有fk_id外，應該加上fk_name： 通常都需要展示關聯的資訊（最少是name）。 如果加上name，壞處是改name的時候，需要大規模關聯修改。好處是不用每次關聯查詢。 但是，由於查詢機率遠大於修改機率，所以應該帶上name




1、自動補全（autocomplete）： 常見應用情境：根據輸入首碼，自動補全搜尋熱詞 使用zset以及ZRANGEBYLEX命令實現： 向zset中添加元素來建立尋找範圍，擷取範圍內的元素後再移除添加的元素 根據輸入的prefix，擷取在當前編碼（通常使用utf-8）下的前驅（predecessor）、後繼（successor） 如果是utf-8的話，前驅的計算方式，是prefix---轉為utf8編碼，然後最後一個位元組減1 後繼則直接為prefix+\xef\xbf\xbf【\uffff Unicode字元的utf-8位元組形式】 將predecessor、successor插入zset， 然後使用ZRANGEBYLEX來擷取兩者之間的元素【注意使用(開區間，從而去掉兩端】——詳細用法參考Redis命令參考文檔 最後使用ZREM移除predecessor、successor 設定zset所有score為0，以便直接對member進行排序搜尋
要在redis-cli命令列，添加位元組（Redis string的最小單位），必須在引號內使用\x加兩位16進位。 競爭條件 race condition：是共用資料保持一致性而加鎖機制中的概念 在合理的範圍內，將部分計算轉移到用戶端，以【分散式運算】的思維，來減輕伺服器的負載。


2、檔案分發： 常見三種檔案分發方式： NFS或者Samba：用於伺服器持續分發檔案 Rsync軟體：（見linux 遠程複製） 使用同步增量的方式，減少傳輸量。 用於內容逐漸發生變化（比如記錄檔） BitTorrent協議： 將檔案分區（partial）分發到多台機器上，然後讓他們互相分享自己擁有的資料，從而降低伺服器的負載。 用於將檔案副本分發到多台機器 局限： 都有顯著的安裝成本和相對價值 都有獨立的服務，需要維護帳號和許可權 NFS/Samba在網路不穩定時會出問題 Rsync雖然對網路連接不敏感，但是同步之前，必須首先下載整個檔案 BitTorrent，需要用戶端有BitTorrent用戶端軟體做支撐。 日誌分析： Map/Reduce、檔案複製不適合 在本地進行資料彙總計算，減少Redis遠程通訊的資源消耗。 發送/接收/處理記錄檔。。

3、 使用redis記錄日誌： 類UNIX系統中常見的兩種日誌記錄方式：
追加日誌行到記錄檔，隨著時間推移添加新的記錄檔（rolling）
syslog服務。。
轉寄功能：接收其他程式的日誌訊息，轉寄到相應的記錄檔