BBSSDK數據同步存儲原理

BBSSDK是一套能快速實現discuz論壇移動化的一套解決方案。今天主要講講這個產品的數據同步存儲原理。

主要從這三個方面：一.存儲機制；二.版本控制；三.同步原理。

一.存儲機制

首先要理清我們有哪些內容，在對內容進行各種不同程度的存儲和持久化。

根據內容類型我們分為：文本和多媒體。主要同步的內容就是文本內容，多媒體內容基本通過URL的形式進行訪問，存儲方式可以在用戶的伺服器端和我們提供的（或第三方提供的）對象存儲系統。

文本內容又拆分為不同的等級：高頻內容，低頻內容，冷內容。

高頻內容我們根據業務也進行進一步的拆分，核心的業務比如論壇版塊、用戶組、最新熱帖等。進行主要的內容同步。而一些不是核心業務的內容比如家園、博客就沒有在我們項目的同步規劃內。

低頻內容包括有用戶，陳貼等，通過非同步激活的方式進行數據的同步。

冷內容比如殭屍用戶，歷史廣告數據等，這部分內容就在用戶的論壇上而不參與BBSSDK線上邏輯。

理清了需要存儲的數據，就需要對各種等級數據進行存儲。在存儲方案中有兩種選擇nosql和RDBS，考慮到沒有複雜的事務性操作和讀寫效率，最終選擇了mongodb作為線上數據存儲服務。mongodb在熱數據的查詢和raw的快速寫入，由於其在數據讀寫方面由於充分使用速度快的內存而佔據優勢。一些更高頻內容（比如板塊列表等）又在redis裡面進行持久化，方便高並發的同時減少磁碟的IO。

平台和論壇的內容關係

二.版本控制

怎麼去處理內容？當前內容是否最新？需要我們去維護一套內容的版本信息。在用戶伺服器需要一套，這樣可以通知或提交最新的內容；平台也需要一套，知道這些通知或內容是否值得去獲取和存儲。

由於版本控制要保持內容的最終一致性，這就必須要有一個原子時鐘。這個時鐘就以用戶伺服器里的DB時間為標準。

用戶伺服器根據DB的觸發器記錄狀態緩存在版本信息表裡，後提交（或平台發送心跳獲取）版本信息通知平台來獲取數據。平台根據請求體或返回體裡面的時間，或每次成功返回的頭信息去維護平台自己的版本信息庫。

三.同步原理

同步原理分三個部分：1.傳輸方式，2.時效性，3.安全性

1.傳輸方式，選擇了http(s)的方式進行數據的推拉同步，首先http的兼容性高，只要是discuz的論壇搭建在虛擬空間也支持，不需要額外的環境配置；二是由於http是TCP協議穩定性好，缺點也就是耗費網路IO增加用時。

2.時效性，涉及到網路同步總會有延遲，怎麼做到用戶無感知延遲的內容同步？用戶的網站千差萬別，有些時候總會遇到不可避免的因素，導致獲取消息的不及時，怎麼解決最終內容的一致性？主要從三個方面進行：a.初始化方式；b.通知隊列的消耗方式；c.心跳輪詢機制。

a.初始化方式

在論壇插件安裝成功後，會發送一個通知給平台。平台根據隊列開啟線程發起初始化。

初始化由於內容上我們進行了各種顆粒的切割，所以這個初始化不是整個論壇的全量數據同步。而是獲取必要的配置信息，再加上高頻的熱內容同步在平台上。類似CDN的初始化流程。

b.通知隊列的消耗方式

在通知隊列中的每條通知需要描述當前任務的屬性：包含權重，任務細節等。當消費者消耗通知隊列的時候，去判斷當前任務在版本描述中是否值得去獲取，再通過http請求去獲取內容，如果遇到不可避免因素導致內容獲取失敗，就需要對當前任務進行指數型遞增下一次的執行時間。這樣在不影響健康論壇運行的同時保持問題論壇內容的一致性。

如果一個論壇一直在發送通知而獲取不到內容。在一個時間段達到一定數量級，我們可以判斷當前論壇已經假死。為保證平台資源的合理利用，對問題論壇進行臨時關閉，拉高指數重試，這樣如果問題論壇還需要平台提供服務就需要再次提交初始化請求。

c.心跳輪詢機制

在定長的時間內，平台會發送請求去目標論壇進行最新版本信息的獲取。如果目標論壇沒有返回。在多次無效的情況下，平台會判定目標網站已經關閉服務不再發起心跳輪詢。

如果論壇用戶是卸載了插件應用，就需要重新安裝論壇插件，再次初始化服務。

如果論壇用戶只是臨時關閉服務或論壇出現短暫問題，插件在前端埋下的鉤子會在定時內會通過前端用戶觸發發送平台伺服器請求，去喚醒論壇服務，後激活心跳輪詢保持服務的正常運行。

3.安全性，a.通信的安全：考慮到信息資產的安全所有的交互都是帶簽名驗證的。這種驗證方式使用的是請求體加秘鑰的hash演算法。秘鑰通過mob管理後台進行獲取，配置在插件端;b.內容存儲安全：平台使用mongdb副本集的方式進行內容的存儲。

數據流向架構設計

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！