多用户令牌下Instagram热门话题内容分布式查询数据库设计咨询

可行性判断 #

你基于现有两个假设提出的初始方案具备可行性，但原有表结构存在冗余、配额计算逻辑不符合官方滚动周期要求的问题，可按以下思路调整优化。

关联表设计必要性 #

你提到的新增hashtag_to_access_token多对多关联表是必要的，原有hashtag表中存储access_token字段的设计存在明显缺陷：

• 同一个标签可能在不同统计周期被多个令牌查询，单字段存储会导致数据冗余
• 令牌更新/失效时需要批量修改所有关联的hashtag记录，执行效率极低
• 无法追溯令牌的历史使用记录，不符合滚动周期配额统计的要求

滚动7天30次配额的约束实现方案 #

原有access_token表中固定存储usage计数的设计不符合官方滚动7天周期的规则，无法适配非固定周期的配额重置逻辑，可通过以下调整实现自动约束：

1. 在hashtag_to_access_token表中新增used_at时间字段，记录每一次令牌查询标签的具体时间
2. 删除access_token表的固定usage字段，令牌剩余可用配额通过动态计算获得：剩余配额 = 30 - 过去7天内该令牌在hashtag_to_access_token表中的关联记录数
3. 定时任务分配令牌前先计算对应令牌的剩余配额，仅当剩余配额>0时才可分配使用，天然符合官方规则要求

优化后完整表结构 #

-- 标签主表
CREATE TABLE `hashtag` (
  `id` int UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `hashtag` varchar(100) NOT NULL UNIQUE COMMENT '标签文本内容',
  `igid` bigint UNSIGNED NULL COMMENT 'Instagram官方标签ID',
  `last_searched` timestamp NULL COMMENT '最近一次成功查询时间'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 内容与标签关联表
CREATE TABLE `media_to_hashtag` (
  `media_id` bigint UNSIGNED NOT NULL,
  `hashtag_id` int UNSIGNED NOT NULL,
  `like_count` int UNSIGNED DEFAULT 0 COMMENT '内容点赞数',
  `comment_count` int UNSIGNED DEFAULT 0 COMMENT '内容评论数',
  `post_time` timestamp NULL COMMENT '内容发布时间',
  PRIMARY KEY (`media_id`, `hashtag_id`),
  KEY `idx_hashtag_id` (`hashtag_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 访问令牌主表
CREATE TABLE `access_token` (
  `access_token_id` int UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `token` text NOT NULL COMMENT '用户访问令牌',
  `user_id` bigint UNSIGNED NOT NULL COMMENT '关联用户ID，用于令牌失效/用户注销时处理',
  `is_valid` tinyint(1) DEFAULT 1 COMMENT '令牌有效性标记，0为失效',
  `created_at` timestamp DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 标签与令牌使用关联表
CREATE TABLE `hashtag_to_access_token` (
  `hashtag_id` int UNSIGNED NOT NULL,
  `access_token_id` int UNSIGNED NOT NULL,
  `used_at` timestamp DEFAULT CURRENT_TIMESTAMP COMMENT '本次查询使用时间',
  PRIMARY KEY (`hashtag_id`, `access_token_id`),
  KEY `idx_access_token_used` (`access_token_id`, `used_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

定时任务流程优化 #

调整后的定时任务执行逻辑更严谨：

• 第一步：筛选待查询标签，包括从未查询过（last_searched IS NULL）、或者距离上次查询时间超过你设定的更新周期（比如24小时）的标签
• 第二步：筛选所有有效令牌（is_valid = 1），计算每个令牌过去7天的使用次数，剩余配额>0的进入可用令牌池
• 第三步：为待查询标签分配可用令牌，每完成一次分配就向hashtag_to_access_token插入一条记录
• 第四步：调用API查询标签数据，查询成功后更新hashtag表的last_searched字段，以及media_to_hashtag表的统计数据

额外优化建议 #

• 新增标签重复查询校验：同一个标签7天内如果已经有查询记录，无需重复分配令牌查询，避免浪费配额
• 令牌失效无需物理删除，仅需将access_token表的is_valid字段设为0即可，后续分配时自动过滤
• 若查询量级较大，可将令牌剩余配额的计算结果做缓存，减少定时任务的数据库查询压力

内容的提问来源于stack exchange，提问作者apidev