日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢(xún)
選擇下列產(chǎn)品馬上在線(xiàn)溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案
點(diǎn)贊功能，用MySQL還是Redis

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

公司專(zhuān)注于為企業(yè)提供網(wǎng)站制作、成都網(wǎng)站制作、微信公眾號(hào)開(kāi)發(fā)、商城網(wǎng)站開(kāi)發(fā)，重慶小程序開(kāi)發(fā)公司，軟件按需網(wǎng)站設(shè)計(jì)等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗(yàn)，我們會(huì)仔細(xì)了解各客戶(hù)的需求而做出多方面的分析、設(shè)計(jì)、整合，為客戶(hù)設(shè)計(jì)出具風(fēng)格及創(chuàng)意性的商業(yè)解決方案，成都創(chuàng)新互聯(lián)公司更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。

今天我們就來(lái)聊聊 點(diǎn)贊、評(píng)論、收藏等這些場(chǎng)景的db數(shù)據(jù)庫(kù)設(shè)計(jì)問(wèn)題，

1. 我們先來(lái)看看場(chǎng)景的需求：

  • 顯示點(diǎn)贊數(shù)量
  • 判斷用戶(hù)是否點(diǎn)過(guò)贊，用于去重，必須的判斷
  • 顯示個(gè)人點(diǎn)贊列表，一般在用戶(hù)中心
  • 顯示文章點(diǎn)贊列表

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

頭條的點(diǎn)贊

微博的點(diǎn)贊

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

2.1 mysql方案

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

 
 
 
    
  
  
  
  1. 文章表
    2. 
  
  
  
  2. 
  
  
  
  3. create table post {
    4. 
  
  
  
  4. 
  
  
  
  5.         post_id int(11) NOT NULL AUTO_INCREMENT,
    6. 
  
  
  
  6. 
  
  
  
  7.         ......
    8. 
  
  
  
  8. 
  
  
  
  9.         star_num int(11) COMMENT '點(diǎn)贊數(shù)量'
    10. 
  
  
  
  10. 
  
  
  
  11. }
    12. 
  
  
  
  12. 
  
  
  
  13. 用戶(hù)表
    14. 
  
  
  
  14. 
  
  
  
  15. create table user {
    16. 
  
  
  
  16. 
  
  
  
  17.         user_id int(11) NOT NULL AUTO_INCREMENT,
    18. 
  
  
  
  18. 
  
  
  
  19.         ......
    20. 
  
  
  
  20. 
  
  
  
  21.         star_num int(11) COMMENT '點(diǎn)贊數(shù)量'
    22. 
  
  
  
  22. 
  
  
  
  23. }
    24. 
  
  
  
  24. 
  
  
  
  25. 點(diǎn)贊表
    26. 
  
  
  
  26. 
  
  
  
  27. create table star {
    28. 
  
  
  
  28. 
  
  
  
  29.         id int(11) NOT NULL AUTO_INCREMENT,
    30. 
  
  
  
  30. 
  
  
  
  31.         post_id,
    32. 
  
  
  
  32. 
  
  
  
  33.         user_id,
    34. 
  
  
  
  34. 
  
  
  
  35.         ......
    36. 
  
  
  
  36. 
  
  
  
  37. }
    38.

常用的查詢(xún)：

 
 
 
    
  
  
  
  1. 查詢(xún)用戶(hù)點(diǎn)贊過(guò)的文章 select post_id from star where user_id=? 
    2. 
  
  
  
  2. 查詢(xún)文章的點(diǎn)贊用戶(hù) select user_id from star where post_id=?
    3.

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

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

缺點(diǎn)：

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

2.2 Redis方案

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

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

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

cache

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

下面說(shuō)下redis作為storage的方案：

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

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

以文章id為key

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

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

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

這個(gè)需求可以使用場(chǎng)景b的數(shù)據(jù)來(lái)實(shí)現(xiàn)。

用戶(hù)中心點(diǎn)贊列表

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

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

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

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

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

帖子點(diǎn)贊列表

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

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

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

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

hash

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

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

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

查找一個(gè)用戶(hù)id是在hash還是set?存在不確定性

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

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

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

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

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

寫(xiě)在最后：把問(wèn)題寫(xiě)明白，真不是一件容易的事情，請(qǐng)大家多多關(guān)注，留言，謝謝!

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


名稱(chēng)欄目：點(diǎn)贊功能，用MySQL還是Redis
文章URL：http://www.5511xx.com/article/dppisge.html