一、Redis在微博的應用場景
Redis在微博內部分佈在各個應用場景，比如像現在春晚必爭的“紅包飛”活動，還有像粉絲數、用戶數、閱讀數、轉評贊、評論蓋樓、廣告推薦、負反饋、音樂榜單等等都有用到Redis。
1、業務&規模&挑戰
線上的業務有前面提到的信息流、廣告、用戶關係等等，還有現在大家可能比較感興趣的熱搜，用戶一般會去看發生了什麼事情，還有引爆閱讀量的話題，以及現在兵家必爭之地的視頻，微博大大小小的業務都有用到Redis。
線上規模方面，微博有100T+存儲，1000+臺物理機，10000+Redis實例。
關於面臨的挑戰，我們每天有萬億級的讀寫，線上的響應時間要求也比較高。
舉一個簡單的例子，我們部署資源是跨機房部署，但是有一些業務部門連跨機房部署存在的多餘兩毫秒的延遲都要投訴反饋（真的是臣妾做不到啊，如果單機房故障了呢？有些業務方真是異想天開）。響應時間基本上四個9是20毫秒。
成本的話因爲我們線上有大量需求是上T的，所以成本壓力其實也特別大。
2、技術選型
上圖是微博數據庫的技術選型，其實可以看到這裏面不僅僅包含Redis等NoSQL，還有隊列、存儲，如果以後有機會的話可以給大家分享一下從0到1搭建微博的數據庫，在內部分享的時候大概花了2-3個小時，時間有限，這次就只講Redis這一部分。
3、優化
從2010年開始，我們就基於官方的2.0版本引進Redis，到現在已經有九個年頭了，我們主要做了以下這些方面的改進：
- Redis編碼格式，在特殊場景下可以節省30%的空間；
- 主從庫方面有獨立的複製線程；
- 我們定製化一些數據結構，比如：LongSet 數據結構，它是一個“固定長度開放尋址的 Hash 數組”，減少Redis dict 很多額外的指針開銷；
- 在主從複製方面，獨立複製線程 + 完全增量複製,這樣的話，如果網絡主從臨時斷了，只要從當前的pos點同步數據就行；
- 在持久化方面，我們是全量的RDB加增量的AOF複製；
- AOF寫入/ 刷盤，主線程—>BIO，避免了因爲寫入導致的阻塞；
- 落地時間，不可控—>cronsave可控；
- 增加aofnumber,設置AOF數量，避免因爲寫入過快，磁盤寫滿；
- 高可用, Redis的HA我們並沒有用官方的或者社區開源的，用的是我們自己開發的一套Redis HA，保障在故障的情況下，能快速進行切換。
微博有大量的技術場景，比如轉評贊、閱讀數等，對於一些用戶來說，他們是很關心這些指標的。
如果我們用原生的Redis，會浪費大量的存儲空間，因爲它的產品特別特殊，它的key是一個用戶的id，value是數字，我們自己內部最早改了一版叫RedisCounter，它相當於只維持了一個哈希表，節省了大量的Redis內存空間。
當然它有一個缺點就是當初是短平快地上線了，所以它只支持單個列和單個表，如果你要存轉發，評論，贊3個計數的話需要部署三套資源，這樣一來大家訪問微博取這3個數的速度會變慢。
而且需要維護3套資源，爲了應對這種場景，我們支持了多列和多表的方式，如果一個表寫滿了，可以繼續寫下一個表，寫到最後一個表時，我們可以把前面的表滾到盤裏面，但是這個時候是不可讀的。
爲了解決不可讀的問題，我們想了一個辦法，把表都放在磁盤裏面，維護ddb的數據結構，在這樣的落地方式下，就可以把最近的熱數據放在內存裏面，把冷數據或者歷史數據放在磁盤裏面。
之前統計了一下，在線上90%多的情況下，用戶只訪問幾個月的數據，所以一些長尾數據可以靠從磁盤中讀取數據來解決，也不影響用戶體驗。
微博還有一些存在性判斷的行爲，比如是否贊過、是否閱讀過，這些全量的數據特別大，如果用Redis的話對內存成本花費特別大。
所以我們改造了一版服務，它是一個兼容Redis協議，基於BloomFilter，開發了一版phantom，高性能，單線程網絡處理機制，與Redis性能相當，低存儲空間，每條記錄佔用1.2*N字節（1%的誤判率，每增加0.6*N字節誤判率下降爲原來的1/10，N爲單個槽位佔用的bit數）。
當然還有其他像我們最近用的隊列、MySQL等等其他類型的數據庫，這邊就不展開了。簡單做一下Redis第一階段優化的小結：
- 無阻塞落地
- 增量複製 -> RDB+AOF
- 在線熱升級
- 關係graph定製
- 內存降爲1/10
- 性能相當
- 計數定製化
- 內存降爲1/4
- 性能提升3-5倍
- BloomFilter
但是我們做了這麼多優化還是跟不上業務的需求。
二、Redis在微博的優化
首先需要明白爲什麼要優化，我們一般從三個方面進行考慮：
首先是業務方。目前線上的業務方需要關心資源的分佈、容量規劃等多方面，比如內存是否滿了、磁盤是否滿了、如果用MySQL的話是否要提前分庫分表、QPS是否能扛住。
我們希望把這些問題對業務方屏蔽，他們只管用，而不用關心太多涉及到資源細節的方面。
第二是DBA。雖然現在微博已經不是處於高速增長的狀態了，但實際上它也還是以一定的速度在增長，所以對DBA來說，需求還是特別多的。
加上我們部門是承接微博所有的數據庫的服務，有微博最多的服務器，因此對於我們來說，需求多，變更多，挑戰大。
從設計的角度，我們要考慮如何設計Redis更合理。
總結了一下有三個方面：
一是高性能，讀寫快、訪問快、響應時間快。
二是能夠支持大容量的需求。
三是可擴展，因爲接觸的業務方比較多，就會發現一個問題，基本上沒有幾個業務方能把自己的需求描述得特別清楚，經常上線之後才發現內存不夠了，或者寫入扛不住了，所以這個時候我們需要在可擴展性方面提供一個強有力的支持。
我們可以把這三個方面解釋爲三座大山。
1、Cache Service服務化
爲了解決三座大山，首先要把Cache服務化，它是一個多級緩存的服務，能夠解決高訪問、高併發的問題以及實現高可用。
基於這套系統，也設計了一套後臺程序，根據微博的流量進行自動監測、能夠支持自動擴縮容，這樣能快速扛過峯值，峯值過去之後又回收機器，實現了對資源的充分利用。
當然這套系統還在持續完善中，希望未來能做到更智能。
ConfigService就是我們把配置放在配置中心裏面，Client再從配置中心裏面拉取配置。
一共有兩種訪問方式，第一種是SDK，第二種是支持多語言的，通過Proxy把請求路由到後端的Cache裏面。DBA只要通過管理平臺就可以對資源進行快速擴縮容。
現在講一下多級的Cache，實際上這裏面有四個角色：master、maste-l1、slave、slave-l1。
master跟slave沒有同步關係，只是按角色作用的方式命名的，master-l1有多組數據來扛熱點，master是基準數據保存全量數據，slave一般是做多機房的容災，slave-l1做多機房的數據同步，這個同步只保證最終數據的一致性。
以讀取作爲例子來說一下流程，讀取是先訪問master-l1，如果沒有命中會訪問master，如果又沒有命中會訪問到slave，通過這3層，大部分情況下能把99%的熱點給扛住，然後還有1%的流量纔會落到MySQL裏面。
假如是100萬的讀，穿透到MySQL只有一萬QPS，如果100萬的讀全部都打到MySQL的話，對於MySQL而言成本特別高，而且大家知道，MySQL在高併發讀寫情況下，很容易被打死，且在短時間內是恢復不了。
Cacheservice 目前支持mc和Redis協議2種協議。
上圖是我們DBA操作的擴縮容的界面，這個業務總共有20組，每組有5個IP，5×20=100個實例，實際上就是一百個實例在裏面提供服務，線上有好多個單個集羣服務，可以支撐百萬甚至千萬QPS的高併發訪問，而且可以支持快速的擴縮容。
分享一下我們之前的成功案例，我們已經實現好幾年的春晚1000+臺阿里雲ECS彈性擴縮容，多次實現無降級平滑過渡，高峯期支持微博50%的春晚核心流量。
上圖是我們內部爲了支持系統而進行的系統整合，在這邊就不展開了。
2、mcq服務化
基於前面的Cache服務化，我們在2018上半年跟業務方一起合作，把隊列也給服務化了。
爲什麼要把隊列單獨提出來呢？是因爲經常有內部或外部的人問，你們發微博是什麼樣的流程？你們發評論是什麼樣的流程？數據怎麼解決？
這些問題很關鍵的一環就是在隊列裏面，發微博的時候實際上是先寫到隊列，然後隊列再寫到後端的MySQL裏面，如果這個時候MySQL宕機了，我們會有一個修復隊列，專門有一個Key來存這部分的數據，等MySQL恢復以後再把這部分數據寫入到MySQL裏面。
上面還有一個BCP，是因爲當初我們在做這一套的時候，實際上是想在整個微博推廣。
去年比特幣特別火，我們也想通過購買比特幣的方式，在內部通過機器的資源或者內部開源的一些東西來做等價物質的轉換，然後來應用這個服務，但是最終這個計劃沒有具體落地。
上圖是一鍵告警以及操作的監控圖。
前面提到我們把Cache服務化了，但是實際上並沒有很好地解決容量過大的問題，雖然現在內存的價格一直在下降，但相對硬盤來說價格還是太高。
如果我們經常有像5T或者10T的業務，並且全放內存裏面的話，對於我們成本的壓力實際上是特別大的。
而且我們需要向專門的成本委員會申領資源，只有成本委員會同意了我們才能拿到這些機器，整個週期時間長。
3、如何解決Redis容量過大？
爲了解決容量過大的問題，我們想把容量從內存放到磁盤裏面。
我們當時考慮了一些特性，比如支持冷熱數據的分離，比如把歷史的數據或者全量的數據全部存在磁盤，然後支持持久化、支持數據主從複製、支持在線熱升級，需要兼容Redis數據類型，還要兼容與Redis的複製。
基於前面的場景，像微博這種屬性特別適合用這種方法，就算冷熱數據不明顯，比如上T，每秒幾K訪問的情況，用這個方法也特別合適。
下面講一下處理模塊，裏面有主線程和後臺線程。
主線程主要處理連接的請求、協議的解析以及命令的請求，後臺線程主要是複製線程，還有像BIO線程，我們把像刷盤操作是寫AOF都是放在這個線程，這樣可以儘可能減少寫入所造成的對Redis的阻塞。
還有一個Bloom Filter，是基於布穀鳥算法來優化，初始化的時候指定Filter的容量，新增雙向鏈表管理Hash衝突。
從這個名字大家可以猜到，是Redis+RocksDB的結合，爲什麼這個時候我們不像前面提到的類似設計CounterserviceSSD那樣自己設計，其實主要原因是當初我們在設計時RocksDB還沒有非常多大規模的應用。
現在RocksDB已經特別成熟，而且有非常多成功的案例。我們還有一個不自己開發的原因，就是如果自己開發的話，可能適用性或者性能，以及代碼健壯性反而沒有那麼好，所以爲了節省時間我們採用了RocksDB來做存儲，避免重複造輪子。
LRU是爲了加快訪問速度的，如果第一次訪問的時候沒有在內存裏面讀取到，就從磁盤裏面讀取，它實際上會放在內存，下次你再讀取的時候會從LRU裏面讀取出來。
這邊還涉及到數據從內存到磁盤換入換出，如果key或者value特別大的話，性能會有影響。這就是前面提到的爲什麼我們不推薦那種特別大的key或者value用RedRocks。
把前面的處理模塊和後端整合一下就形成了以下這樣的架構圖。
對其做一下小結：
- 簡單易用：完全兼容Redis，業務方不用做任何改動就可以遷移上；
- 成本優勢：把熱點數據或者頻繁訪問數據放在內存，全量的數據全部放磁盤，這是一個特別大的優勢，可以突破內存容量限制；
- 高性能：熱點數據在內存，熱點數據訪問性能和Redis相當。
下圖是性能壓測報告，我們對比了set的隨機對寫。
4、仍滿足不了新需求？
我們前面已經解決了大容量的問題，但還是有很多困難並沒有得到很好的解決。
因此，我們借鑑了開源經驗，也調研了Twemproxy、Codis、Corvus、Redis-Cluser這些功能：
實際上我們在2015年就已經存在基於Twemproxy的業務，在線上的話像微博音樂、微博健康、通行證這3個業務已經上線。
但是我們沒有在內部大範圍推廣開來，其中涉及到2個主要的原因，第一就是遷移還是比較費時間，第二是無法比較完美的動態增加節點，還有內部一些其他原因等等的約束。
以上是我們的設計思路，一是能支持在線擴縮容，二是支持多語言的訪問，因爲我們是要對整個公司進行推廣的，而不是說只對一個部門，所以爲了推廣方便我們必須有這種功能，三是對服務化特性的需求。
下面簡單講一下proxy裏面各模塊的功能：
port自動增刪和監聽：根據Vintage對本proxy節點的配置，自動增加監聽的端口或者刪除移除的端口，監聽客戶端的連接。
Redis協議解析：解析Redis協議，確定需要路由的請求，非法和不支持的請求直接返回錯誤。
路由：需要獲取和監聽端口對應的backend以及它們的slot， 根據端口、key和Redis命令選擇一個backend, 將請求路由到對應的backend,並將結果返回給客戶端。
配置監控：監控Vintage中本proxy的配置，包括端口的變動、端口和backend的變動以及slot的變化等，通知端口監聽模塊和路由模塊。
指標監控：需要將Metrics發送到Graphite中進行監控。
日誌記錄：生成日誌文件以便跟蹤。
Redis存儲方面：還是沿用我們內部改造的Redis版本，相對之前線上的版本，這次我們新增了官方比如Mememory，內存編碼的優化，以及內部新增的一些新的功能。
關於集羣管理方面，無論是Redis也好，MySQL也好，對資源的任何管理都可以用這個來總結，包括五個部分：資源申請，資源分配，業務上線，資源查詢，資源變更。
對於業務申請這一方面需要有一個業務唯一的標識，QPS、數據類型是怎樣的，基於這些考察我們再對它進行分配、配置、部署。
基於前面我們做了那麼多的優化以及平臺服務化，用下圖作爲總結比較合適，就相當於服務的高可用、高性能以及可擴展這些方面，我們基本上都用前面這一套方案解決了。
三、未來展望
無論是最開始的MySQL也好還是到後面的Oracle也好，這些都離不開SQL。如果我們能把數據一致性解決好的話，Redis的應用場景會更廣。
現在有很多公司對Raft做了二次開發，後續我們也會投入到在這方面中。
借用兩句話結束今天的演講：“數據庫實際上是需要你用最快的速度把數據存儲下來，然後以最方便的方式把數據給回憶起來。”
謝謝大家！
Q & A
Q1：剛纔您說您這邊有一個新的類型叫LongSet，能不能說一下它的應用場景？
A：應用場景是在關係判斷這個場景下，在微博關注Cache化改造中，需要把Redis當做Cache用存儲用戶的關注列表，原定方案是使用Hash結構。
但是由於Redis是做Cahce使用，key可能會被剔除，所以在判斷用戶是否關注某人的時候，可能不存在，這時就需要從數據庫拉用戶的關注列表直接HMSET到Hash結構中。
但是Redis在一次HSET多個field的時候，性能是比較低的，並且會堵塞其它的請求。
同時在仿真壓力測試過程中發現，在Cache爲空的情況下，必須要逐步放量填充Cache後，業務才能達到穩定。
這種情況下，對運維的壓力比較大，容錯很低，違背了我們Cache化的初衷，所以纔有了這一次的改造。
爲了解決Redis Hash結構HMSET性能較低及內存利用率較低的問題，對Redis進行了定製化改造，增加了一種新的數據結構LongSet，用來存儲元素爲long類型的集合。
Q2：您剛剛解釋的是熱數據放在Redis，初始放在RocksDB，什麼時候調用這個數據？什麼時候調用那個數據？肯定是有一張表吧？
A：讀取流程是，先讀取內存中的數據，這個內存大小是可以動態調整的，和官方的maxMemory參數是一致的，內存中只保留一部分的數據，如果內存中的數據沒有讀取到，纔會從磁盤裏面讀取數據。
作者介紹：
蘭將州，新浪微博核心feed流、廣告數據庫業務線負責人，主要負責MySQL、NoSQL、TiDB相關的自動化開發和運維，參與Redis、counteservice_ssd、memcacheq相關代碼的開發，目前關注分佈式系統。
本文由 dbaplus 社羣授權轉載。