核心思路是用ThreadLocal绑定商户ID实现线程级上下文隔离，并通过ConcurrentHashMap< String, AtomicInteger >为各商户维护独立原子计数器，超阈值拒绝请求；同时落实Redis分片、DB路由、线程池隔离等物理通道隔离措施，并在finally中清理ThreadLocal和计数器。
核心思路是：用线程局部状态标识商户上下文，配合原子计数器控制结算通道的准入与释放，避免跨商户操作互相干扰。
绑定商户ID到线程生命周期
在结算请求入口（如Spring MVC拦截器或网关Filter）中，提取请求头或JWT中的merchantId，并存入ThreadLocal<String>。后续所有结算逻辑（库存校验、价格计算、优惠叠加）都从该ThreadLocal读取商户标识，不依赖参数传递或全局变量。这样即使同一用户同时结算A店和B店的购物车，两个线程也天然隔离，不会混用商户配置或缓存键。
为每个商户分配独立的原子通道计数器
使用ConcurrentHashMap<String, AtomicInteger>维护商户级计数器，key为merchantId：
- 每次进入结算流程前，执行counter.incrementAndGet()，获取当前通道序号
- 若返回值 > 预设阈值（如3），说明该商户并发结算过高，直接拒绝或排队，防止压垮其专属服务实例
- 结算完成或异常退出时，必须调用counter.decrementAndGet()，确保计数器准确回落
物理通道隔离的关键落地点
通道隔离不止体现在计数上，更要落实到实际资源调用：
- Redis Key分片：购物车数据按merchantId:userKey组织，避免不同商户共用同一个Hash结构引发锁竞争
- 数据库连接路由：结合ShardingSphere或自定义DataSource路由规则，将同一merchantId的结算事务始终打到指定读写实例
- 优惠计算线程池隔离：为高流量商户（如“旗舰店”）单独配置线程池，不与其他商户共享corePoolSize和队列
异常场景下的状态清理保障
ThreadLocal可能因线程复用残留旧值，AtomicInteger可能因未捕获异常导致计数滞留。必须做两件事：
- 在拦截器finally块中显式调用threadLocal.remove()
- 结算主流程外层包裹try-catch-finally，确保decrementAndGet执行，必要时加日志告警未清理的计数器
