朋友圈設計

朋友圈設計

在社交軟件中,朋友圈(社交圈)的功能逐漸出如今各個項目經理的案板上,本文將從技術的角度介紹,如何實現一個相似微信的朋友圈功能。數據庫

朋友圈的功能點

首先看看,朋友圈要實現的基本功能點,有請截圖:緩存

朋友圈截圖

能夠發現主要包含:服務器

  1. 主題內容,具備各類類型的內容,如文本,圖片,小視頻,軟文...微信

  2. 點贊信息,按照時間排序的用戶信息網絡

  3. 評論信息,按照時間排序的文本評論,或許之後會衍生出圖片評論。分佈式

  4. 離線同步,不知道你們有沒有發現,不管是發佈主題,發佈點贊,發佈評論,都支持離線同步的功能。在斷網的狀況下,依舊能夠進行發佈說說。這個功能極大的優化了用戶體驗。優化

  5. 離線緩存,在斷網的狀況下,依舊能查看過去的說說內容。.net

  6. 增量更新,在使用朋友圈的過程當中,對比同類型的APP,微信朋友圈的流量消耗是很是小的。線程

  7. 及時通知,包括了好友發表的說說顯示小紅點,他人回覆的評論和點贊消息,都能及時的通知用戶。設計

能夠發現,這些4-7這些都是在以前QQ空間中沒有發現的優勢,增強了用戶體驗,以及適應移動環境下,低流量,網絡不穩定的特色。

兼容性設計

能夠發現,微信朋友圈在不斷的升級過程當中,不斷引入了新的主題類型,而這主要是依賴良好的兼容性設計。具體能夠參考App兼容性設計這篇文章。我的猜想就是使用TYPE字段進行向下兼容。

離線同步

離線同步的功能可謂是爲移動環境量身定作的功能,極大的增強了用戶體驗。可是想要比較完美的實現這個功能,也是很是考驗軟件開發人員的。離線同步,基本實現的原理圖:

離線同步過程圖

其基本方法就是日誌先行原則:把全部的操做,先寫入本地數據庫中,而後後臺不斷的進行同步到服務器。日誌先行原則在分佈式系統設計中,會常常被用到,它是分佈式事務補償(RETRY)的一種通用方法。

離線緩存

經過離線緩存,能夠作到在斷網的狀況下,依舊能夠查看朋友圈,而且,能夠採用增量更新的方式,在刷朋友圈的時候進行低流量的同步服務器的說說到本地。

增量更新

增量更新通俗的講就是把舊的數據和新的變化數據合併,造成最新的數據。

增量更新實現的兩種方式:

  1. 採用日誌版本號:則每次提交都會生成一個版本號,更新的時候,客戶端拿着Old Version去服務器對比,服務器將Newest Version返回給客戶端。而後進行for 循環升級便可。這種方式,比較適合須要追蹤每次變化的業務場景,如SVN,GIT。

  2. 採用最後修改時間:對增量更新的目標,添加最後修改時間的屬性(MT),客戶端在更新的時候,拿着本地的MT和服務器的MT對比,而後判斷目標是否須要更新便可。這種方式,就比較適合不須要追蹤變化過程的場景,如朋友圈。可是須要注意,這個顆粒度須要選擇合適。

增量更新的顆粒度:

顆粒度值得是增量更新的目標單位,好比說,一個文件,一個數據庫,一條說說。選擇合適的顆粒度是很是重要的。顆粒度太大會致使增量更新沒有意義,過小會致使增量更新須要考慮的因素過多。 而在朋友圈中,選擇顆粒度就是一條說說了。

要點設計

結合離線同步,離線緩存,以及增量更新中的各個要點,咱們設計出以下的基本流程結構:

朋友圈基本設計

發佈

在發佈階段,須要先把發佈的內容(說說,點贊,評論)寫入操做日誌中,而後Notify SYNC 線程進行同步。

發佈遇到的問題和解決方法:

  1. 發佈-Request異常:只須要等待網絡恢復正常,再次發佈便可。

  2. 發佈-Resonse異常:此時服務器已經寫入了發佈的具體內容,而APP端不知道,根據BASE思想,採用最終一致的方法,咱們採用UUID做爲內容的ID,只須要網絡恢復正常的時候RETRY,服務器發現該ID的內容已經存在,則直接返回OK便可。

讀取數據

而讀取數據階段,咱們須要考慮合併日誌和班級圈緩存,造成最終的數據。由於咱們設計中,緩存數據就是合併了日誌操做的緩存,因此只用直接讀取就能夠了。

刷朋友圈

在刷朋友圈的時候有兩種狀況:

  1. 獲取最新的說說數據

  2. 獲取某一條說說後面的固定條數的說說

此時,咱們能夠利用好離線緩存數據,提取離線緩存的ID+CT(建立時間)+MT(最後修改時間)進行查詢,服務器進行查詢後,若是發現服務器的MT時間大於APP的緩存,則返回增量更新的內容,且大體有三種狀態:

  1. CREATE:APP端沒有緩存中,本條數據,須要將本條說說完整的返回給APP,而後持久化
  2. UPDATE:本條說說具備更新,只須要返回點贊+評論列表+MT便可,由於主題部門基本上是不會變化的。而後更新MT時間。
  3. DELETE:本條說說已經被刪除,APP端須要刪除本條說說的緩存。

同步的時候,建議採用指示緩存數據信息數量=須要展現的數據數量+5 ,避免由於DELETE,從而致使服務器返回的數據(CREATE)中包含了APP端已經緩存的數據。

反穿

從服務器過來的數據,須要反穿過操做日誌,才能造成正確的顯示數據。反穿圖解:

反穿圖解

反穿的基本要求就是須要保證同步過來的數據和操做日誌保持合併後,能保持最終一致。

推送

對於一些他人評論的消息,或者點贊信息,須要及時的推送給用戶,因此咱們還須要設計推送協議,將一些及時消息推送給用戶。

總結

在移動環境中,網絡異常和省流量是很是重要的,一個好的社交圈設計,須要考慮到這兩點。而微信朋友圈無異於創造了先河。

相關文章
相關標籤/搜索