5154-高并发下后台数据库点赞功能该如何设计实现？

在当今的互联网应用中,“点赞”已成为一种基础且核心的用户交互功能，无论是社交媒体、内容平台还是电商网站，点赞系统都扮演着连接用户与内容、传递情感反馈的关键角色，要实现一个稳定、高效的点赞功能，其核心在于后台数据库的精心设计，一个糟糕的设计不仅会影响用户体验，还可能在数据量激增时给系统带来灾难性的性能瓶颈，本文将深入探讨后台数据库中点赞功能的设计思路、主流方案及其优缺点，并针对高并发场景提出优化策略。

高并发下后台数据库点赞功能该如何设计实现？

核心设计思路

在设计点赞系统之前,我们必须明确几个核心需求：要能准确记录哪个用户对哪个对象（如文章、评论、视频）进行了点赞；要能快速查询某个对象的总点赞数；要能快速判断某个用户是否已经对某个对象点过赞，以防止重复点赞；系统需要具备良好的扩展性，以应对未来数据量的增长，围绕这些需求，衍生出了几种主流的数据库设计方案。

独立的点赞关系表

这是最经典、最通用的一种设计方案，其核心思想是创建一张独立的“点赞关系表”，专门用于存储用户与被点赞对象之间的关联关系。

表结构设计示例：

CREATE TABLE `likes` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) unsigned NOT NULL COMMENT '点赞用户ID',
  `target_id` bigint(20) unsigned NOT NULL COMMENT '被点赞对象ID（如文章ID）',
  `target_type` varchar(50) NOT NULL COMMENT '被点赞对象类型（如post, comment）',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_target` (`user_id`, `target_id`, `target_type`) COMMENT '防止重复点赞的唯一约束',
  KEY `idx_target` (`target_id`, `target_type`) COMMENT '用于快速查询某对象的点赞列表'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

操作逻辑：

用户点赞： 执行 INSERT 操作，向 likes 表中插入一条记录，由于设置了 (user_id, target_id, target_type) 的联合唯一索引，如果用户重复点赞，数据库会直接报错，应用层捕获此错误并提示用户即可。
用户取消点赞： 执行 DELETE 操作，根据 user_id 和 target_id 删除对应的记录。
查询点赞总数： 执行 SELECT COUNT(*) FROM likes WHERE target_id = ? AND target_type = ?。
判断用户是否已点赞： 执行 SELECT COUNT(*) FROM likes WHERE user_id = ? AND target_id = ? AND target_type = ?，或者更高效的 SELECT id FROM likes WHERE ... LIMIT 1。

优点：

数据结构清晰： 关系明确，符合数据库设计范式。
扩展性强： 通过 target_type 字段可以轻松支持对多种类型对象的点赞。
信息完整： 可以轻松查询出谁点赞了某个对象，用于展示点赞用户列表等高级功能。

缺点：

查询性能问题： 对于热点内容（点赞数非常高的对象），每次执行 COUNT(*) 操作都会造成不小的性能开销，尤其是在高并发读取场景下。

在目标表中冗余计数字段

为了解决方案一中查询点赞数性能低下的问题,可以采用空间换时间的策略，即在目标对象（如文章表）中直接增加一个计数字段。

表结构修改示例：

高并发下后台数据库点赞功能该如何设计实现？

-- 在已有文章表 posts 中增加字段
ALTER TABLE `posts` ADD COLUMN `like_count` int(10) unsigned NOT NULL DEFAULT 0 COMMENT '点赞数';

操作逻辑：

用户点赞：
1. 开启数据库事务。
2. 向 likes 表 INSERT 一条记录（用于防重复和记录关系）。
3. 更新 posts 表，执行 UPDATE posts SET like_count = like_count + 1 WHERE id = ?。
4. 提交事务。
用户取消点赞： 同样在事务中，先 DELETE likes 表记录，再 UPDATE posts SET like_count = like_count - 1。
查询点赞总数： 直接从 posts 表读取 like_count 字段，速度极快。

优点：

读取性能极高： 获取点赞数的查询变成了简单的单表字段读取，性能远超 COUNT 操作。
实现简单： 对于只需要显示总数的场景，此方案直观高效。

缺点：

数据一致性风险： likes 表的关系数据和 posts 表的计数数据可能不一致，更新 like_count 成功但插入 likes 记录失败，反之亦然，虽然事务可以很大程度上保证，但在复杂分布式环境下仍需额外处理。
并发更新问题： 高并发下，多个用户同时点赞可能导致 like_count 更新出错（使用 like_count = like_count + 1 而非原子操作时），需要依赖数据库的行锁或乐观锁机制。

混合与高级策略

对于大型、高并发的互联网应用，上述两种方案可能都难以满足极致的性能要求，通常会引入缓存和异步处理等高级策略，形成一套混合方案。

核心思想： 将高频的读写操作转移到内存缓存（如 Redis）中，然后通过异步任务将缓存数据同步回数据库。

操作流程：

用户点赞/取消点赞：
- 应用服务器接收到请求后,不直接操作数据库。
- 向 Redis 发送一个指令，对 post:123:likes 这样的 key 执行 INCR（点赞）或 DECR（取消点赞）操作，Redis 的原子性操作保证了计数的准确性。
- 可以将用户点赞/取消点赞的事件记录发送到消息队列（如 Kafka, RabbitMQ）中。
查询点赞总数： 直接从 Redis 中读取 post:123:likes 的值，响应速度在毫秒级。
判断用户是否已点赞： 可以在 Redis 中使用 Set 数据结构来存储每个对象的点赞用户列表，post:123:likers，利用 SADD 和 SISMEMBER 命令实现，效率极高。
数据持久化：
- 启动一个或多个后台消费者进程,监听消息队列。
- 消费者从队列中取出点赞事件,然后异步地将关系数据写入 likes 表，并定期（如每隔几分钟）或当缓存中的计数达到一定阈值时，将最终的点赞数同步回 posts 表的 like_count 字段。

优点：

性能卓越： 读写操作均在内存中完成，极大降低了数据库压力，用户体验极佳。
系统解耦： 通过消息队列，点赞操作的核心流程与数据库持久化过程解耦，提高了系统的健壮性和可扩展性。

缺点：

高并发下后台数据库点赞功能该如何设计实现？

架构复杂： 引入了 Redis、消息队列等新组件，增加了系统的复杂度和运维成本。
数据延迟： 缓存中的数据和最终落库的数据之间存在一定的时间延迟，对于需要强一致性的业务场景需要谨慎评估。

方案对比

为了更直观地选择,我们将上述方案进行对比：

方案	优点	缺点	适用场景
独立点赞关系表	结构清晰，扩展性强，信息完整	计数查询性能差	初创项目、中小型应用、对点赞者列表有强需求
冗余计数字段	查询点赞数性能极高	数据一致性风险，并发更新复杂	读取性能要求高，但并发量不大的应用
混合与高级策略	性能卓越，系统解耦，可扩展性强	架构复杂，有数据延迟，运维成本高	大型、高并发互联网应用

后台数据库的点赞设计并非一成不变,而是一个在性能、一致性和复杂度之间权衡的过程，对于大多数中小型项目，从“方案一：独立的点赞关系表”入手是一个稳妥的选择，它提供了最好的灵活性和数据完整性，当业务增长，出现明显的性能瓶颈时，可以平滑演进到“方案二：冗余计数字段”来优化读取性能，而对于追求极致用户体验、面临巨大流量挑战的头部应用，引入缓存和异步队列的“方案三：混合与高级策略”则是必然的技术演进方向，理解每一种方案的底层逻辑和取舍，才能在实际开发中做出最合适的技术决策。

一	二	三	四	五	六	日
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

5154

Good Luck To You!

高并发下后台数据库点赞功能该如何设计实现？2025-10-16 03:08:12

核心设计思路

独立的点赞关系表

在目标表中冗余计数字段

混合与高级策略

方案对比

相关问答FAQs