新浪微博「点赞功能」数据库如何设计的？
新浪微博的“点赞功能”数据库设计是一个相对复杂但又充满巧思的系统，它需要处理海量的用户、微博、以及互动数据。下面我将尽可能详细地阐述其设计思路和可能采用的方案。
核心需求分析：
在深入设计之前，我们先明确“点赞功能”的核心需求：
1. 记录点赞关系： 哪个用户点赞了哪条微博。
2. 统计点赞数量： 实时或近实时地显示每条微博被点赞的总数。
3. 查看点赞用户列表： 用户可以查看点赞了某条微博的所有用户。
4. 取消点赞： 用户可以取消之前的点赞行为。
5. 用户是否点赞过某条微博： 用户在查看某条微博时，需要知道自己是否已经点赞。
6. 性能要求： 微博的点赞量巨大，需要高效的写入（点赞/取消点赞）和读取（显示点赞数、点赞列表）。
7. 可扩展性： 随着用户量和内容的增长，系统需要能够水平扩展。
8. 社交关系影响： （可选但常见）如果点赞行为会影响好友动态，还需要考虑如何将点赞事件推送到好友的feed流中。
数据库设计方案探讨：
针对以上需求，我们可以考虑多种数据库和存储方案的组合。以下是一些可能的方向和具体设计：
方案一：关系型数据库为主（如MySQL）
这是最基础的方案，适合初期的设计或作为某些子模块的支撑。
1. 核心表设计：
`users` 表 (用户信息)：
`user_id` (BIGINT, PK) 用户唯一标识
`username` (VARCHAR)
... 其他用户信息
`weibos` 表 (微博信息)：
`weibo_id` (BIGINT, PK) 微博唯一标识
`user_id` (BIGINT, FK to users.user_id) 微博作者
`content` (TEXT)
`created_at` (DATETIME)
`like_count` (INT DEFAULT 0) 微博的点赞总数（这里是一个冗余字段，用于快速读取）
... 其他微博信息
`weibo_likes` 表 (点赞记录)：
`like_id` (BIGINT, PK) 点赞记录的唯一标识（可选，有时也可以使用复合主键）
`user_id` (BIGINT, FK to users.user_id) 点赞用户ID
`weibo_id` (BIGINT, FK to weibos.weibo_id) 被点赞微博ID
`created_at` (DATETIME) 点赞时间
复合唯一索引： `(user_id, weibo_id)` 确保一个用户只能点赞一条微博一次。
2. 关键字段设计说明：
`weibo_likes.user_id` 和 `weibo_likes.weibo_id`： 这是记录点赞关系的核心。
`weibos.like_count`： 这个字段是优化读取性能的关键。每次点赞或取消点赞时，都需要更新 `weibos` 表的 `like_count` 字段。这会导致写操作的开销增加，但能极大提升读取时的效率，因为不需要 JOIN `weibo_likes` 表来计算点赞数。
3. 核心操作的实现：
点赞：
1. 在一个事务中，向 `weibo_likes` 表插入一条记录 `(user_id, weibo_id, current_time)`。
2. 如果插入成功（即之前没有被点赞过），则更新 `weibos` 表，将 `like_count` 字段加1（`UPDATE weibos SET like_count = like_count + 1 WHERE weibo_id = ?`）。
3. 如果插入失败（由于唯一索引冲突），则说明用户已点赞，不做任何操作。
取消点赞：
1. 在一个事务中，从 `weibo_likes` 表中删除 `(user_id, weibo_id)` 对应的记录。
2. 如果删除成功，则更新 `weibos` 表，将 `like_count` 字段减1（`UPDATE weibos SET like_count = like_count 1 WHERE weibo_id = ?`）。
查看点赞数量：
直接从 `weibos` 表中读取 `like_count` 字段。这是最快的方式。
查看点赞用户列表：
查询 `weibo_likes` 表：`SELECT user_id FROM weibo_likes WHERE weibo_id = ? LIMIT ? OFFSET ?`。这里需要对 `weibo_id` 进行索引，以便快速查找。如果需要显示用户名等信息，则需要 JOIN `users` 表。
判断用户是否点赞某条微博：
查询 `weibo_likes` 表：`SELECT 1 FROM weibo_likes WHERE user_id = ? AND weibo_id = ? LIMIT 1`。如果返回一行，则表示已点赞。
4. 关系型数据库的挑战与优化：
写冲突（并发更新 `like_count`）： 当大量用户同时点赞同一条微博时，`weibos.like_count` 的更新会成为瓶颈。简单的行锁可能导致大量的等待。
热点问题： 热门微博的点赞操作会集中在少数几条微博上，导致这些微博对应的行锁竞争激烈。
数据量： `weibo_likes` 表会非常庞大，索引的维护成本高，查询性能可能下降。
读写分离： 数据库需要支持读写分离，将点赞/取消点赞的写操作导向主库，将点赞列表的读操作导向从库（但需要考虑数据同步延迟）。
分库分表： 随着数据量的增长，必须进行分库分表。
用户维度分表： 以 `user_id` 作为分片键，将 `weibo_likes` 表分散到多个数据库或多个表中。例如，`weibo_likes_user_part_X`。这样可以分散用户点赞写入的压力。
微博维度分表： 以 `weibo_id` 作为分片键，将 `weibo_likes` 表分散。例如，`weibo_likes_weibo_part_Y`。这样可以分散热门微博的点赞读取压力。
混合分片： 可能需要一种更复杂的策略来平衡。
`weibos.like_count` 的更新： 在分库分表后，更新 `like_count` 会变得复杂，可能需要跨库事务（不推荐，性能问题）或者采用异步更新机制。
方案二：混合存储方案（关系型数据库 + NoSQL/缓存）
为了解决关系型数据库在海量高并发场景下的瓶颈，通常会引入其他技术。
1. 使用 Redis 作为点赞计数器和点赞集合的缓存：
点赞计数 (`like_count`)：
使用 Redis 的 `INCR` 命令来原子性地增加计数。
当用户点赞时：`INCR weibos:like_count:`
当用户取消点赞时：`DECR weibos:like_count:`
优点： Redis 的 `INCR`/`DECR` 操作非常快，可以轻松处理高并发更新。
缺点： 这是一个内存存储，需要考虑持久化和与数据库的同步。如果 Redis 故障，可能会丢失一部分计数。
点赞用户集合：
使用 Redis 的 `SADD` 命令将用户ID添加到集合中。
当用户点赞时：`SADD weibos:likers: `
当用户取消点赞时：`SREM weibos:likers: `
优点： 集合数据结构天然支持去重，方便查看某个用户是否点赞过（`SISMEMBER`），以及获取点赞用户列表（`SMEMBERS`，但注意内存占用和性能）。
缺点： 如果点赞用户非常多，`weibos:likers:` 这个 Key 对应的集合会非常大，消耗大量内存，并且 `SMEMBERS` 操作在高并发下可能导致性能问题（返回大量数据）。
2. 如何与关系型数据库同步：
异步双写/数据同步：
当用户点赞/取消点赞时，应用程序会同时执行以下操作：
1. 在 Redis 中更新计数和集合。
2. 将点赞/取消点赞的事件（`user_id`, `weibo_id`, `action_type`）发送到一个消息队列（如 Kafka, RabbitMQ）。
3. 一个消费者从消息队列中读取事件，然后将这些记录（点赞关系）写入到关系型数据库的 `weibo_likes` 表中（进行去重和幂等处理）。
好处： 降低了直接写入关系型数据库的压力，提高了点赞操作的响应速度。
同步延迟： 这种方式会引入一定的同步延迟，用户在短时间内可能无法在数据库中看到完整的点赞记录，但点赞数会实时更新。
3. 集成方案：
点赞数读取： 直接从 Redis 读取 `weibos:like_count:`。如果 Redis 不可用，可以尝试从 `weibos` 表的 `like_count` 字段读取（作为降级）。
用户是否点赞某条微博： 使用 Redis 的 `SISMEMBER weibos:likers: `。
点赞用户列表： 如果点赞用户数量不大（例如，最多显示前几百个），可以直接从 Redis 的 `SMEMBERS` 获取。如果需要完整的列表，或者数据量过大，则需要从关系型数据库的 `weibo_likes` 表查询。
方案三：基于特定技术栈的优化
如果考虑更专业的分布式数据库或数据处理工具：
分布式数据库 (如 TiDB, CockroachDB)： 这些数据库本身支持分布式事务和水平扩展，可能可以更简单地处理点赞计数和点赞关系的存储，但需要权衡其成本和生态。
大数据处理框架 (如 Hadoop/Spark with HBase/Cassandra)：
HBase/Cassandra： 适合存储大量的（user_id, weibo_id）的键值对。
HBase 设计：
表：`weibo_likes`
Row Key： `weibo_id` + `_` + `user_id` (或反之，取决于查询模式)。这样可以按 `weibo_id` 分组。
Column Family： `info`
Columns： `like_time` (DATETIME), `status` (VARCHAR, e.g., "liked", "unliked" 如果需要记录状态变化)
优点： 可以高效地存储大量的点赞关系，并能通过 Row Key 前缀查找某个微博的所有点赞记录。
挑战： 如何高效获取点赞总数？这通常需要额外的计数机制或扫描，可能不如 Redis 的 `INCR` 直观。
点赞计数： 对于点赞计数，依然可以考虑使用 Redis 作为热点计数器，或者使用 Spark Streaming/Flink 等流处理框架实时聚合。
综合来看，一个成熟的微博点赞系统可能采取的策略：
1. 高频、实时的点赞计数： 使用 Redis 的 `INCR`/`DECR` 原子操作，非常高效。
2. 用户点赞状态的快速查询： 使用 Redis 的 `SADD`/`SREM`/`SISMEMBER` 来记录用户是否点赞了某条微博。
3. 点赞关系持久化： 将点赞行为（`user_id`, `weibo_id`, `timestamp`）异步写入到消息队列，然后由消费者写入到分库分表的关系型数据库（如MySQL）的 `weibo_likes` 表中。这样可以保留完整的点赞历史，用于数据分析、风控、以及在 Redis 缓存失效时的恢复。
4. 点赞用户列表的获取：
如果点赞用户数量在可接受范围内（例如，几百以内），直接从 Redis 的 `SMEMBERS` 获取。
如果需要显示更多点赞用户，或者进行分页展示，则从关系型数据库的 `weibo_likes` 表中查询。
5. 微博的点赞总数展示： 主要从 Redis 读取，以保证实时性和性能。在需要时，可以通过定时任务或数据同步 Job 将 Redis 的计数与数据库的计数进行核对和修正。
6. 数据清理和归档： 随着时间的推移，旧的或不活跃的微博的点赞数据量可能非常庞大，需要考虑数据归档或清理策略。
考虑的点赞功能扩展：
“赞过”列表： 用户可以查看自己赞过的所有微博，这可以通过查询 `weibo_likes` 表（或其分片）来实现，将 `user_id` 作为主查询条件。
“点赞”动态： 将点赞事件推送到好友的feed流中。这需要一个事件总线和 Feed 流生成系统，点赞事件会触发生成新的feed项。
反作弊/风控： 监控异常的点赞行为，例如短时间内大量点赞同一条微博或大量用户对同一条微博进行重复点赞/取消点赞。这些都需要对点赞行为数据进行分析。
总结：
一个高性能、可扩展的微博点赞功能数据库设计通常是多技术栈的融合。核心思路是利用内存缓存（如 Redis）处理高并发的计数和状态判断，同时将完整的点赞关系异步持久化到分布式关系型数据库（如分库分表的MySQL）中以保证数据的可靠性和可追溯性。这种设计权衡了实时性、可用性、一致性和存储成本。
核心需求分析：
在深入设计之前，我们先明确“点赞功能”的核心需求：
1. 记录点赞关系： 哪个用户点赞了哪条微博。
2. 统计点赞数量： 实时或近实时地显示每条微博被点赞的总数。
3. 查看点赞用户列表： 用户可以查看点赞了某条微博的所有用户。
4. 取消点赞： 用户可以取消之前的点赞行为。
5. 用户是否点赞过某条微博： 用户在查看某条微博时，需要知道自己是否已经点赞。
6. 性能要求： 微博的点赞量巨大，需要高效的写入（点赞/取消点赞）和读取（显示点赞数、点赞列表）。
7. 可扩展性： 随着用户量和内容的增长，系统需要能够水平扩展。
8. 社交关系影响： （可选但常见）如果点赞行为会影响好友动态，还需要考虑如何将点赞事件推送到好友的feed流中。
数据库设计方案探讨：
针对以上需求，我们可以考虑多种数据库和存储方案的组合。以下是一些可能的方向和具体设计：
方案一：关系型数据库为主（如MySQL）
这是最基础的方案，适合初期的设计或作为某些子模块的支撑。
1. 核心表设计：
`users` 表 (用户信息)：
`user_id` (BIGINT, PK) 用户唯一标识
`username` (VARCHAR)
... 其他用户信息
`weibos` 表 (微博信息)：
`weibo_id` (BIGINT, PK) 微博唯一标识
`user_id` (BIGINT, FK to users.user_id) 微博作者
`content` (TEXT)
`created_at` (DATETIME)
`like_count` (INT DEFAULT 0) 微博的点赞总数（这里是一个冗余字段，用于快速读取）
... 其他微博信息
`weibo_likes` 表 (点赞记录)：
`like_id` (BIGINT, PK) 点赞记录的唯一标识（可选，有时也可以使用复合主键）
`user_id` (BIGINT, FK to users.user_id) 点赞用户ID
`weibo_id` (BIGINT, FK to weibos.weibo_id) 被点赞微博ID
`created_at` (DATETIME) 点赞时间
复合唯一索引： `(user_id, weibo_id)` 确保一个用户只能点赞一条微博一次。
2. 关键字段设计说明：
`weibo_likes.user_id` 和 `weibo_likes.weibo_id`： 这是记录点赞关系的核心。
`weibos.like_count`： 这个字段是优化读取性能的关键。每次点赞或取消点赞时，都需要更新 `weibos` 表的 `like_count` 字段。这会导致写操作的开销增加，但能极大提升读取时的效率，因为不需要 JOIN `weibo_likes` 表来计算点赞数。
3. 核心操作的实现：
点赞：
1. 在一个事务中，向 `weibo_likes` 表插入一条记录 `(user_id, weibo_id, current_time)`。
2. 如果插入成功（即之前没有被点赞过），则更新 `weibos` 表，将 `like_count` 字段加1（`UPDATE weibos SET like_count = like_count + 1 WHERE weibo_id = ?`）。
3. 如果插入失败（由于唯一索引冲突），则说明用户已点赞，不做任何操作。
取消点赞：
1. 在一个事务中，从 `weibo_likes` 表中删除 `(user_id, weibo_id)` 对应的记录。
2. 如果删除成功，则更新 `weibos` 表，将 `like_count` 字段减1（`UPDATE weibos SET like_count = like_count 1 WHERE weibo_id = ?`）。
查看点赞数量：
直接从 `weibos` 表中读取 `like_count` 字段。这是最快的方式。
查看点赞用户列表：
查询 `weibo_likes` 表：`SELECT user_id FROM weibo_likes WHERE weibo_id = ? LIMIT ? OFFSET ?`。这里需要对 `weibo_id` 进行索引，以便快速查找。如果需要显示用户名等信息，则需要 JOIN `users` 表。
判断用户是否点赞某条微博：
查询 `weibo_likes` 表：`SELECT 1 FROM weibo_likes WHERE user_id = ? AND weibo_id = ? LIMIT 1`。如果返回一行，则表示已点赞。
4. 关系型数据库的挑战与优化：
写冲突（并发更新 `like_count`）： 当大量用户同时点赞同一条微博时，`weibos.like_count` 的更新会成为瓶颈。简单的行锁可能导致大量的等待。
热点问题： 热门微博的点赞操作会集中在少数几条微博上，导致这些微博对应的行锁竞争激烈。
数据量： `weibo_likes` 表会非常庞大，索引的维护成本高，查询性能可能下降。
读写分离： 数据库需要支持读写分离，将点赞/取消点赞的写操作导向主库，将点赞列表的读操作导向从库（但需要考虑数据同步延迟）。
分库分表： 随着数据量的增长，必须进行分库分表。
用户维度分表： 以 `user_id` 作为分片键，将 `weibo_likes` 表分散到多个数据库或多个表中。例如，`weibo_likes_user_part_X`。这样可以分散用户点赞写入的压力。
微博维度分表： 以 `weibo_id` 作为分片键，将 `weibo_likes` 表分散。例如，`weibo_likes_weibo_part_Y`。这样可以分散热门微博的点赞读取压力。
混合分片： 可能需要一种更复杂的策略来平衡。
`weibos.like_count` 的更新： 在分库分表后，更新 `like_count` 会变得复杂，可能需要跨库事务（不推荐，性能问题）或者采用异步更新机制。
方案二：混合存储方案（关系型数据库 + NoSQL/缓存）
为了解决关系型数据库在海量高并发场景下的瓶颈，通常会引入其他技术。
1. 使用 Redis 作为点赞计数器和点赞集合的缓存：
点赞计数 (`like_count`)：
使用 Redis 的 `INCR` 命令来原子性地增加计数。
当用户点赞时：`INCR weibos:like_count:
当用户取消点赞时：`DECR weibos:like_count:
优点： Redis 的 `INCR`/`DECR` 操作非常快，可以轻松处理高并发更新。
缺点： 这是一个内存存储，需要考虑持久化和与数据库的同步。如果 Redis 故障，可能会丢失一部分计数。
点赞用户集合：
使用 Redis 的 `SADD` 命令将用户ID添加到集合中。
当用户点赞时：`SADD weibos:likers:
当用户取消点赞时：`SREM weibos:likers:
优点： 集合数据结构天然支持去重，方便查看某个用户是否点赞过（`SISMEMBER`），以及获取点赞用户列表（`SMEMBERS`，但注意内存占用和性能）。
缺点： 如果点赞用户非常多，`weibos:likers:
2. 如何与关系型数据库同步：
异步双写/数据同步：
当用户点赞/取消点赞时，应用程序会同时执行以下操作：
1. 在 Redis 中更新计数和集合。
2. 将点赞/取消点赞的事件（`user_id`, `weibo_id`, `action_type`）发送到一个消息队列（如 Kafka, RabbitMQ）。
3. 一个消费者从消息队列中读取事件，然后将这些记录（点赞关系）写入到关系型数据库的 `weibo_likes` 表中（进行去重和幂等处理）。
好处： 降低了直接写入关系型数据库的压力，提高了点赞操作的响应速度。
同步延迟： 这种方式会引入一定的同步延迟，用户在短时间内可能无法在数据库中看到完整的点赞记录，但点赞数会实时更新。
3. 集成方案：
点赞数读取： 直接从 Redis 读取 `weibos:like_count:
用户是否点赞某条微博： 使用 Redis 的 `SISMEMBER weibos:likers:
点赞用户列表： 如果点赞用户数量不大（例如，最多显示前几百个），可以直接从 Redis 的 `SMEMBERS` 获取。如果需要完整的列表，或者数据量过大，则需要从关系型数据库的 `weibo_likes` 表查询。
方案三：基于特定技术栈的优化
如果考虑更专业的分布式数据库或数据处理工具：
分布式数据库 (如 TiDB, CockroachDB)： 这些数据库本身支持分布式事务和水平扩展，可能可以更简单地处理点赞计数和点赞关系的存储，但需要权衡其成本和生态。
大数据处理框架 (如 Hadoop/Spark with HBase/Cassandra)：
HBase/Cassandra： 适合存储大量的（user_id, weibo_id）的键值对。
HBase 设计：
表：`weibo_likes`
Row Key： `weibo_id` + `_` + `user_id` (或反之，取决于查询模式)。这样可以按 `weibo_id` 分组。
Column Family： `info`
Columns： `like_time` (DATETIME), `status` (VARCHAR, e.g., "liked", "unliked" 如果需要记录状态变化)
优点： 可以高效地存储大量的点赞关系，并能通过 Row Key 前缀查找某个微博的所有点赞记录。
挑战： 如何高效获取点赞总数？这通常需要额外的计数机制或扫描，可能不如 Redis 的 `INCR` 直观。
点赞计数： 对于点赞计数，依然可以考虑使用 Redis 作为热点计数器，或者使用 Spark Streaming/Flink 等流处理框架实时聚合。
综合来看，一个成熟的微博点赞系统可能采取的策略：
1. 高频、实时的点赞计数： 使用 Redis 的 `INCR`/`DECR` 原子操作，非常高效。
2. 用户点赞状态的快速查询： 使用 Redis 的 `SADD`/`SREM`/`SISMEMBER` 来记录用户是否点赞了某条微博。
3. 点赞关系持久化： 将点赞行为（`user_id`, `weibo_id`, `timestamp`）异步写入到消息队列，然后由消费者写入到分库分表的关系型数据库（如MySQL）的 `weibo_likes` 表中。这样可以保留完整的点赞历史，用于数据分析、风控、以及在 Redis 缓存失效时的恢复。
4. 点赞用户列表的获取：
如果点赞用户数量在可接受范围内（例如，几百以内），直接从 Redis 的 `SMEMBERS` 获取。
如果需要显示更多点赞用户，或者进行分页展示，则从关系型数据库的 `weibo_likes` 表中查询。
5. 微博的点赞总数展示： 主要从 Redis 读取，以保证实时性和性能。在需要时，可以通过定时任务或数据同步 Job 将 Redis 的计数与数据库的计数进行核对和修正。
6. 数据清理和归档： 随着时间的推移，旧的或不活跃的微博的点赞数据量可能非常庞大，需要考虑数据归档或清理策略。
考虑的点赞功能扩展：
“赞过”列表： 用户可以查看自己赞过的所有微博，这可以通过查询 `weibo_likes` 表（或其分片）来实现，将 `user_id` 作为主查询条件。
“点赞”动态： 将点赞事件推送到好友的feed流中。这需要一个事件总线和 Feed 流生成系统，点赞事件会触发生成新的feed项。
反作弊/风控： 监控异常的点赞行为，例如短时间内大量点赞同一条微博或大量用户对同一条微博进行重复点赞/取消点赞。这些都需要对点赞行为数据进行分析。
总结：
一个高性能、可扩展的微博点赞功能数据库设计通常是多技术栈的融合。核心思路是利用内存缓存（如 Redis）处理高并发的计数和状态判断，同时将完整的点赞关系异步持久化到分布式关系型数据库（如分库分表的MySQL）中以保证数据的可靠性和可追溯性。这种设计权衡了实时性、可用性、一致性和存储成本。
网友意见
我现在在微博负责这块代码
每个微博都有一个点赞数，跟微博内容是分开存储的
数据库用了基于redis二次开发的计数器，里面有很多亮瞎的细节具体就不方便多说了，主要优化了存储效率，内存存储了最近几年的点赞数据，在达到存储极限的时候会将最旧的数据转到磁盘，如果缓存miss会读磁盘，而且只有特别老的数据才会读磁盘，所以影响不大，性能和原生的redis一样，但是同样的内存会存储更多的数据，具体有多少倒是没有算过
最近也在考虑将计数器的代码开源出来，如果你们对这方面有需要，可以关注一下
找到了前辈在设计计数器思路的文章
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有