雙11如火如荼的結束了，阿裡雲redis(apsaradb for redis原kvstore)也圓滿完成了雙11redis的保障工作。目前阿裡雲redis提供了單機版本和叢集版本的redis。
單機版本redis具有很高的相容性，并且支援lua腳本及地理位置計算。
叢集版本具有大容量、高性能的特性，能夠突破redis單線程的單機性能極限。
阿裡雲redis預設雙機熱備并提供了備份恢複支援，同時阿裡雲redis源碼團隊持續對redis進行優化更新，提供了強大的安全防護能力。本文将選取雙11的一些業務場景簡化之後進行介紹，實際業務場景會比本文複雜。
微淘社群承載了億級淘寶使用者的社交關系鍊，對于每個使用者都有自己的關注清單，每個商家有自己的粉絲資訊，整個微淘社群承載的關系鍊如下圖所示。
如果選用傳統的關系型資料庫模型表達如上的關系資訊，會使業務設計繁雜，并且不能獲得良好的性能體驗。微淘社群使用redis叢集緩存了存儲社群的關注鍊，簡化了關注資訊的存儲，并保證了雙11業務絲滑一般的體驗。微淘社群使用了hashes存儲使用者之間的關注資訊，存儲結構如下，并提供了以下兩種的查詢接口：
使用者a 是否和 使用者b産生過關注關系；
使用者a的主動關系清單；
雙11使用者在觀看無線端直播的時候，需要對直播對應的評論進行重新整理動作，主要有以下三種模式:
增量下拉。 也即是從指定位置向上擷取指定個數（增量）的評論。
下拉重新整理。 也即是擷取最新的指定個數的評論。
增量上拉。 也即是從指定位置向下擷取指定個數（增量）的評論。
無線直播系統使用redis優化該場景的業務，保證了直播評論接口的成功率，并能夠保證5w+以上的tps和毫秒級的rt請求。直播系統對于每個直播會寫入兩份資料，分别為索引和評論資料，索引資料為sortedset的資料結構用于對評論的排序，而評論資料使用hashes進行存儲，在擷取評論的時候通過索引拿到需要的索引id之後通過hashes的讀取來獲得評論的清單。評論的寫入過程如下：
使用者在重新整理清單之後背景需要擷取對應的評論資訊，擷取的流程如下：
擷取目前索引位置
擷取索引清單
擷取評論資料
雙11使用者在産生一個交易訂單之後會随之産生一個物流訂單。經過菜鳥倉配系統處理的訂單，為了讓倉配各個階段能夠更加智能的協同作業，決策系統會根據訂單資訊指定出對應的訂單履行計劃，包括什麼時候下發倉、什麼時候出庫、什麼時候配送攬收、什麼 時候送達等資訊，單據履行中心根據履行計劃，對每個階段按照對應的時間去履行物流服務。由于倉、配的運力有限，對于有限的運力下，期望最早作業的單據是業務認為優先級最高的單據，是以訂單在真正下發給倉或者配之前，需要按照優先級進行排序。
訂單履行中心通過使用redis來對所有的物流訂單進行排序決定哪個訂單是最高優先級的。