当前位置：首页 > news >正文

内容平台的数据库分库分表实践：按用户、按内容还是按时间的决策矩阵

news 2026/7/24 15:47:00

内容平台的数据库分库分表实践：按用户、按内容还是按时间的决策矩阵

一、"双十一晚上的分表策略失效了"：分库分表的误判案例

某图文内容平台按user_id % 128做了16库×8表的分库分表。上线半年后，发现分片严重不均衡：粉丝超过100万的大V有50人，他们的单表数据量是普通用户的500倍。"大V表"的QPS是"普通表"的30倍，但因为按user_id哈希，无法将大V单独迁移到高性能实例上。

这就是分库分表中最经典的错误：以开发者的视角均匀分片，忽略了业务的幂律分布。

二、三种分片策略的深度对比

三、分库分表中间件与路由实现

使用ShardingSphere实现两级分片：

# ShardingSphere配置示例 dataSources: ds_0: url: jdbc:mysql://10.0.1.1:3306/content_db_0 ds_1: url: jdbc:mysql://10.0.1.2:3306/content_db_1 rules: - !SHARDING tables: articles: actualDataNodes: ds_${0..1}.articles_${0..15} databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: db_inline tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: table_inline user_articles: actualDataNodes: ds_${0..1}.user_articles_${0..7} tableStrategy: standard: shardingColumn: article_id shardingAlgorithmName: article_table_inline shardingAlgorithms: db_inline: type: INLINE props: algorithm-expression: ds_${user_id % 2} table_inline: type: INLINE props: algorithm-expression: articles_${user_id % 16}

但大V需要特殊处理（"热点隔离"策略）：

public class HotspotAwareShardingAlgorithm implements StandardShardingAlgorithm<Long> { private static final Set<Long> HOT_USERS = loadHotUsers(); private static final String HOT_DS = "ds_hot"; // 高性能实例 @Override public String doSharding(Collection<String> availableTargetNames, PreciseShardingValue<Long> shardingValue) { Long userId = shardingValue.getValue(); // 大V数据路由到专用高性能实例 if (HOT_USERS.contains(userId)) { return HOT_DS; } // 普通用户按哈希路由 int dbIndex = (int) (userId % 2); return "ds_" + dbIndex; } private static Set<Long> loadHotUsers() { // 从配置中心动态加载大V列表 // 可以通过Redis缓存，定期更新 return Sets.newHashSet(1001L, 2002L, 3003L); } } // 自定义ID生成器（分片友好的雪花变体） public class ShardAwareIdGenerator { private final int shardId; private final SnowflakeIdGenerator snowflake; public long generateArticleId() { long baseId = snowflake.nextId(); // 将分片ID编码到article_id中（低8位） return (baseId << 8) | (shardId & 0xFF); } public static int extractShardId(long articleId) { return (int) (articleId & 0xFF); } }

跨分片查询的路由策略：

public class CrossShardQueryRouter { public List<Article> searchArticles(String keyword, int page, int size) { // Step 1: 先查ES获取article_id列表（含user_id信息） List<ArticleHit> hits = elasticsearchService.search(keyword, page, size); // Step 2: 按分片分组 Map<String, List<Long>> shardGroups = hits.stream() .collect(Collectors.groupingBy( hit -> { int shardId = ShardAwareIdGenerator.extractShardId( hit.getArticleId() ); return "ds_" + shardId; }, Collectors.mapping(ArticleHit::getArticleId, Collectors.toList()) )); // Step 3: 并发查询各分片 List<CompletableFuture<List<Article>>> futures = shardGroups.entrySet() .stream() .map(entry -> CompletableFuture.supplyAsync( () -> querySingleShard(entry.getKey(), entry.getValue()), shardQueryExecutor )) .collect(Collectors.toList()); // Step 4: 合并结果 return futures.stream() .map(CompletableFuture::join) .flatMap(Collection::stream) .collect(Collectors.toList()); } private List<Article> querySingleShard(String dataSource, List<Long> articleIds) { // 使用对应的数据源执行IN查询 String sql = "SELECT * FROM articles WHERE article_id IN (:ids)"; return namedJdbcTemplates.get(dataSource) .query(sql, Map.of("ids", articleIds), articleRowMapper); } }