五課時回顧：主要介紹了如何通過Facebook主頁找到更對我們的業(yè)務(wù)感興趣的潛在用戶。當(dāng)我們找到潛在受眾后就要開始針對自己的業(yè)務(wù)和客戶創(chuàng)建適當(dāng)?shù)奶印Ｋ缘诹n時主要講述如何在Facebook主頁上創(chuàng)建帖子，

通過Facebook主頁發(fā)帖時，您可以：

1.撰寫會立即顯示在主頁上的更新

2.向帖子添加照片和視頻

3.設(shè)置排期帖，節(jié)省時間

4.速推帖子，向更多用戶營銷

5.創(chuàng)建優(yōu)惠或活動

6.將帖子譯為不同的語言

一、創(chuàng)建Facebook基本帖子

只需在顯示“最近在忙什么呢？”的方框中鍵入內(nèi)容。

狀態(tài)更新可以是您認(rèn)為客戶會感興趣的任何內(nèi)容，例如：促銷公告或新品照片。所有帖子都會顯示在Facebook主頁上，并可能會顯示在主頁點贊用戶的動態(tài)消息中。

1. 點擊時鐘圖標(biāo)即可設(shè)置排期貼，在日后發(fā)布。

2. 點擊定位圖標(biāo)即可選擇帖子的分享對象。如果只想向特定年齡或位于特定國家/地區(qū)的客戶展示帖子，此功能很有用。

3. 點擊地點圖標(biāo)即可添加自己所在的地點——如果在不同的地點或在活動中發(fā)帖，此功能很有用。

4. 點擊相機(jī)圖標(biāo)即可向帖子添加照片或視頻。

5. 準(zhǔn)備好帖子后，只需點擊“發(fā)布”。

二、在Facebook主頁上為帖子獲得更多關(guān)注

帖子發(fā)布后，您可以增加帖子的關(guān)注度。

點擊帖子右上角的箭頭，然后選擇：

1.置頂，讓帖子保持在Facebook主頁頂部。該帖子將是用戶第一眼看到的帖子，如果您有重要更新或活動，此功能就是絕佳選擇。

2.嵌入帖子，將帖子添加到網(wǎng)站。如果希望網(wǎng)站訪客看到某個特別的帖子，F(xiàn)acebook 將為您提供一小段代碼，用于添加至網(wǎng)頁的 HTML 代碼中。當(dāng)訪客在網(wǎng)站上點擊該帖子時，他們將直接轉(zhuǎn)至您的 Facebook 主頁。

三、關(guān)于您業(yè)務(wù)的優(yōu)惠、活動或大事記的帖子

您還可以通過Facebook帖子為客戶提供優(yōu)惠、邀請他們參加活動或向他們介紹您業(yè)務(wù)的特別大事記。

只需點擊狀態(tài)更新字段頂部的“優(yōu)惠、活動 +”即可創(chuàng)建此類帖子。

A.優(yōu)惠

優(yōu)惠是用戶可以在 Facebook 領(lǐng)取并在您店鋪中使用的限時折扣，例如抵用券。

1. 點擊“活動、大事件+”，然后選擇“優(yōu)惠”。

2. 填寫表格，包括優(yōu)惠的投放時間、可以領(lǐng)取優(yōu)惠的客戶數(shù)量、想要覆蓋的受眾、以及愿意花費的預(yù)算。

B.活動

當(dāng)用戶接受活動邀請后，系統(tǒng)就會將活動添加至用戶個人的 Facebook 活動日歷。

他們會收到活動提醒，并在活動更改后收到通知。您還可以查看誰接受了邀請，以便了解參加活動的預(yù)計人數(shù)。

1. 點擊“優(yōu)惠、活動+”，然后選擇“活動”。

2. 填寫表格，包括名稱、地點、時間等。

C.大事記

主頁還可用于慶祝您業(yè)務(wù)的特別事件，例如：開業(yè)儀式或周年紀(jì)念。

1. 點擊“優(yōu)惠、活動+”，然后選擇“大事件”。

2. 填寫表格，包括標(biāo)題、地區(qū)、時間等。

D.按地區(qū)或語言顯示帖子

如果客戶遍布世界各地或使用不同的語言，則可以設(shè)置帖子，使其針對特定地區(qū)/語言向相應(yīng)客戶展示。*

1. 點擊“公開”按鈕，然后選擇“區(qū)域/語言”。選擇顯示帖子的地區(qū)和分享對象所使用的語言。

2. 點擊“保存發(fā)帖設(shè)置”按鈕，即可按照您的設(shè)置向特定分享對象顯示帖子。

*設(shè)置此功能后，客戶必須位于所選地區(qū)或?qū)?Facebook 設(shè)置為所選語言，才能在您的主頁、自己的動態(tài)消息或搜索結(jié)果中看見相關(guān)帖子。

E.指尖輕觸，創(chuàng)建帖子

在Facebook主頁管理應(yīng)用中，前往主頁并輕觸“發(fā)帖”或“分享照片”。

輕觸“發(fā)帖”后，可以通過顯示的鍵盤輸入文本。輕觸鍵盤上方的相機(jī)圖標(biāo)，可以添加照片應(yīng)用中的照片并編輯這些照片。輕觸時鐘圖標(biāo)，可以設(shè)置排期帖，讓帖子在預(yù)定時間顯示。

輕觸“分享照片”，可以選擇照片應(yīng)用中的照片，編輯照片，并添加與照片一起顯示的文字。

1. 輕觸“文字內(nèi)容”或“照片”即可向主頁發(fā)帖

2. 輕觸相機(jī)圖標(biāo)即可向帖子添加照片

3. 直接在主頁管理應(yīng)用中編輯照片，讓它們更搶眼

4. 點擊時鐘圖標(biāo)可設(shè)置排期貼，以便在日后顯示

博及 Twitter 這兩大社交平臺都重度依賴 Redis 來承載海量用戶訪問。本文介紹如何使用 Redis 來設(shè)計一個社交系統(tǒng)，以及如何擴(kuò)展 Redis 讓其能夠承載上億用戶的訪問規(guī)模。

雖然單臺 Redis 具備極佳的性能，但隨著系統(tǒng)規(guī)模增大，單臺服務(wù)器不能存儲所有數(shù)據(jù)、以及沒辦法處理所有讀寫請求的問題遲早都會出現(xiàn)，這時我們就需要對 Redis 進(jìn)行擴(kuò)展，讓它能夠滿足需求。

在介紹如何擴(kuò)展之前，我們先看下如何用 Redis 來搭建一個社交平臺。

使用 Redis 搭建社交平臺

用 Redis 來搭建一個社交平臺，需要首先考慮以下幾個核心功能。

1. 已發(fā)表微博

可以使用 Redis 的 hash 來保存已發(fā)表微博。

一條微博通常包括多個字段，比如發(fā)表時間、發(fā)表用戶、正文內(nèi)容等，通常使用微博 id 作為 key 將多個鍵值對作為 hash 保存在 Redis 中。

2. 信息流

當(dāng)一個用戶訪問它的首頁信息流時候，他可以看到他所有關(guān)注用戶最新的信息。key 是當(dāng)前用戶的 uid, 信息流的內(nèi)容以 id / timestamp 的形式保存在 zset 中，timestamp 用于排序，以便返回的列表是按照時間順序排列。微博的 id 用于業(yè)務(wù)下一步獲取微博的相關(guān)信息。

3. 關(guān)注與粉絲

我們可以把關(guān)注及粉絲庫也存在 zset 中，依舊使用 timestamp 來排序。key 是當(dāng)前用戶 uid。

了解上述結(jié)構(gòu)之后，我們繼續(xù)來看如何使用 Redis 來擴(kuò)展整個系統(tǒng)，具備處理億級用戶的能力。

我們首先要做的，就是在 Redis 能夠存儲所有數(shù)據(jù)并且能夠正常地處理寫查詢的情況下，讓 Redis 的讀查詢處理能力超過單臺 Redis 服務(wù)器所能提供的讀查詢處理能力。

擴(kuò)展讀性能

假定我們用 Redis 構(gòu)建一個與微博或 Twitter 具有相同特性和功能的社交網(wǎng)站，網(wǎng)站的其中一個特性就是允許用戶查看他們自己的 profile 頁和個人首頁信息流，每當(dāng)用戶訪問時，程序就會從信息流里面獲取大約 30 條內(nèi)容。

因為一臺專門負(fù)責(zé)獲取信息流的 Redis 服務(wù)器每秒至少可以同時為 3,000 ～ 10,000 個用戶獲取信息流消息，所以這一操作對于規(guī)模較小的社交網(wǎng)站來說并不會造成什么問題。

但是對于規(guī)模更大的社交網(wǎng)站來說，程序每秒需要獲取的信息流消息數(shù)量將遠(yuǎn)遠(yuǎn)超過單臺 Redis 服務(wù)器所能處理的上限，因此我們必須想辦法提升 Redis 每秒能夠獲取的信息流消息數(shù)量。

下面我們將會討論如何使用只讀的從服務(wù)器提升系統(tǒng)處理讀查詢的性能，使得系統(tǒng)的整體讀性能能夠超過單臺 Redis 服務(wù)器所能提供的讀查詢性能上限。

在對讀查詢的性能進(jìn)行擴(kuò)展，并將額外的服務(wù)器用作從服務(wù)器以提高系統(tǒng)處理讀查詢的性能之前，讓我們先來回顧一下 Redis 提高性能的幾個途徑。

• 在使用短結(jié)構(gòu)時，請確保壓縮列表的最大長度不會太大以至于影響性能。

• 根據(jù)程序需要執(zhí)行的查詢的類型，選擇能夠為這種查詢提供最好性能的結(jié)構(gòu)。比如說，不要把 LIST 當(dāng)作 SET 使用；也不要獲取整個 HASH 然后在客戶端里面對其進(jìn)行排序，而是應(yīng)該直接使用 ZSET；諸如此類。

• 在將大體積的對象緩存到 Redis 之前，考慮對它進(jìn)行壓縮以減少讀取和寫入對象時所需的網(wǎng)絡(luò)帶寬。對比壓縮算法 lz4、gzip 和 bzip2，看看哪個算法能夠?qū)Ρ淮鎯Φ臄?shù)據(jù)提供最好的壓縮效果和最好的性能。

• 使用 pipeline（pipeline 是否啟用事務(wù)性質(zhì)由具體的程序決定）以及連接池。

在做好了能確保讀查詢和寫查詢能夠快速執(zhí)行的一切準(zhǔn)備之后，接下來要考慮的就是如何實際解決“怎樣才能處理更多讀請求”這個正題。

提升 Redis 讀取能力的最簡單方法，就是添加提供讀能力的從服務(wù)器。

用戶可以運行一些額外的服務(wù)器，讓它們與主服務(wù)器進(jìn)行連接，然后接受主服務(wù)器發(fā)送的數(shù)據(jù)副本并通過網(wǎng)絡(luò)進(jìn)行準(zhǔn)實時的更新（具體的更新速度取決于網(wǎng)絡(luò)帶寬）。通過將讀請求分散到不同的從服務(wù)器上面進(jìn)行處理，用戶可以從新添加的從服務(wù)器上獲得額外的讀查詢處理能力。

記住：只對主服務(wù)器進(jìn)行寫入

在使用只讀從服務(wù)器的時候，請務(wù)必記得只對 Redis 主服務(wù)器進(jìn)行寫入。在默認(rèn)情況下，嘗試對一個被配置為從服務(wù)器的 Redis 服務(wù)器進(jìn)行寫入將引發(fā)一個錯誤（就算這個從服務(wù)器是其他從服務(wù)器的主服務(wù)器，也是如此）。

簡單來說，要將一個 Redis 服務(wù)器變?yōu)閺姆?wù)器，我們只需要在 Redis 的配置文件里面，加上一條 slaveof host port語句，并將 host 和 port 兩個參數(shù)的值分別替換為主服務(wù)器的 IP 地址和端口號就可以了。除此之外，我們還可以通過對一個正在運行的 Redis 服務(wù)器發(fā)送SLAVEOF host port命令來把它配置為從服務(wù)器。需要注意的一點是，當(dāng)一個從服務(wù)器連接至主服務(wù)器的時候，從服務(wù)器原本存儲的所有數(shù)據(jù)將被清空。最后，通過向從服務(wù)器發(fā)送SLAVEOF no one命令，我們可以讓這個從服務(wù)器斷開與主服務(wù)器的連接。

使用多個 Redis 從服務(wù)器處理讀查詢時可能會遇到的最棘手的問題，就是主服務(wù)器臨時下線或者永久下線。每當(dāng)有從服務(wù)器嘗試與主服務(wù)器建立連接的時候，主服務(wù)器就會為從服務(wù)器創(chuàng)建一個快照，如果在快照創(chuàng)建完畢之前，有多個從服務(wù)器都嘗試與主服務(wù)器進(jìn)行連接，那么這些從服務(wù)器將接收到同一個快照。從效率的角度來看，這種做法非常好，因為它可以避免創(chuàng)建多個快照。

但是，同時向多個從服務(wù)器發(fā)送快照的多個副本，可能會將主服務(wù)器可用的大部分帶寬消耗殆盡。使主服務(wù)器的延遲變高，甚至導(dǎo)致主服務(wù)器已經(jīng)建立了連接的從服務(wù)器斷開。

解決從服務(wù)器重同步（resync）問題的其中一個方法，就是減少主服務(wù)器需要傳送給從服務(wù)器的數(shù)據(jù)數(shù)量，這可以通過構(gòu)建樹狀復(fù)制中間層來完成。

（圖：一個 Redis 主從復(fù)制樹示例，樹的最底層由 9 個從服務(wù)器組成，而中間層則由 3 個復(fù)制輔助服務(wù)器組成）

從服務(wù)器樹非常有用，在對不同數(shù)據(jù)中心（data center）進(jìn)行復(fù)制的時候，這種從服務(wù)器樹甚至是必需的：通過緩慢的廣域網(wǎng)（WAN）連接進(jìn)行重同步是一件相當(dāng)耗費資源的工作，這種工作應(yīng)該交給位于中間層的從服務(wù)器去做，而不必勞煩最頂層的主服務(wù)器。但是另一方面，構(gòu)建從服務(wù)器樹也會帶來復(fù)雜的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)（topology），這增加了手動和自動處理故障轉(zhuǎn)移的難度。

除了構(gòu)建樹狀的從服務(wù)器群組之外，解決從服務(wù)器重同步問題的另一個方法就是對網(wǎng)絡(luò)連接進(jìn)行壓縮，從而減少需要傳送的數(shù)據(jù)量。一些 Redis 用戶就發(fā)現(xiàn)使用帶壓縮的 SSH 隧道（tunnel）進(jìn)行連接可以明顯地降低帶寬占用，比如某個公司就曾經(jīng)使用這種方法，將復(fù)制單個從服務(wù)器所需的帶寬從原來的 21Mbit 降低為 1.8Mbit（http://mng.bz/2ivv）。如果讀者也打算使用這個方法的話，那么請記得使用 SSH 提供的選項來讓 SSH 連接在斷線后自動重連。

加密和壓縮開銷

一般來說，使用 SSH 隧道帶來的加密開銷并不會給服務(wù)器造成大的負(fù)擔(dān)，因為2.6 GHz 主頻的英特爾酷睿 2 單核處理器在只使用單個處理核心的情況下，每秒能夠使用 AES-128 算法加密 180MB 數(shù)據(jù)，而在使用 RC4 算法的情況下，每秒則可以加密大約 350MB 數(shù)據(jù)。在處理器足夠強(qiáng)勁并且擁有千兆網(wǎng)絡(luò)連接的情況下，程序即使在加密的情況下也能夠充分地使用整個網(wǎng)絡(luò)連接。

唯一可能會出問題的地方是壓縮—因為 SSH 默認(rèn)使用的是 gzip 壓縮算法。SSH 提供了配置選項，可以讓用戶選擇指定的壓縮級別（具體信息可以參考SSH的文檔），它的 1 級壓縮在使用之前提到的 2.6GHz 處理器的情況下，可以在復(fù)制的初始時候，以每秒 24～52MB 的速度對 Redis 的 RDB 文件進(jìn)行壓縮；并在復(fù)制進(jìn)入持續(xù)更新階段之后，以每秒 60～80MB 的速度對 Redis 的 AOF 文件進(jìn)行壓縮。

使用 Redis Sentinel

Redis Sentinel 可以配合 Redis 的復(fù)制功能使用，并對下線的主服務(wù)器進(jìn)行故障轉(zhuǎn)移。Redis Sentinel 是運行在特殊模式下的 Redis 服務(wù)器，但它的行為和一般的 Redis 服務(wù)器并不相同。

Sentinel 會監(jiān)視一系列主服務(wù)器以及這些主服務(wù)器的從服務(wù)器，通過向主服務(wù)器發(fā)送 PUBLISH命令和 SUBSCRIBE 命令，并向主服務(wù)器和從服務(wù)器發(fā)送PING命令，各個 Sentinel 進(jìn)程可以自主識別可用的從服務(wù)器和其他 Sentinel。

當(dāng)主服務(wù)器失效的時候，監(jiān)視這個主服務(wù)器的所有 Sentinel 就會基于彼此共有的信息選出一個 Sentinel，并從現(xiàn)有的從服務(wù)器當(dāng)中選出一個新的主服務(wù)器。當(dāng)被選中的從服務(wù)器轉(zhuǎn)換成主服務(wù)器之后，那個被選中的 Sentinel 就會讓剩余的其他從服務(wù)器去復(fù)制這個新的主服務(wù)器（在默認(rèn)設(shè)置下，Sentinel 會一個接一個地遷移從服務(wù)器，但這個數(shù)量可以通過配置選項進(jìn)行修改）。

一般來說，使用 Redis Sentinel 的目的就是為了向主服務(wù)器屬下的從服務(wù)器提供自動故障轉(zhuǎn)移服務(wù)。此外，Redis Sentinel 還提供了可選的故障轉(zhuǎn)移通知功能，這個功能可以通過調(diào)用用戶提供的腳本來執(zhí)行配置更新等操作。

更深入了解 Redis Sentinel 可以閱讀 http://redis.io/topics/sentinel

在了解如何擴(kuò)展讀性能的方法之后，接下來我們該考慮如何擴(kuò)展寫性能了。

擴(kuò)展寫性能和內(nèi)存容量

隨著被緩存的數(shù)據(jù)越來越多，當(dāng)數(shù)據(jù)沒辦法被存儲到單臺機(jī)器上面的時候，我們就需要想辦法把數(shù)據(jù)分割存儲到由多臺機(jī)器組成的集群里面。

擴(kuò)展寫容量

盡管這一節(jié)中討論的是如何使用分片來增加可用內(nèi)存的總數(shù)量，但是這些方法同樣可以在一臺 Redis 服務(wù)器的寫性能到達(dá)極限的時候，提升 Redis 的寫吞吐量。

在對寫性能進(jìn)行擴(kuò)展之前，首先需要確認(rèn)我們是否已經(jīng)用盡了一切辦法去降低內(nèi)存占用，并且是否已經(jīng)盡可能地減少了需要寫入的數(shù)據(jù)量。

• 對自己編寫的所有方法進(jìn)行了檢查，盡可能地減少程序需要讀取的數(shù)據(jù)量。

• 將無關(guān)的功能遷移至其他服務(wù)器。

• 在對 Redis 進(jìn)行寫入之前，嘗試在本地內(nèi)存中對將要寫入的數(shù)據(jù)進(jìn)行聚合計算，這一做法可以應(yīng)用于所有分析方法和統(tǒng)計計算方法。

• 使用鎖去替換可能會給速度帶來限制的 WATCH/MULTI/EXEC 事務(wù)，或者使用 Lua 腳本。

• 在使用 AOF 持久化的情況下，機(jī)器的硬盤必須將程序?qū)懭氲乃袛?shù)據(jù)都存儲起來，這需要花費一定的時間。對于 400,000 個短命令來說，硬盤每秒可能只需要寫入幾 MB 的數(shù)據(jù)；但是對于 100,000 個長度為 1KB 的命令來說，硬盤每秒將需要寫入100MB 的數(shù)據(jù)。

如果用盡了一切方法降低內(nèi)存占用并且盡可能地提高性能之后，問題仍然未解決，那么說明我們已經(jīng)遇到了只使用單臺機(jī)器帶來的瓶頸，是時候?qū)?shù)據(jù)分片到多臺機(jī)器上面了。

本文介紹的數(shù)據(jù)分片方法要求用戶使用固定數(shù)量的 Redis 服務(wù)器。舉個例子，如果寫入量預(yù)計每 6 個月就會增加 4 倍，那么我們可以將數(shù)據(jù)預(yù)先分片（preshard）到 256 個分片里面，從而擁有一個在接下來的 2 年時間里面都能夠滿足預(yù)期寫入量增長的分片方案（具體要規(guī)劃多長遠(yuǎn)的方案要由你自己決定）。

為了應(yīng)對增長而進(jìn)行預(yù)先分片

在為了應(yīng)對未來可能出現(xiàn)的流量增長而對系統(tǒng)進(jìn)行預(yù)先分片的時候，我們可能會陷入這樣一種處境：目前擁有的數(shù)據(jù)實在太少，按照預(yù)先分片方法計算出的機(jī)器數(shù)量去存儲這些數(shù)據(jù)只會得不償失。為了能夠如常地對數(shù)據(jù)進(jìn)行分割，我們可以在單臺機(jī)器上面運行多個 Redis 服務(wù)器，并將每個服務(wù)器用作一個分片。

注意，在同一臺機(jī)器上面運行多個 Redis 服務(wù)器的時候，請記得讓每個服務(wù)器都監(jiān)聽不同的端口，并確保所有服務(wù)器寫入的都是不同的快照文件或 AOF 文件。

在單臺機(jī)器上面運行多個 Redis 服務(wù)器

上面介紹了如何將寫入命令分片到多臺服務(wù)器上面執(zhí)行，從而增加系統(tǒng)的可用內(nèi)存總量并提高系統(tǒng)處理寫入操作的能力。但是，如果你在執(zhí)行諸如搜索和排序這樣的復(fù)雜查詢時，感覺系統(tǒng)的性能受到了 Redis 單線程設(shè)計的限制，而你的機(jī)器又有更多的計算核心、更多的通信網(wǎng)絡(luò)資源，以及更多用于存儲快照文件和 AOF 文件的硬盤 I/O，那么你可以考慮在單臺機(jī)器上面運行多個 Redis 服務(wù)器。你需要做的就是對位于同一臺機(jī)器上面的所有服務(wù)器進(jìn)行配置，讓它們分別監(jiān)聽不同的端口，并確保它們擁有不同的快照配置或 AOF 配置。

擴(kuò)展復(fù)雜的業(yè)務(wù)場景

在對各式各樣的 Redis 服務(wù)進(jìn)行擴(kuò)展的時候，常常會遇到這樣一種情況：因為服務(wù)執(zhí)行的查詢并不只是讀寫那么簡單，所以只對數(shù)據(jù)進(jìn)行簡單分片并不足以滿足復(fù)雜業(yè)務(wù)場景的需求。

對社交網(wǎng)站進(jìn)行擴(kuò)展

下面介紹如何對類似微博或者 Twitter 這樣的社交網(wǎng)站進(jìn)行擴(kuò)展，介紹的目的是為了讓我們更好的理解使用什么樣的數(shù)據(jù)結(jié)構(gòu)及方法來構(gòu)建一個大型社交網(wǎng)絡(luò)，這些方法幾乎可以無限制地進(jìn)行——只要資金允許，我們可以將一個社交網(wǎng)站擴(kuò)展至任意規(guī)模。

對社交網(wǎng)站進(jìn)行擴(kuò)展的第一步，就是找出經(jīng)常被讀取的數(shù)據(jù)以及經(jīng)常被寫入的數(shù)據(jù)，并思考是否有可能將常用數(shù)據(jù)和不常用數(shù)據(jù)分開。

首先，假設(shè)我們已經(jīng)把用戶已發(fā)表的微博放在一個獨立的 Redis 服務(wù)器，并使用只讀的從服務(wù)器處理針對這些數(shù)據(jù)進(jìn)行大量讀取操作。那么一個社交網(wǎng)站上需要進(jìn)行擴(kuò)展的主要是兩個類型的數(shù)據(jù)：信息流、關(guān)注及粉絲列表。

擴(kuò)展已發(fā)表微博的數(shù)據(jù)庫

當(dāng)你的社交網(wǎng)站獲得一定的訪問量之后，我們需要對存儲已發(fā)表微博的數(shù)據(jù)庫做進(jìn)一步的擴(kuò)展，而不僅僅只添加從服務(wù)器。

因為每條微博都完整地存儲在一個單獨的 HASH 里面，所以程序可以很容易地基于散列所在的鍵，把各條微博 hash 分片到由多個 Redis 服務(wù)器組成的集群里面。

因為對每條微博 hash 進(jìn)行分片并不困難，所以分片的工作應(yīng)該并不難完成。擴(kuò)展微博數(shù)據(jù)庫的另一種方法，就是將 Redis 用作緩存，并把最新發(fā)布的消息存儲到 Redis 里，而較舊（也就是較少讀取）的消息則存儲到以硬盤存儲為主的服務(wù)器里面，像 PostgreSQL、MySQL、Riak、MongoDB 等。

在一個社交網(wǎng)站上，主要的信息流有 3 種：用戶首頁的信息流、profile 信息流以及分組信息流。各個信息流本身都是相似的，所以我們將使用相同的處理方式。

下面我們來看社交系統(tǒng)中最核心的兩種系統(tǒng)如何通過不同的分片策略對其進(jìn)行擴(kuò)展。

1．對信息流列表進(jìn)行分片

標(biāo)題所說的“對信息流進(jìn)行分片”實際上有些詞不達(dá)意，因為首頁信息流和分組列表信息流通常都比較短（最大通常只有 1,000 條，實際的數(shù)量由 zset-max-ziplist-size選項的值決定），因此實際上并不需要對信息流的內(nèi)容進(jìn)行分片；我們真正要做的是根據(jù)鍵名，把不同的信息流分別存儲到不同的分片上面。

另一方面，社交網(wǎng)站每個用戶 profile 信息流通常無限增長的。盡管絕大多數(shù)用戶每天最多只會發(fā)布幾條微博，但也有話癆用戶以明顯高于這一頻率的速度發(fā)布大量信息。以 Twitter 為例，該網(wǎng)站上發(fā)布信息最多的 1,000 個用戶，每人都發(fā)布了超過 150,000 條推文，而其中發(fā)布最多的 15 個用戶，每人都發(fā)布了上百萬條推文。

從實用性的角度來看，一個合乎情理的做法是限制每個用戶的已發(fā)表微博最多只能存儲大約 20,000 條信息，并將最舊的信息刪除或者隱藏——這種做法足以處理 99.999% 的 Twitter 用戶，而我們也會使用這一方案來對社交網(wǎng)站的個人信息流進(jìn)行擴(kuò)展。擴(kuò)展個人信息流的另一種方法，就是使用本節(jié)稍后介紹的關(guān)注庫進(jìn)行擴(kuò)展的技術(shù)。

2．通過分片對關(guān)注及粉絲列表擴(kuò)展

雖然對信息流進(jìn)行擴(kuò)展的方法相當(dāng)直觀易懂，但是對關(guān)注和粉絲列表這些由有序集合構(gòu)成的“列表”進(jìn)行擴(kuò)展卻并不容易。這些有序集合絕大多數(shù)都很短（如 Twitter 上 99.99% 的用戶的關(guān)注者都少于 1,000 人），但是也存在少量用戶的列表非常大，他們關(guān)注了非常多的人或者擁有數(shù)量龐大的粉絲。

從實用性的角度來考慮，一個合理的做法是給用戶以及分組可以關(guān)注的人數(shù)設(shè)置一個上限（比如新浪微博普通用戶最大允許關(guān)注 2,000 用戶）。不過這個方法雖然可以控制用戶的關(guān)注人數(shù)，但是仍然解決不了單個用戶的粉絲數(shù)人數(shù)過多的問題。

為了處理關(guān)注和粉絲列表變得非常巨大的情況，我們需要將實現(xiàn)這些列表的有序集合劃分到多個分片上面，說得更具體一樣，也就是根據(jù)分片的數(shù)量把用戶的粉絲劃分為多個部分，存在多個 zset 中。為此，我們需要為 ZADD命令、ZREM命令和ZRANGEBYSCORE命令實現(xiàn)特定的分片版本。

和信息流分片的區(qū)別是，這次分片的對象是數(shù)據(jù)而不是鍵。此外，為了減少程序創(chuàng)建和調(diào)用連接的數(shù)量，把關(guān)注和粉絲的數(shù)據(jù)放置在同一個分片里面將是一種非常有意義的做法。因此這次我們將使用新的方法對數(shù)據(jù)進(jìn)行分片。

為了能夠在關(guān)注及粉絲數(shù)據(jù)進(jìn)行分片的時候，把兩者數(shù)據(jù)都存儲到同一個分片里面，程序?qū)殃P(guān)注者和被關(guān)注者雙方的 ID 用作查找分片鍵的其中一個參數(shù)。

總結(jié)

本章對各式各樣的程序進(jìn)行了回顧，介紹了一些對它們進(jìn)行擴(kuò)展以處理更多讀寫流量并獲得更多可用內(nèi)存的方法，其中包括使用只讀從服務(wù)器、使用可以執(zhí)行寫查詢的從服務(wù)器、使用分片以及使用支持分片功能的類和函數(shù)。盡管這些方法可能沒有完全覆蓋讀者在擴(kuò)展特定程序時可能會遇到的所有問題，但是這些例子中展示的每項技術(shù)都可以廣泛地應(yīng)用到其他情景里面。

本文希望向讀者傳達(dá)這樣一個概念：對任何系統(tǒng)進(jìn)行擴(kuò)展都是一項頗具挑戰(zhàn)性的任務(wù)。但是通過 Redis，我們可以使用多種不同的方法來對平臺進(jìn)行擴(kuò)展，從而把平臺擴(kuò)展成我們想要的規(guī)模。

本文節(jié)選自人民郵電出版社《Redis 實戰(zhàn)》第 8、10 章，由聚焦 Redis 領(lǐng)域的黃健宏翻譯，感興趣的讀者可以在各大書店購買。以下是翻譯過程中的一張照片，看出譯者對質(zhì)量非常用心。

圖片來源：http://blog.huangz.me/diary/2015/memories-of-redis-in-action-translation.html

人郵也新開了公眾號「人郵 IT 書坊」長期提供最新 IT 圖書資訊，歡迎關(guān)注。

、背景

疫情至今近三年，國家和各省市衛(wèi)健委官網(wǎng)都是通過全文本通報每日疫情數(shù)據(jù)，內(nèi)容數(shù)據(jù)里有境外、國內(nèi)，有確診、無癥狀，確診里又可能含無癥狀轉(zhuǎn)確診（各地通報不一樣）等等，一堆文字和數(shù)據(jù)看的確實頭疼，一直不明白為什么不做成表格，降低信息傳遞的成本。最近有點時間，就嘗試做了個這樣的項目：每日自動獲取國家衛(wèi)健委官網(wǎng)疫情數(shù)據(jù)轉(zhuǎn)并為表格，再自動發(fā)布到。

二、程序執(zhí)行效果

先看下程序執(zhí)行的效果吧，可以關(guān)注“橙獅科技”頭條號，查看每日自動更新的微頭條。

三、方案實現(xiàn)

1、總體方案
整體方案如圖1，流程比較清晰，重點是如何通過程序發(fā)布頭條（下文會展開描述）。開發(fā)語言選擇Python，主要原因是：有豐富的相關(guān)功能庫，語法相對簡單，解析語言跨平臺方便。

2、數(shù)據(jù)獲取
這一步驟大致如下，相對簡單，具體就不展開描述了：
1、http get 網(wǎng)頁內(nèi)容
2、通過BeautifulSoup 解析HTML，清洗html文本數(shù)據(jù)，獲取疫情文本內(nèi)容

3、數(shù)據(jù)處理
1）第一步
數(shù)據(jù)處理的第一步是獲取全國，各省和新疆兵團(tuán)的各自維度病例數(shù)，如本土確診，本土無癥狀，本土無癥狀轉(zhuǎn)確診，境外輸入確診，境外輸入無癥狀等。獲取的文本內(nèi)容如圖2，衛(wèi)健委每日通報文本內(nèi)容結(jié)構(gòu)都是一致的，如先通報國外數(shù)據(jù)，再通報國內(nèi)數(shù)據(jù)，各省市的數(shù)據(jù)都在括號里、逗號分隔，這些都是程序處理的關(guān)鍵邏輯和標(biāo)識符。這部分程序上都是字符串的處理，輸出pyhton字典保存各維度病例數(shù)，具體代碼邏輯就不展開描述了。

2）第二步
獲取到各維度病例數(shù)后，接著就是生成表格圖片，這里花了一些時間做調(diào)研和調(diào)試，主要希望生成表格清晰簡潔，最終使用的是plotly庫，效果如圖3，圖中紅色字體的表頭也是程序生成的。

4、發(fā)布微頭條
并未開放open api來發(fā)布內(nèi)容，通過程序自動發(fā)布頭條有兩種方案：

1. 一開始做的是mock api的方案，模擬構(gòu)造登錄和發(fā)布微頭條API流，來實現(xiàn)自動發(fā)布。這個方案雖然調(diào)試通過，但并不穩(wěn)定，不使用。
2. Web UI自動化方案，本質(zhì)是模擬鼠標(biāo)和鍵盤操作來達(dá)到自動化發(fā)布的效果，對系統(tǒng)來說，Web UI自動化與人的操作無區(qū)別，所有理論來說，這個方案是穩(wěn)定，最終用的是這個方案。具體來說，采用pyhton selenium方案來實現(xiàn)，開發(fā)調(diào)試過程中也躺了一些坑，如微頭條的文本輸入未選中和選中兩個狀態(tài)下html element names是不一樣的，這樣選中前onClick是一個element，選中后輸入文本是另一個element。

四、后記

1. 整套程序做的是疫情數(shù)據(jù)表格自動化通報，也可以普適到各種自動化發(fā)布自媒體的場景。
2. 這是一個不錯的練手項目，如同整體方案流程圖，整套代碼流程和邏輯是比較清晰的，有一定python或開發(fā)基礎(chǔ)的同學(xué)都可以hold的住，如需源代碼，可以“橙獅科技”微信公眾號或同名頭條號私信獲取。
3. 目前自動發(fā)布是前臺打開瀏覽器操作實現(xiàn)的，后續(xù)會做到整個過程在后臺實現(xiàn)，這樣降低對運行環(huán)境依賴，適應(yīng)性會更高一些。

4. 若有收獲，就點個贊吧