一、寫在前面

最近在寫博客的留言功能，由此引發的思考，留言一般分為簡單留言和蓋樓留言

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

蓋樓留言：有著大量的用戶評論，那么設計“蓋樓”的效果還是可取的，這樣能幫助用戶找到該條評論或者回復的上下文情景。但是根據“蓋樓”的顯示效果不同，設計上也是有很大的差別的。

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

數據庫結構模型如下：

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下面只能掛在留言級數需要控制，多余的下一頁顯示。頁面由用戶觸發

三、蓋樓總結

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

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

原文發布時間為：2018-11-15

本文作者：HARRIES

本文來自云棲社區合作伙伴“Java雜記”，了解相關信息可以關注“Java雜記”。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的你真的会写留言功能吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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