17370845950

Java活动报名人数统计需准确记录、实时更新、安全并发、支持查询：建sign_up_record表存明细，活动表冗余total_signups并受控更新；实时计数用MySQL行锁或Redis INCR；报名前校验时间、重复、限额；每日对账补偿。

Java中实现活动报名人数统计，核心在于准确记录、实时更新、安全并发、支持查询。不是简单加1减1，而是要结合业务场景设计健壮的统计逻辑。

报名数据建模：区分“报名行为”和“统计值”

不要把报名人数直接存在活动表里做字段更新（比如activity.sign_up_count += 1），这容易引发脏读或丢失更新。正确做法是：

• 单独建sign_up_record表，记录每次报名的用户ID、活动ID、时间、状态（如“成功”“取消”）
• 统计值（如total_signups）作为冗余字段存在活动表中，但只通过受控逻辑更新
• 提供定时任务或事件驱动方式，从明细表聚合刷新统计值，用于报表或大屏展示

实时计数更新：用数据库行锁 or Redis原子操作

用户点击“报名”时需立即反馈当前人数，推荐两种轻量方案：

• MySQL行锁：对活动记录加SELECT ... FOR UPDATE，查出当前人数 → +1 → 更新字段 → 提交事务。适合QPS不高、强一致性要求的场景
• Redis原子计数：用INCR activity:1001:signup，天然线程安全、毫秒级响应；再异步落库同步明细表。适合高并发、允许短暂最终一致的场景

人数校验与防刷：报名前必做的三件事

统计准不准，关键在入口控制。每次报名请求必须检查：

• 活动是否在报名时间内（start_time ≤ now ≤ end_time）
• 用户是否已报过该活动（查sign_up_record where user_id=xxx and activity_id=yyy and status='success'）
• 是否超限（当前人数 DECRBY activity:1001:quota 1，返回负数则拒绝

取消报名与数据一致性处理

用户取消报名不能只减人数，还要保障状态可追溯：

• 将原报名记录status改为canceled，而非物理删除
• 人数回退使用DECR（Redis）或带条件的UPDATE（如SET sign_up_count = sign_up_count - 1 WHERE id = ? AND sign_up_count > 0）
• 补偿机制：每日跑一次核对脚本，比对明细表有效记录数 vs 活动表统计值，自动修复偏差

基本上就这些。统计本身不复杂，但容易忽略并发、校验、回滚和对账环节，补全这四点，系统才真正稳得住。