功能需求

• 發布動態：類似朋友圈的功能，支持圖片、文字、視頻。
• 讀取動態：支持推薦、最新、最熱等欄目。
• 刪除動態：支持發布者刪除，運營刪除（包括硬刪除和軟刪除）。
• 審核動態：需要有正常、審核中、封禁中等。
• 動態送禮、點贊：支持給某條動態送禮、點贊。并且需要給發布者發消息。并且需要有消息列表，可以刪除和一鍵清空。
• 動態運營：運營可以置頂、推薦某個動態，還可以以運營身份發布官方動態。

需求分析和初步設計

考慮到發布動態的人群是主播，所以量不會很大，表的設計不用分表。

動態頁面的訪問是很頻繁的，所以在主頁面如果有多張圖則使用縮略圖，否則使用原圖，視頻顯示第一幀，剩下的交給CDN。

接口讀取的時候根據需求拉取動態ID，然后將每條動態的元數據緩存，加快接口速度。

送禮和點贊，要考慮并發和效率，將發消息異步到隊列慢慢處理。

發消息方面，提供一個接口，在客戶端第一次進入動態頁時請求，獲取是否有最新消息，后面則由客戶端監聽消息，來繪制新消息UI。

數據庫設計

具體細節就不贅述了，大致有以下幾張表：

值得注意的幾點：

• 點贊數和禮物數記錄在主表，不要sum流水表。（減慢寫，加快讀）
• 所有表添加is_delete，表示軟刪除，涉及違規的才采用真刪除，方便運營還原。

代碼設計

總體來說這個功能是比較簡單的，只是一個上傳加查詢的過程。

需要注意的：

• 將動態采用元數據緩存起來，一條動態一個，如果動態有修改直接更新該緩存，按照業務，一般設置3-7天過期就好了。
• 首頁排序提前用command命令計算好，不同的頁面直接獲取排好序的動態Id，然后點查緩存。主頁可以不用緩存，只是全部拿緩存的過程。（整個返回值套緩存，第一是占redis內存，第二是拿全部出來再解析和直接點查效率差不多，第三是直接點查實時性更好。）
• 一旦后臺有刪除、封禁操作，將某個動態的緩存刪掉就好了，當讀不到緩存生成的時候判斷is_delete即可。（不用直接執行command計算命令，第一是時間可能很長，第二是有些算法是根據時間來的，就是需要定期執行。）
• 如果點贊的量過大，可以考慮加消息隊列，但是可能會存在ABA的問題。（點贊數忽上忽下）

最后

整體的設計大致就是這樣了，如果有問題歡迎評論或者私信我哦。我們下期再見。

總結

以上是生活随笔為你收集整理的项目实战：动态系统的设计（类似朋友圈）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。