简易购物车在高并发下通过ConcurrentHashMap+快照/增量文件双模式实现轻量持久化：内存用computeIfAbsent保证原子更新，文件写入分5分钟快照与实时delta日志，启动时先加载快照再重放日志，并通过预检限数、唯一ID幂等、临时文件写入及校验机制保障准确与可靠。

简易购物车在高并发场景下，不依赖 Redis 或数据库也能实现基本的持久化数量控制，关键在于用好内存集合 + 文件逻辑的轻量组合。核心思路是：用线程安全的集合暂存变更，再通过异步、分批、带校验的文件写入来保障数量准确，避免直接刷库带来的性能瓶颈和并发冲突。

用 ConcurrentMap 管理实时购物车状态

Java 中推荐使用 ConcurrentHashMap 作为内存层主结构，以用户 ID 为 key，商品 SKU 为子 key，value 存数量或简单对象。它天然支持高并发读写，无需额外加锁。

• 每个添加/修改操作都走 computeIfAbsent 或 merge 方法，保证原子性更新
• 删除时用 remove(key)，避免空指针或竞态残留
• 不建议用 get + put 组合，那是非原子操作，高并发下易丢数量

文件写入采用“快照+增量”双模式

纯内存不持久，必须落盘。但频繁写文件会拖慢响应，所以拆成两步：

• 快照模式：每 5 分钟或累计变更超 100 条时，将当前 ConcurrentHashMap 全量序列化为 JSON，写入 cart_snapshot_20260605_1430.json 这类带时间戳的文件
• 增量模式：每次变更同时追加一条日志到 cart_delta.log，格式如 2026-06-05T14:32:11|uid123|sku456|add|2，便于故障后按序重放
• 服务启动时先加载最新快照，再逐行回放 delta 日志中快照之后的操作，确保数据不丢

数量控制靠“预检+幂等写入”防超限

简易购物车常需限制单商品上限（如最多买 99 件）或总商品数（如最多存 200 件），不能只靠内存判断。

• 每次 add 前查当前数量，叠加后若超限，直接拒绝并返回提示，不进集合也不写日志
• 文件写入时对每条 delta 记录加唯一 ID（如 uid_sku_ts_seq），避免重复解析导致数量翻倍
• 可定期（如每小时）扫描 delta 日志，合并同 uid+sku 的连续操作，压缩冗余记录

异常恢复与轻量校验机制

文件系统不可靠，需主动兜底：

• 写快照前先生成临时文件 .cart_snapshot_20260605_1430.json.tmp，写完再 rename，防止中断导致损坏
• 每次加载快照后，用 sum(values) 校验总数是否合理（比如远超 200 就触发告警）
• delta 日志保留最近 7 天，过期自动归档压缩，避免无限增长