點(diǎn)贊功能是目前app開發(fā)基本的功能

今天我們就來聊聊 點(diǎn)贊、評論、收藏等這些場景的db數(shù)據(jù)庫設(shè)計問題，

1. 我們先來看看場景的需求：

• 顯示點(diǎn)贊數(shù)量

• 判斷用戶是否點(diǎn)過贊，用于去重，必須的判斷

• 顯示個人點(diǎn)贊列表，一般在用戶中心

• 顯示文章點(diǎn)贊列表

我們先看一下頭條和微博的例子

這兩個都是具有頂級流量的，后端肯定有復(fù)雜的架構(gòu)，我們今天只談大眾化的方案。

2.1 mysql方案

mysql方案, 隨著nosql的流行，大數(shù)據(jù)的持續(xù)熱點(diǎn)，但是mysql仍然不可替代，對于大多數(shù)的中小項目，低于千萬級的數(shù)據(jù)量，采用mysql分表+cache，是完全可以勝任的，而且穩(wěn)定性是其他方案無可比擬的：

-- 文章表

create table post {

        post_id int(11) NOT NULL AUTO_INCREMENT,

        ......

        star_num int(11) COMMENT '點(diǎn)贊數(shù)量'

}

-- 用戶表

create table user {

        user_id int(11) NOT NULL AUTO_INCREMENT,

        ......

        star_num int(11) COMMENT '點(diǎn)贊數(shù)量'

}

-- 點(diǎn)贊表

create table star {

        id int(11) NOT NULL AUTO_INCREMENT,

        post_id,

        user_id,

        ......

}

常用的查詢：

查詢用戶點(diǎn)贊過的文章 select post_id from star where user_id=?

查詢文章的點(diǎn)贊用戶 select user_id from star where post_id=?

點(diǎn)贊數(shù)量可以通過定時異步統(tǒng)計更新到post和user 表中。

數(shù)據(jù)量不大的時候，這種設(shè)計基本可以滿足需求了，

缺點(diǎn)：

數(shù)據(jù)量大時，一張表在查詢時壓力巨大，需要分表，而不論用post_id還是user_id來hash分表都與我們的需求有沖突，唯一的辦法就是做兩個表冗余。這增加了存儲空間和維護(hù)工作量，還可能有一致性問題。

2.2 redis方案

當(dāng)數(shù)據(jù)量達(dá)到上億的量，上cache是必經(jīng)的階段，由于點(diǎn)贊這種動作很隨意，很多人看到大拇指就想點(diǎn)，所以數(shù)據(jù)量增長很快，數(shù)據(jù)規(guī)模上來后，對mysql讀寫都有很大的壓力，這時就要考慮memcache、redis進(jìn)行存儲或cache。

為什么一般都選擇redis， redis作為流行的nosql，有著豐富的數(shù)據(jù)類型，可以適應(yīng)多個場景的需求。

采用redis有兩種用途，一種是storage，一種是純cache，需要+mysql一起。純cache就是把數(shù)據(jù)從mysql先寫入redis，用戶先讀cache，miss后再拉取MySQL，同時cache做同步。

多數(shù)場景二者是同時使用的，并不沖突。

下面說下redis作為storage的方案：

場景a ：顯示點(diǎn)贊數(shù)量

在點(diǎn)贊的地方，只是顯示一個點(diǎn)贊數(shù)量，能區(qū)分用戶是否點(diǎn)贊過，一般用戶不關(guān)心這個列表，這個場景只要一個數(shù)字就可以了，當(dāng)數(shù)量比較大時，一般顯示為"7k" ,"10W" 這樣。

以文章id為key

//以文章id=888為例 
127.0.0.1:6379[2]> set star:tid:888 898 //設(shè)置點(diǎn)贊數(shù)量 
OK 
127.0.0.1:6379[2]> incr star:tid:888 //實現(xiàn)數(shù)量自增 (integer) 
899

場景b：點(diǎn)贊去重，避免重復(fù)點(diǎn)贊

要實現(xiàn)這個需求，必須有文章點(diǎn)贊的uid列表，以uid為key場景c：一般在用戶中心，可以看到用戶自己的點(diǎn)贊列表

這個需求可以使用場景b的數(shù)據(jù)來實現(xiàn)。

場景d：文章的點(diǎn)贊列表，類似場景b，以文章id為key

//以文章id=888為例 
127.0.0.1:6379[2]> sadd star:list:tid:888 123 456 789  //點(diǎn)贊uid列表 (integer) 
3 
127.0.0.1:6379[2]> sismember star:list:tid:888 456  //判斷是否點(diǎn)贊 (integer) 
1

點(diǎn)贊的地方，如果點(diǎn)贊過顯示紅色，沒有則顯示黑白色，

今日頭條是沒有地方可以看到點(diǎn)贊列表的，而微博點(diǎn)進(jìn)去，詳情頁可以看到點(diǎn)贊列表，但是只會顯示最近的幾十條，沒有分頁顯示。

如下圖，我選了一條熱點(diǎn)，擁有眾多粉絲的“豬豬”

可能有人覺得，點(diǎn)贊列表沒人關(guān)心，存儲又會浪費(fèi)大量資源，不如不存！但是，這個數(shù)據(jù)是必須要有的。兩點(diǎn)：

• 去重。點(diǎn)贊數(shù)可以不精確，但去重必須是精確的，

• 另外一個社交產(chǎn)品，用戶行為的一點(diǎn)一滴都需要記錄，對于后續(xù)的用戶行為分析和數(shù)據(jù)挖掘都是有意義的。

上面使用string存儲的用戶點(diǎn)贊數(shù)量，除了string，還可以用hash來存儲，對文章id分塊，每100個存到一個hash，分別存入hash table，每個文章id為hash的一個key，value存儲點(diǎn)贊的用戶id，如果點(diǎn)贊用戶很多，避免id過多產(chǎn)生性能問題，可以單列出來，用sorted set結(jié)構(gòu)保存，熱點(diǎn)的畢竟是少數(shù)。

方案優(yōu)缺點(diǎn)比對

hash：使用了更少的全局key ，節(jié)省了內(nèi)存空間；但是也帶來了問題

如何根據(jù)文章id路由到對應(yīng)的hash？

查找一個用戶id是在hash還是set？存在不確定性

使用hash雖然節(jié)省了空間，但增加了復(fù)雜度，如何選擇就看個人需求了。

除此之外，你還有其他的方法嗎？

3. 數(shù)據(jù)一致性

redis作為storage使用時，一定要做好數(shù)據(jù)的持久化，必須開啟 rdb 和 aof，這會導(dǎo)致業(yè)務(wù)只能使用一半的機(jī)器內(nèi)存，所以要做好容量的監(jiān)控，及時擴(kuò)容。

另外只要有數(shù)據(jù)copy，就會有一致性問題，這就是另外一個很重要的話題了。以后有時間再細(xì)聊吧！

寫在最后：把問題寫明白，真不是一件容易的事情，請大家多多關(guān)注，留言，謝謝！

前幾天寫的一篇文章，受到眾多同行的熱情回復(fù)，能和眾多同行一起交流，深感榮幸！對于工程類問題，沒有標(biāo)準(zhǔn)的方案，一千個人有一千個方案，哪個最適合你只有你自己知道！期待你更好的思路和方法。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝