做保洁网站找谁做,seo自然排名优化,二七区室内设计装修公司排名,怎样查看网站是用什么做的首先我们定义出一个点赞系统需要对外提供哪些接口#xff1a;
1.用户对特定的消息进行点赞#xff1b; 2.用户查看自己发布的某条消息点赞数量以及被哪些人赞过#xff1b; 3.用户查看自己给哪些消息点赞过#xff1b;
这里假设每条消息都有一个message_id, 每一个用户都…首先我们定义出一个点赞系统需要对外提供哪些接口
1.用户对特定的消息进行点赞 2.用户查看自己发布的某条消息点赞数量以及被哪些人赞过 3.用户查看自己给哪些消息点赞过
这里假设每条消息都有一个message_id, 每一个用户都有一个user_id 从以上三个接口我们可以大概想到需要在存储层保存哪些数据 1.消息点赞表, 形式如{message_id, user_id, timestamp ... }, 需要具备根据指定message_id 查找所有点赞人及点赞数量的能力 2.用户点赞表形式如{user_id, message_id, timestamp ... }需要具备根据user_id查找其所有点赞过的消息列表 3.点赞计数表形式如{message_id, count}
从以上几点来看如果系统的用户规模不大比如用户小于1w人如果用mysql来存储好像一张表就能搞定用message_id做主键然后在user_id上建立索引就可以很方便实现上面要求的三个接口
select * from table where message_idxxxx
select * from table where user_idxxxxx
select count(*) from table where message_idxxxx但是如果用户数量很大比如向抖音这种过亿量级单表行数量迅速膨胀并且可能存在某些消息热门短时间内大量用户点赞导致mysql挂掉一般而言mysql能够支持的tps为10的三次级别具体数值依赖与cpu 磁盘 内存性能。 很自然我们想到分库分表但是选择哪一个字段做分表列如果选message_id 进行分库分表那么如果要查询单个用户所有点赞的message, 就需要查询所有的库反之用user_id进行分那么查询指定message_id 查找所有点赞人就需要查询所有库 从另一个方面来讲上述方式构建表存在带量冗余信息一条message 被1000人点赞 那么就需要1000行来存储这主要是收到mysql中关系型数据库模式的限制。
方案二 上述方案在用户规模较大的情况下难以满足我们的需求这里在提供一种以mogondb作为核心存储的可能方案。 mogondb与mysql不同它天然支持分布式扩展并且他是无模式的下面给出存储方案 消息点赞表
{message_id:12345,count: 3user_List: [5555, 8888,9999 ....]
}用户点赞表:
{user_id:5555,message_List: [12345...]
}上面只列出核心字段其他业务字段如时间戳等可以自行扩展mogondb 可以对message_id 或者 user_id 进行索引查询很方便的满足上面提出的三个接口。
这里还可以做一些特定的限制如果一条消息被超过5000以上人点赞那么我们是否有必要记录所有点赞过的用户呢我个人觉得没有必要不会有用户会去查询全量用户列表因为假设客户端一屏幕展示20个点赞用户那么5000/20250用户需要250此滑屏幕才能看完不会有人这么干。 因此可以考虑当点赞用户超过5000后消息点赞表就只需要更新点赞数量而不用将用户加到user_List列表里了。
但是如果某条消息上瞬间请求量大还是可能冲垮mogondb特定分片从而导致服务不可用如何解决呢 这里我想到的是使用消息队列来削峰具体的架构如下图所示
https://docs.qq.com/flowchart-addon 用户点赞的流程 1.首先业务网关层这里提供身份校验、限流等通用能力 2.业务逻辑层根据message id 进行哈希写入kafka分区 3.消费者集群从kafka消费数据写入mogondb 如果是数据查询那么业务逻辑层直接请求db拿到结果就可以返回 以上就是我点赞系统的设计的一些思考。
