异步多采集器场景下实现MaxPerHour、MaxPerDay采样规则的方案咨询

分层计数核心设计 #

通过「本地内存聚合+中间存储批量写入」的架构，既避免高频请求直接打穿数据库，又满足多采集器的计数查询需求，误差范围可控制在采样场景可接受的区间内。 #

第一层：本地内存预聚合 #

负责承接上游高频消息的计数请求，所有计算逻辑全部在内存完成：

• 每个采集器实例本地维护三个维度的原子计数器，对应小时级、日级、全时间的消息总量、采样量，异步场景下用无锁原子类（如Java AtomicLong、Go sync/atomic、Python multiprocessing.Value）实现，单次计数耗时<1ms
• 采样判断直接基于本地全量消息计数完成：当前消息序号%10 == 0时，才触发采样资格校验，无需每次请求都访问存储层
• 维护待同步增量队列，采用双触发策略同步到中间存储：累计满100条计数同步1次，或间隔10秒强制同步1次，极端实例崩溃场景最多丢失10秒/100条的计数误差，符合采样场景的精度容忍度

第二层：中间存储选型 #

方案A：Redis（推荐，适合绝大多数生产场景） #

Redis的单线程原子操作+高性能读写特性，完美匹配计数场景需求：

• 存储结构：用Hash结构存储单个采集器的全量计数，Key规则为collector:sampling:{采集器ID}，三个Field分别为max_per_hour、max_per_day、max_all_time，对应三个维度的采样量
• 自动过期配置：小时级计数Key设置3600秒过期，日级计数Key设置86400秒过期，无需手动清理历史数据
• 写入性能：单实例Redis写入QPS可达10w+，批量写入下性能进一步提升，完全承接异步场景的高并发写入压力
• 查询性能：单个采集器的多维度查询为O(1)操作，耗时<1ms，支持高并发查询需求

可用性要求高的场景可以部署Redis主从集群或哨兵模式，避免单点故障

方案B：数据库+本地缓存（无Redis基础设施时选用） #

如果没有Redis部署条件，通过批量合并+缓存优化也能满足性能要求：

• 写入优化：异步合并1秒内所有采集器的增量计数请求，组装为批量更新SQL提交到数据库，将每秒上千次的单条写入合并为个位数的批量写入，大幅降低数据库压力
• 查询优化：用Caffeine/Guava等LRU缓存做热点查询缓存，缓存有效期设置为1秒，可拦截90%以上的重复查询请求
• 参考表结构设计：

CREATE TABLE collector_sampling_count (
  id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT COMMENT '主键',
  collector_id VARCHAR(64) NOT NULL COMMENT '采集器唯一标识',
  hourly_count BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '小时采样量',
  daily_count BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '当日采样量',
  all_time_count BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '累计采样量',
  hour_stamp INT UNSIGNED NOT NULL COMMENT '小时时间戳（精度到小时，如2024052014）',
  day_stamp INT UNSIGNED NOT NULL COMMENT '日期时间戳（精度到天，如20240520）',
  UNIQUE KEY `uk_collector_time` (`collector_id`, `hour_stamp`, `day_stamp`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT '采集器采样计数表';

• 提前初始化每日/每小时的计数行，避免运行时插入唯一键冲突

多实例一致性保证 #

• 计数同步采用原子加操作：Redis用HINCRBY命令，数据库用UPDATE collector_sampling_count SET hourly_count = hourly_count + 增量 WHERE 条件的原子更新语法，避免多实例写入计数丢失
• 采样上限校验优先以存储层的全量计数为准，本地计数仅做预聚合和采样触发判断，不会出现超限问题

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