平时Portal计费系统跑得稳，一到开业活动、促销秒杀、大型会议集中上线，瞬时几千人同时认证付费，系统就开始喘。很多人以为瓶颈在认证，其实更隐蔽的是计费明细的落库。明细慢一秒，丢的不是一秒的账，是一批说不清的缺口，活动结束谁都补不回来，因为漏的那笔根本没留下痕迹。
并发认证和明细计数是两笔账
认证说支持多少人同时在线，说的是连接能力；计费要在每一次上线、每一笔扣费实时写明细。两者压力不同步，认证扛住了，明细写入跟不上，就会出现上线成功但计费没记、或者计费记重。压测时不能只看认证并发数字，要把明细落库延迟一起压，看高峰期写不写得进、丢不丢。很多厂家演示只秀认证并发，不秀明细写入，因为你一压明细就知道短板在哪，他们心知肚明。
明细丢了最难补的是来源
计费明细一旦在高峰漏写，事后想补极难。因为漏的那笔没有记录，你不知道谁少算了多少，只能拿支付流水反推，而支付流水只到商户单号，到不了单笔上网时长。所以明细落库宁可慢一点带队列，也不能丢了不报。带缓冲的异步写入加落库确认，比追求极致同步速度稳得多。落库确认要做到：写成功才认账，写失败进重试队列并告警，绝不静默丢弃。静默丢一笔，月底就是一笔永远对不上的差，谁都解释不了。
活动前按峰值留余量
很多项目按平时平均并发配资源，活动当天被打穿。配置时要按活动预估峰值留余量，数据库连接、写入队列、缓存都按峰值估，而不是平时。曾经有商场开业按日均配，开业前两小时集中上线，计费明细开始丢，活动结束补了两天账。余量是为峰值买的保险，活动就那么几天，为几天多配的资源比事后补账的人力便宜得多。预估峰值还要留缓冲，别卡着上限配，峰值往往比预估再高两成，缓冲就是给意外留的。
限流和排队比崩溃好
峰值实在超过设计，与其让系统崩，不如在Portal侧做温和限流或者排队，让用户感知到稍等而非失败。计费侧则把写入削峰填谷。限流是保护账本完整性的手段，账算准比秒开更重要，活动体验差一点能解释，账对不上没法解释。限流阈值要可配，活动前调高、活动后调回，别让限流自己变成常态瓶颈。排队也要给用户明确进度，不是转圈圈，否则投诉从账本转到体验，换个地方一样烦。
写入队列要可观测
异步写入不是丢给队列就完事。队列长度、积压时长、消费延迟要可观测，高峰期一眼能看到是不是快堵了。很多项目队列默默积压，直到对账才发现少了几天明细。可观测才能在高并发时主动加资源，而不是事后补。观测面板要在活动期间有人盯，告警要能直接找到值班人，别做成没人看的摆设。
明细要做幂等防重
重试补录最怕重复写。同一笔上线事件要有唯一标识，写了就标记，重试时幂等跳过。否则网络抖动触发三次重试，计费记三倍，比丢更糟。幂等是明细可靠的后半句，和落库确认一样重要。唯一标识要带业务主键而不是靠时间，时间可能重合，业务主键才真唯一，这一点设计时就要钉死。
容量演练要贴近真实模型
压测别用平均模型，要用真实分布：哪类账号多、哪个时段尖。拿真实模型跑，才能暴露真实瓶颈。用均匀模型压，峰值特征被抹平，上线照样被打穿。演练模型贴近真实，配置才有参考价值，否则压测报告漂亮、线上该崩还崩。
活动保障要有值班和预案
大活动当天不能只靠自动化，要有人盯监控、有预案处理写库延迟尖峰。预案写清：延迟超阈值加什么资源、限流开到多少、掉单怎么补。没人盯，再好的可观测也救不了当场。活动保障是人和系统的配合，不是买了配置就完事。
明细落库要和业务主流程解耦
计费明细写入别和业务主流程绑死，主流程卡了明细也跟着卡。做成独立可靠的后台管道，认证和计费主链路只发事件，写库异步消化。解耦后主流程再快也不拖明细，明细积压也不影响用户上线。解耦是高并发下账本稳的结构前提，绑一起看似简单，峰值必炸。管道还要有背压和限流，上游发太快下游扛不住时温和降速，而不是丢数据。背压加落库确认，明细才既快又准，活动再猛账也不丢。
Portal计费系统的高并发，真正的考题不是撑住连接，是撑住账本。明细落库稳、丢了能补、峰值有冗余、超限能削峰、写可观测、记幂等，这六件事做到，活动再热闹账也是平的。账平了，活动才算真成功，否则热闹过后是一地对账的鸡毛。