友猫社区系统源码解析，千级并发下的MySQL分表与Redis缓存方案

经纬云科技

370人浏览 · 2026-05-11 18:17:44

经纬云科技 · 2026-05-11 18:17:44 发布

一、内容社区的数据挑战

内容社区产品的核心业务包括动态发布、圈子生态、问答悬赏等功能。这些功能背后有一个共同特点：读多写少，热点集中。一篇热门动态可能被数十万用户浏览，而这条数据在数据库里只有一条记录；一条评论发布后，会被成千上万次阅读。如果每次查询都直接打到MySQL，数据库很快会成为瓶颈。本文将拆解友猫社区系统（一个开源的垂直内容社区项目）在数据库设计和缓存架构上的解决方案。

二、核心功能模块与数据特征

在深入数据库之前，先明确三个核心功能的数据特征：

动态发布：支持图文、短视频、长图文。数据特征是写一次、读多次，热门动态的读请求可能达到每秒数千次。

圈子生态：用户与圈子的隶属关系，以及圈内动态的聚合查询。查询模式是“查某个圈子的动态列表”，需要按圈子ID和时间排序。

问答悬赏：涉及积分账户的增减操作，对事务一致性要求高，需要保证悬赏积分从提问者到回答者的原子性转移。

三、核心表结构设计

1. 用户表与动态表

用户ID采用雪花算法生成，避免自增ID在分表场景下的冲突问题。手机号作为唯一索引，用于登录快速校验。密码使用BCrypt加密存储。

动态表建表语句：

CREATE TABLE `post` (
  `id` bigint NOT NULL,
  `user_id` bigint NOT NULL,
  `content_type` tinyint DEFAULT '1',
  `status` tinyint DEFAULT '0',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_user_status` (`user_id`, `status`),
  KEY `idx_create_time` (`create_time`)
);

2. 圈子表与成员关系表

圈子表存储圈主ID、名称、公告、类型（普通/推荐/热门/付费）、入圈价格。成员关系表使用(user_id, circle_id)联合主键防止重复加入，同时在这两个字段上分别建立索引，支持“用户加入了哪些圈子”和“圈子有哪些成员”两种查询方向。

3. 问答表与悬赏记录

问题表存储提问者ID、悬赏积分、状态。答案表存储回答者ID、内容、采纳状态。悬赏积分的转移必须在事务中完成——更新提问者积分（减）、更新回答者积分（加）、更新问题状态、记录积分流水，四个操作要么全部成功要么全部回滚。

四、评论分表与冷热分离

1. 评论表的分表策略

评论表的写入频率远高于读取频率。按post_id取模分成16张物理表，分表键选择动态ID而非评论ID，因为查询评论时总是“根据动态ID查评论列表”。分表后单表数据量控制在500万以内。

分表路由封装在MyBatis-Plus拦截器中，应用层无感知。

分表路由核心方法：

public String getCommentTableName(Long postId) {
    long shardKey = postId % 16;
    return "comment_" + shardKey;
}

2. 动态表冷热分离

动态表中只有最近30天的内容需要频繁访问。通过Quartz定时任务，每天凌晨将30天前的动态迁移到post_archive历史表中，原表只保留热数据。被迁移的动态若再次被访问，异步回迁到热表。这套方案使主表行数保持在可控范围。

五、Redis缓存架构设计

1. 三层缓存策略

Redis缓存三类数据：用户信息（String结构，user:info:{userId}，过期1小时）、热门动态列表（ZSet结构，Score为热度值）、点赞状态（Set结构，post:like:{postId}）。

点赞状态用Redis Set存储，判断是否已点赞只需执行SISMEMBER命令，O(1)时间复杂度，避免查询MySQL互动表。

点赞状态判断逻辑：

public boolean hasLiked(Long userId, Long postId) {
    String key = "post:like:" + postId;
    return redisTemplate.opsForSet().isMember(key, userId.toString());
}