微博评论点赞点踩的系统，数据库是如何设计的？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1714 天前的主题，其中的信息可能已经有所发展或是发生改变。

如题，是我一直好奇的一个点。众所周知点赞系统你不能单纯通过前端限制点过赞的不能重复点，要不然刷赞分分钟的事，但是如果后端要过滤比如一个人是不是已经点过赞了这种的话，微博流量那么大，由此产生的表和对应关系的 cost 也太夸张了吧

实力是我怎么实现的呢？又能防止刷赞，数据库也不会太臃肿

数据库

cost

分分钟

19 条回复 • 2020-03-19 12:53:23 +08:00

q1angch0u

2020-03-19 02:49:41 +08:00 via iPhone

redis 啊

stabc

2020-03-19 04:00:14 +08:00

我的设计是：首先肯定是保存每个人的点赞信息的，放在比如 votes 表里。然后评论超过 3 天就禁止点赞，然后就可以定期清理 votes 里 3 天之前的数据了。

veike

2020-03-19 04:01:10 +08:00

主要减少查数据库查询，查一次可以放缓存里，服务器里的缓存+前端缓存。

防止刷赞，请求开始在 redis 中加个该动作的唯一标识，我一般用户 id+动作标识+资源 id 判断该动作是否存在，存在就是动作还没完成

成功或者失败后删除动作唯一标识

前端也限制一下

不知道还有没有其他的方法

black11black

2020-03-19 04:35:08 +08:00

@veike 大佬，动作还没完成怎么理解

elfive

2020-03-19 07:54:28 +08:00 via iPhone

每个用户维护一个用户点赞列表，存帖子 id 进去。
每个帖子维护一个点赞列表，存用户 id 进去。

conn4575

2020-03-19 07:54:29 +08:00 via Android

点赞数少的时候就 redis 记录每个点赞 ID，超过 1000 就升级为布隆过滤器

earther01

2020-03-19 08:57:39 +08:00

@conn4575 布隆过滤器的话，取消点赞怎么办？

p2pCoder

2020-03-19 09:20:17 +08:00

建议找找 feed 流设计相关文章看下，这东西很复杂，不同流量下，架构有比较大的改变，核心就在于读写机制

sanggao

2020-03-19 09:33:31 +08:00

微博 redis 内存使用得 300 多 T,还是前几年的，现在不知道多少了

lovedebug

2020-03-19 09:35:23 +08:00

推荐看设计数据密集型应用，里面有讲方案

x86

2020-03-19 10:00:03 +08:00

redis 啊，晚上 0 点清算

dianso

2020-03-19 10:01:37 +08:00 via Android

没必要数据库，缓存就行

freakxx

2020-03-19 10:13:44 +08:00

新浪微博「点赞功能」数据库如何设计的？ - 高辰飞的回答 - 知乎
https://www.zhihu.com/question/63947513/answer/224529861

附的链接也可以看看

之前还看过一个 blog 有大概说实现方案，但没看懂就略过了。

passerbytiny

2020-03-19 10:29:19 +08:00

提供一个思路（仅仅是思路，不是可行方案）：被点赞方只处理“点赞数”，并且还读写分离（简单的方案就是隔一段时间才根据点赞 /取消事件集中计算最新的点赞数），点赞方（用户）正常处理完整的点赞关系。你只要隔离了被点赞方和点赞方，那么后者是低频行为就无需特殊照顾了，前者也只需要对一个字段（而非关联关系）做高频特殊照固。而只要跳出了 CRUD 的思维，略微懂点领域模型或事件驱动，这个隔离，是不难做的。