隨著社交網(wǎng)絡(luò)的蓬勃發(fā)展，點贊功能逐漸成為了一個網(wǎng)站中不可或缺的功能。因為點贊功能不僅可以讓用戶更直觀地了解自己的視頻、文章等內(nèi)容被多少人認(rèn)可，而且也提升了用戶互動體驗感。下面我們來聊聊通用的點贊系統(tǒng)設(shè)計的方案。

1、點贊系統(tǒng)的數(shù)據(jù)表設(shè)計

    在設(shè)計數(shù)據(jù)表的時候我們需要知道點贊系統(tǒng)需要完成的基礎(chǔ)功能有哪些，點贊系統(tǒng)通常需要實現(xiàn)以下功能：

（1）用戶可以點贊一個視頻、文章、評論等內(nèi)容

（2）用戶可以查看一個視頻、文章、評論等內(nèi)容的點贊數(shù)

（3）用戶可以取消對視頻、文章、評論等內(nèi)容的點贊

    針對如上所示的功能，我們可以設(shè)計一張點贊記錄表和點贊計數(shù)表來記錄數(shù)據(jù)，如下是兩張表的字段設(shè)計：

圖片

圖片

    點贊計數(shù)表中記錄了稿件（視頻、文章、評論等等）被點贊和取消點贊的總數(shù)，用作總的點贊數(shù)據(jù)展示；點贊記錄表用于記錄哪些用戶在何時給哪個稿件點贊或取消點贊。

2、系統(tǒng)設(shè)計

2.1 點贊數(shù)據(jù)寫入的設(shè)計方案

圖片

    點贊系統(tǒng)一般流量是比較大的，特別是在某個稿件突然成為熱點之后，那么流量就會突增上來，為了應(yīng)對大流量，我們在設(shè)計點贊系統(tǒng)的時候采用MQ來做削峰處理，整個點贊數(shù)據(jù)寫入的流程如下所示：

（1）用戶發(fā)送來點贊請求，經(jīng)過Nginx和網(wǎng)關(guān)轉(zhuǎn)發(fā)到點贊服務(wù)上，點贊服務(wù)組裝必要的數(shù)據(jù)（稿件的id、稿件用戶id等數(shù)據(jù)）發(fā)送MQ消息，并發(fā)響應(yīng)客戶端寫入點贊數(shù)據(jù)成功。

（2）點贊服務(wù)消費MQ消息，首先要保存點贊的數(shù)據(jù)，在保存點贊數(shù)據(jù)的時候需要做一些邏輯檢驗工作，如下的流程圖所示：

圖片

    首先根據(jù)用戶的id和點贊的稿件id查詢數(shù)據(jù)庫獲取用戶的點贊記錄數(shù)據(jù)，根據(jù)查詢的結(jié)果分如下的情況分析：

（a）如果沒有查詢到用戶的點贊記錄數(shù)據(jù)，那么直接保存用戶的點贊記錄到記錄表中，將點贊計數(shù)表中的總的點贊數(shù)量加1。

（b）如果已經(jīng)存在了用戶的點贊記錄，那么就需要根據(jù)點贊的時間和點贊的動作進一步的檢查

    （b1）數(shù)據(jù)表中的點贊時間 > MQ中用戶的點贊時間，說明可能存在重復(fù)的點贊，此時我們這表MQ消息直接丟棄。

    （b2）數(shù)據(jù)表中的點贊時間 < MQ中用戶的點贊時間，比較數(shù)據(jù)庫中當(dāng)前的用戶點贊狀態(tài)是否為點贊，如果是點贊狀態(tài)那么當(dāng)前的MQ也不消費了，如果是數(shù)據(jù)庫中狀態(tài)是取消狀態(tài)，那么MQ消息我們就需要消費，此時修改記錄表的數(shù)據(jù)狀態(tài)為點贊狀態(tài)、點贊計數(shù)表中當(dāng)前的稿件的點贊數(shù)量加1。

（3）點贊的數(shù)據(jù)寫入緩存中從而減輕數(shù)據(jù)庫的壓力，點贊記錄和點贊計數(shù)表的設(shè)計如下所示：

圖片

    在redis中稿件的點贊總數(shù)可以采用String類型的數(shù)據(jù)結(jié)構(gòu)來緩存，點贊記錄數(shù)據(jù)采用Zset的數(shù)據(jù)格式來存緩存數(shù)據(jù)，這里需要給redis設(shè)置適當(dāng)?shù)倪^期時間。

（4）數(shù)據(jù)庫的設(shè)計采用讀寫分離的架構(gòu)，使用canal來同步數(shù)據(jù)到從庫中，所有的寫請求都打到主庫上，所有的讀請求都轉(zhuǎn)發(fā)到從庫上。

（5）為了保證數(shù)據(jù)的一致性，我們采用定時任務(wù)定期從數(shù)據(jù)庫中同步數(shù)據(jù)到redis上，這樣即使是redis在某個時間中寫失敗了，我們通過定時任務(wù)的方式將數(shù)據(jù)補償?shù)絩edis中。

    取消的點贊數(shù)據(jù)的寫入流程也是一樣設(shè)計的，只是最終邏輯是要點贊計數(shù)表中點贊的數(shù)量減1，取消點贊的數(shù)量加1的，還要在點贊記錄表中更新或者添加用戶取消點贊的記錄，所以取消點贊的這里就不在贅述。

2.2 用戶讀取點贊的數(shù)據(jù)

圖片

    當(dāng)點贊數(shù)據(jù)成功的寫入緩存和數(shù)據(jù)庫之后，用戶讀取點贊數(shù)據(jù)的流程如下：

（1）讀請求轉(zhuǎn)發(fā)到點贊服務(wù)上之后，點贊服務(wù)優(yōu)先查詢redis中是否存在數(shù)據(jù)，如果有數(shù)據(jù)的情況下，直接響應(yīng)數(shù)據(jù)給客戶端。

（2）如果redis中無點贊數(shù)據(jù)，那么此時就需要到數(shù)據(jù)庫中查詢數(shù)據(jù)，此時讀取數(shù)據(jù)庫的時候需要添加鎖，防止短時間內(nèi)由于緩存失效等原因造成大量的請求直接請求數(shù)據(jù)庫從而導(dǎo)致數(shù)據(jù)庫崩潰的問題。數(shù)據(jù)庫上查詢的數(shù)據(jù)要緩存一份到redis中。

總結(jié)：

（1）點贊系統(tǒng)本文介紹的是一種通過MQ+主從架構(gòu)+redis的設(shè)計方案來應(yīng)對大流量

（2）高并發(fā)下點贊系統(tǒng)的redis緩存推薦使用更新的方案，因為高并發(fā)如果頻繁的刪除緩存就會導(dǎo)致緩存的命中率下降，那么就發(fā)揮不了緩存的作用

（3）主從架構(gòu)中，主從的通過是通過canal來同步的，canal也是依賴與主庫的binlog，如果主庫由于系統(tǒng)的壓力較大生成binlog速度慢了，就可能會發(fā)生從庫和redis之間的數(shù)據(jù)不一致性，此時定時任務(wù)可以做數(shù)據(jù)補償，修復(fù)從庫和redis之間的數(shù)據(jù)不一致性。