一、寫在前面

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

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

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

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

數(shù)據(jù)庫結(jié)構(gòu)模型如下：

create table ArticleComment(

@ID int, –標識列

@PID int, –回復(fù)ID

@ArticleID int, –文章ID

@Content ntext, –內(nèi)容

@IP nvarchar(50), –IP

@AddDate DateTime –留言時間

)

方法一：

復(fù)制前面回復(fù)，附加上新的，一同放入 Content 中。Content 要足夠大，足以放下所有的樓層。

這樣做有兩個缺點：

1. 占用空間大

2. 前面的回復(fù)后修改后，后面的不好更新

方法二：

遞歸，需要程序查詢所需和前端做必要的處理合并就可以達到效果。這里又引出另外一個問題“當留言回復(fù)的層數(shù)過多的時候，比如1萬條蓋樓，會極大拖慢系統(tǒng)的加載時間。”

一種解決方案：

1.文章留言分頁加載

2.每個父ID下面只能掛在留言級數(shù)需要控制，多余的下一頁顯示。頁面由用戶觸發(fā)

三、蓋樓總結(jié)

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

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

原文發(fā)布時間為：2018-11-15

本文作者：HARRIES

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。