在当今的互联网应用中,“点赞”已成为一种基础且核心的用户交互功能，无论是社交媒体、内容平台还是电商网站，点赞系统都扮演着连接用户与内容、传递情感反馈的关键角色，要实现一个稳定、高效的点赞功能，其核心在于后台数据库的精心设计，一个糟糕的设计不仅会影响用户体验，还可能在数据量激增时给系统带来灾难性的性能瓶颈，本文将深入探讨后台数据库中点赞功能的设计思路、主流方案及其优缺点，并针对高并发场景提出优化策略。
核心设计思路
在设计点赞系统之前,我们必须明确几个核心需求：要能准确记录哪个用户对哪个对象（如文章、评论、视频）进行了点赞；要能快速查询某个对象的总点赞数；要能快速判断某个用户是否已经对某个对象点过赞，以防止重复点赞；系统需要具备良好的扩展性，以应对未来数据量的增长，围绕这些需求，衍生出了几种主流的数据库设计方案。
独立的点赞关系表
这是最经典、最通用的一种设计方案，其核心思想是创建一张独立的“点赞关系表”，专门用于存储用户与被点赞对象之间的关联关系。
表结构设计示例：
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 '点赞数';
操作逻辑：
- 用户点赞：
- 开启数据库事务。
- 向
likes表INSERT一条记录（用于防重复和记录关系）。 - 更新
posts表，执行UPDATE posts SET like_count = like_count + 1 WHERE id = ?。 - 提交事务。
- 用户取消点赞： 同样在事务中，先
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、消息队列等新组件，增加了系统的复杂度和运维成本。
- 数据延迟： 缓存中的数据和最终落库的数据之间存在一定的时间延迟，对于需要强一致性的业务场景需要谨慎评估。
方案对比
为了更直观地选择,我们将上述方案进行对比：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 独立点赞关系表 | 结构清晰，扩展性强，信息完整 | 计数查询性能差 | 初创项目、中小型应用、对点赞者列表有强需求 |
| 冗余计数字段 | 查询点赞数性能极高 | 数据一致性风险，并发更新复杂 | 读取性能要求高，但并发量不大的应用 |
| 混合与高级策略 | 性能卓越，系统解耦，可扩展性强 | 架构复杂，有数据延迟，运维成本高 | 大型、高并发互联网应用 |
后台数据库的点赞设计并非一成不变,而是一个在性能、一致性和复杂度之间权衡的过程，对于大多数中小型项目，从“方案一：独立的点赞关系表”入手是一个稳妥的选择，它提供了最好的灵活性和数据完整性，当业务增长，出现明显的性能瓶颈时，可以平滑演进到“方案二：冗余计数字段”来优化读取性能，而对于追求极致用户体验、面临巨大流量挑战的头部应用，引入缓存和异步队列的“方案三：混合与高级策略”则是必然的技术演进方向，理解每一种方案的底层逻辑和取舍，才能在实际开发中做出最合适的技术决策。
相关问答FAQs
如何从数据库层面彻底防止用户重复点赞？
解答： 最有效且可靠的方法是在点赞关系表（如 likes 表）上创建一个联合唯一索引（UNIQUE KEY），这个索引应该包含用户ID、被点赞对象ID和对象类型，UNIQUE KEY uk_user_target (user_id, target_id, target_type)，当同一个用户尝试对同一个对象再次点赞时，数据库会尝试插入一条违反唯一约束的记录，数据库操作将失败并返回一个错误码（如 MySQL 的 1062 错误），应用层捕获这个特定的错误，就可以判断出这是重复点赞行为，并向用户给出相应提示，这种方法将防重复的逻辑交给了数据库，从根本上保证了数据的一致性，比在应用层代码中先查询再插入的方式更高效、更安全。
当点赞数据量达到千万甚至上亿级别时，如何优化数据库的查询和存储性能？
解答： 面对海量点赞数据，可以从以下几个方面进行优化：
- 索引优化： 确保所有查询字段都建立了合适的索引，除了用于防重复的唯一索引外，
target_id和target_type的复合索引对于查询某内容的点赞列表和总数至关重要。 - 数据库分库分表（Sharding）： 当单表数据量过大时，查询性能会急剧下降，可以按照
target_id（被点赞对象ID）进行哈希取模，将likes表水平拆分成多个子表（如likes_0,likes_1, …），查询时，根据target_id直接定位到对应的子表，从而将单表的压力分散到多张表上。 - 读写分离： 将数据库部署为主从架构，主库负责处理点赞、取消点赞等写操作，从库负责处理查询点赞总数、点赞列表等读操作，通过读写分离，可以显著提升系统的整体读性能和可用性。
- 冷热数据分离： 对于非常久远的“冷”数据，可以将其归档到其他存储系统（如对象存储或数据仓库）中，只在主数据库中保留近期的“热”数据，保持主数据库的轻量级和高性能。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复