Java并发计数器架构设计：百万用户活动限流方案选型咨询

选型1：单体架构 + AtomicInteger #

• CAS相关问题：AtomicInteger基于CAS（Compare-And-Swap）实现原子计数，不会出现数据不一致的问题，但高并发下会有CAS自旋重试的情况——大量线程竞争更新时，失败的线程会循环重试，消耗CPU资源。
• 100万量级的影响：100万请求量级下，CAS的自旋压力处于可控范围，不会引发致命问题。当请求量级达到千万级及以上，且并发线程数超过数千时，CAS重试次数会急剧上升，CPU使用率会大幅飙升，可能导致服务响应延迟增加。

选型2：单体架构 + synchronized #

• 运行稳定性：使用synchronized可以完全保证计数的原子性，不会出现数据不一致问题，能稳定运行。
• 性能注意点：synchronized是独占锁，同一时刻仅一个线程能进入代码块更新计数，高并发场景下会导致大量线程阻塞等待。如果并发请求峰值在每秒几千级以内，synchronized可以稳定支撑；但峰值更高时，服务吞吐量会明显下降，性能表现不如AtomicInteger。

选型3：微服务架构方案 #

Redis INCR方案 #

Redis的INCR命令是原子性操作，非常适配这类分布式计数场景：用户点击时调用INCR reward_key，判断返回值是否≤1000000，是则发放奖励，否则提示“抱歉”。该方案性能极强，可轻松支撑百万甚至千万级并发请求。

其他微服务可选方案 #

• Redisson分布式锁：如果需要绑定用户信息等额外业务逻辑，可使用Redisson的可重入分布式锁锁定计数更新流程，保证原子性。但性能略逊于直接使用Redis INCR，适合有复杂业务逻辑的场景。
• ZooKeeper分布式锁：借助ZooKeeper的节点特性实现分布式锁，能保证计数一致性，但性能比Redis方案差，适合对一致性要求极高但并发量不大的场景。

MySQL实现可行性 #

可以用MySQL实现，但需注意原子性保障：

• 方案1：直接使用UPDATE语句：UPDATE reward_count SET count = count + 1 WHERE count < 1000000，通过判断受影响行数确定是否发放奖励（受影响行数为1则成功，0则已达上限）。InnoDB引擎下的UPDATE语句是行级锁，能保证原子性。
• 方案2：事务+行锁：先通过SELECT count FROM reward_count FOR UPDATE加行锁，再更新计数，最后提交事务。这种方式需注意锁的范围，避免出现锁冲突。
• 缺点：MySQL性能远低于Redis，高并发场景下（如每秒上万请求）会出现锁等待、连接池耗尽等问题，不适合百万级高并发的推广活动场景。

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