你真的會寫留言功能嗎？

1、寫在前面

最近在寫博客的留言功能，由此引起的思考，留言通常分爲簡單留言和蓋樓留言

簡單留言：一問一答，對於沒有大量用戶評論或者評論不是核心功能的app來講就夠用了。

蓋樓留言：有着大量的用戶評論，那麼設計「蓋樓」的效果仍是可取的，這樣能幫助用戶找到該條評論或者回復的上下文情景。可是根據「蓋樓」的顯示效果不一樣，設計上也是有很大的差異的。

如何設計一個簡潔優雅的蓋樓留言呢？下面讓咱們帶着這個問題進入今天的課題

2、蓋樓設計

數據庫結構模型以下：

create table ArticleComment(

@ID int, –標識列

@PID int, –回覆ID

@ArticleID int, –文章ID

@Content ntext, –內容

@IP nvarchar(50), –IP

@AddDate DateTime –留言時間

)

方法一：

複製前面回覆，附加上新的，一同放入 Content 中。Content 要足夠大，足以放下全部的樓層。

這樣作有兩個缺點：

1. 佔用空間大

2. 前面的回覆後修改後，後面的很差更新

方法二：

遞歸，須要程序查詢所需和前端作必要的處理合並就能夠達到效果。這裏又引出另一個問題「當留言回覆的層數過多的時候，好比1萬條蓋樓，會極大拖慢系統的加載時間。」

一種解決方案：

1.文章留言分頁加載

2.每一個父ID下面只能掛在留言級數須要控制，多餘的下一頁顯示。頁面由用戶觸發

3、蓋樓總結

上面只是簡單列舉目前市面的上幾種留言實現方式，若是你的系統天天都會有成千上萬條評論，那麼單表的設計確定是不行，優化的方式也有不少。

• 分庫分表。分庫分表是最爲經常使用也最有效的優化方式，建議按照主題來分庫分表。這樣同一個主題下面的評論就會落到同一張表裏，避免了跨表查詢。
• 適當的數據冗餘。若是你須要顯示評論人的相關信息，那麼在插入評論時就把這些信息寫入評論表中，避免屢次查詢。實際上，若是是紀錄數據，均可以冗餘對應的數據信息，由於它們的數據的實時行和一致性要求並不高，用戶不會由於評論中的頭像沒更新而撕了你，哈哈。
• 若是pd要求你能給評論點贊，得注意點贊冪等性，同一個用戶只能點一次贊或者取消本身的點贊。由於從冪等性的要求來講，每一個贊都是一條記錄。評論的贊數若是都從點贊表中統計得出，那麼性能開銷會十分巨大，並且點贊如此輕量級的一個操做必定會加重點贊表的競爭操做。因此建議直接在評論表中添加一個like_count的計數器，維護該冗餘該字段。減輕服務器聚合數據的壓力，熱門評論加緩存。相似於網易新聞的熱門評論，讀取頻度很是高，能夠專門開接口給客戶端，同時該接口作緩存。