Redis 在微博內部分布在各個應用場景，比如像現在春晚必爭的“紅包飛”活動，還有像粉絲數、用戶數、閱讀數、轉評贊、評論蓋樓、廣告推薦、負反饋、音樂榜單等等都有用到 Redis。

[[280870]]

圖片來自 Pexels

本人將分為如下三個方面分享：

• Redis 在微博的應用場景
• Redis 在微博的優化
• 未來展望

Redis 在微博的應用場景

業務&規模&挑戰

線上的業務有前面提到的信息流、廣告、用戶關系等等，還有現在大家可能比較感興趣的熱搜，用戶一般會去看發生了什么事情，還有引爆閱讀量的話題，以及現在兵家必爭之地的視頻，微博大大小小的業務都有用到 Redis。

線上規模方面，微博有 100T+ 存儲，1000+ 臺物理機，10000+Redis 實例。

關于面臨的挑戰，我們每天有萬億級的讀寫，線上的響應時間要求也比較高。

舉一個簡單的例子，我們部署資源是跨機房部署，但是有一些業務部門連跨機房部署存在的多余 2 毫秒的延遲都要投訴反饋(真的是臣妾做不到啊，如果單機房故障了呢?有些業務方真是異想天開)。響應時間基本上四個 9 是 20 毫秒。

成本的話因為我們線上有大量需求是上 T 的，所以成本壓力其實也特別大。

技術選型

上圖是微博數據庫的技術選型，可以看到這里面不僅僅包含 Redis 等 NoSQL，還有隊列、存儲。

優化

從 2010 年開始，我們就基于官方的 2.0 版本引進 Redis，到現在已經有 9 個年頭了。

我們主要做了以下這些方面的改進：

• Redis 編碼格式，在特殊場景下可以節省 30% 的空間。
• 主從庫方面有獨立的復制線程。
• 我們定制化一些數據結構，比如：LongSet 數據結構，它是一個“固定長度開放尋址的 Hash 數組”，減少 Redis dict 很多額外的指針開銷。
• 在主從復制方面，獨立復制線程+完全增量復制，這樣的話，如果網絡主從臨時斷了，只要從當前的 Pos 點同步數據就行。
• 在持久化方面，我們是全量的 RDB 加增量的 AOF 復制。
• AOF 寫入/ 刷盤，主線程—>BIO，避免了因為寫入導致的阻塞。
• 落地時間，不可控—>cronsave 可控。
• 增加 aofnumber，設置 AOF 數量，避免因為寫入過快，磁盤寫滿。
• 高可用，Redis 的 HA 我們并沒有用官方的或者社區開源的，用的是我們自己開發的一套 Redis HA，保障在故障的情況下，能快速進行切換。

微博有大量的技術場景，比如轉評贊、閱讀數等，對于一些用戶來說，他們是很關心這些指標的。

如果我們用原生的 Redis，會浪費大量的存儲空間，因為它的產品特別特殊，它的 Key 是一個用戶的 ID，Value 是數字。

我們自己內部最早改了一版叫 Redis Counter，它相當于只維持了一個哈希表，節省了大量的 Redis 內存空間。

當然它有一個缺點就是當初是短平快地上線了，所以它只支持單個列和單個表，如果你要存轉發，評論，贊 3 個計數的話需要部署 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 更合理。

總結了一下有三個方面：

• 高性能，讀寫快、訪問快、響應時間快。
• 能夠支持大容量的需求。
• 可擴展，因為接觸的業務方比較多，就會發現一個問題，基本上沒有幾個業務方能把自己的需求描述得特別清楚，經常上線之后才發現內存不夠了，或者寫入扛不住了，所以這個時候我們需要在可擴展性方面提供一個強有力的支持。

我們可以把這三個方面解釋為三座大山。

Cache Service 服務化

為了解決三座大山，首先要把 Cache 服務化，它是一個多級緩存的服務，能夠解決高訪問、高并發的問題以及實現高可用。

基于這套系統，也設計了一套后臺程序，根據微博的流量進行自動監測、能夠支持自動擴縮容，這樣能快速扛過峰值，峰值過去之后又回收機器，實現了對資源的充分利用。

當然這套系統還在持續完善中，希望未來能做到更智能。Config Service 就是我們把配置放在配置中心里面，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 在高并發讀寫情況下，很容易被打死，且在短時間內是恢復不了。

Cache Service 目前支持 MC 和 Redis 協議 2 種協議。

上圖是我們 DBA 操作的擴縮容的界面，這個業務總共有 20 組，每組有 5 個 IP，5×20=100 個實例。

實際上就是一百個實例在里面提供服務，線上有好多個單個集群服務，可以支撐百萬甚至千萬 QPS 的高并發訪問，而且可以支持快速的擴縮容。

分享一下我們之前的成功案例，我們已經實現好幾年的春晚 1000+ 臺阿里云 ECS 彈性擴縮容，多次實現無降級平滑過渡，高峰期支持微博 50% 的春晚核心流量。

上圖是我們內部為了支持系統而進行的系統整合，在這邊就不展開了。

MCQ 服務化

基于前面的 Cache 服務化，我們在 2018 上半年跟業務方一起合作，把隊列也給服務化了。

為什么要把隊列單獨提出來呢?是因為經常有內部或外部的人問，你們發微博是什么樣的流程?你們發評論是什么樣的流程?數據怎么解決?

這些問題很關鍵的一環就是在隊列里面，發微博的時候實際上是先寫到隊列，然后隊列再寫到后端的 MySQL 里面。

如果這個時候 MySQL 宕機了，我們會有一個修復隊列，專門有一個 Key 來存這部分的數據，等 MySQL 恢復以后再把這部分數據寫入到 MySQL 里面。

上面還有一個 BCP，是因為當初我們在做這一套的時候，實際上是想在整個微博推廣。

去年比特幣特別火，我們也想通過購買比特幣的方式，在內部通過機器的資源或者內部開源的一些東西來做等價物質的轉換，然后來應用這個服務，但是最終這個計劃沒有具體落地。

上圖是一鍵告警以及操作的監控圖。前面提到我們把 Cache 服務化了，但是實際上并沒有很好地解決容量過大的問題，雖然現在內存的價格一直在下降，但相對硬盤來說價格還是太高。

如果我們經常有像 5T 或者 10T 的業務，并且全放內存里面的話，對于我們成本的壓力實際上是特別大的。

而且我們需要向專門的成本委員會申領資源，只有成本委員會同意了我們才能拿到這些機器，整個周期時間長。

如何解決 Redis 容量過大?

為了解決容量過大的問題，我們想把容量從內存放到磁盤里面。

我們當時考慮了一些特性，比如支持冷熱數據的分離，比如把歷史的數據或者全量的數據全部存在磁盤，然后支持持久化、支持數據主從復制、支持在線熱升級，需要兼容 Redis 數據類型，還要兼容與 Redis 的復制。

基于前面的場景，像微博這種屬性特別適合用這種方法，就算冷熱數據不明顯，比如上 T，每秒幾 K 訪問的情況，用這個方法也特別合適。

下面講一下處理模塊，里面有主線程和后臺線程。

主線程主要處理連接的請求、協議的解析以及命令的請求，后臺線程主要是復制線程，還有像 BIO 線程，我們把像刷盤操作是寫 AOF 都是放在這個線程，這樣可以盡可能減少寫入所造成的對 Redis 的阻塞。

還有一個 BloomFilter，是基于布谷鳥算法來優化，初始化的時候指定 Filter 的容量，新增雙向鏈表管理 Hash 沖突。

從這個名字大家可以猜到，是 Redis+RocksDB 的結合，為什么這個時候我們不像前面提到的類似設計 CounterserviceSSD 那樣自己設計，其實主要原因是當初我們在設計時 RocksDB 還沒有非常多大規模的應用。

現在 RocksDB 已經特別成熟，而且有非常多成功的案例。

我們還有一個不自己開發的原因，就是如果自己開發的話，可能適用性或者性能，以及代碼健壯性反而沒有那么好，所以為了節省時間我們采用了 RocksDB 來做存儲，避免重復造輪子。

LRU 是為了加快訪問速度的，如果第一次訪問的時候沒有在內存里面讀取到，就從磁盤里面讀取，它實際上會放在內存，下次你再讀取的時候會從 LRU 里面讀取出來。

這邊還涉及到數據從內存到磁盤換入換出，如果 Key 或者 Value 特別大的話，性能會有影響。

這就是前面提到的為什么我們不推薦那種特別大的 Key 或者 Value 用 RedRocks。

把前面的處理模塊和后端整合一下就形成了以下這樣的架構圖：

對其做一下小結：

簡單易用：完全兼容 Redis，業務方不用做任何改動就可以遷移上。

成本優勢：把熱點數據或者頻繁訪問數據放在內存，全量的數據全部放磁盤，這是一個特別大的優勢，可以突破內存容量限制。

高性能：熱點數據在內存，熱點數據訪問性能和 Redis 相當。

下圖是性能壓測報告，我們對比了 Set 的隨機對寫：

仍滿足不了新需求?

我們前面已經解決了大容量的問題，但還是有很多困難并沒有得到很好的解決。

因此，我們借鑒了開源經驗，也調研了 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 做了二次開發，后續我們也會投入到在這方面中。

借用兩句話結束今天的演講：“數據庫實際上是需要你用最快的速度把數據存儲下來，然后以最方便的方式把數據給回憶起來。”

作者：蘭將州

簡介：新浪微博核心 Feed 流、廣告數據庫業務線負責人，主要負責 MySQL、NoSQL、TiDB 相關的自動化開發和運維，參與 Redis、counteservice_ssd、Memcacheq 相關代碼的開發，目前關注分布式系統。