mirror of
https://gitcode.com/ageerle/ruoyi-ai.git
synced 2026-03-26 11:03:45 +08:00
affdc5e3a6
1.保存消息和计费逻辑存在耦合 2.修改计费逻辑： 按次计费被阈值限制：旧逻辑把 TIMES 分支放在 totalTokens ≥ 100 的大分支里，导致没到100 token时不扣费，违背“每次调用就扣费”的语义。 token累计不当：TIMES 分支只扣费不处理累计，同时在 totalTokens < 100 时不会进入任何TIMES逻辑，累计会无意义增长。 粒度不稳定：TOKEN 计费一旦达阈值就把 total 全扣完并清零，不利于对账与用户体验。 打印方式：使用 System.out.println，不利于生产追踪。 改动要点 1.新增独立方法 saveMessage(ChatRequest): 只落库。 publishBillingEvent(ChatRequest): 只发布异步计费事件。 保留组合方法 saveMessageAndPublishEvent(ChatRequest) 以便需要一行调用时使用。 调用处已改为“先保存，再发布事件” SseServiceImpl: 先 saveMessage，再 publishBillingEvent。 SSEEventSourceListener: 同上。 DifyServiceImpl: 同上。 2.计费模式分流： TIMES：每次调用直接扣费，不累计。 TOKEN：按阈值（100）批量扣费，保留余数，账单颗粒稳定。 保留余数：total = prev + delta；billable = floor(total/threshold)threshold；remainder = total % threshold。 日志替换：统一使用 log.debug。 结构更清晰、可维护。 所有金额计算统一用 BigDecimal，保留两位小数，RoundingMode.HALF_UP 按次计费：每次直接扣费（BigDecimal），边界转 Double 按 token 计费：按阈值批量结算，保留余数；费用=单价(BigDecimal)×可结算token数 1. 消息分类存储 用户消息：role="user", deductCost=null, totalTokens=本次token数, remark="用户消息" 系统账单：role="system", deductCost=实际扣费, totalTokens=计费token数, remark="TIMES_BILLING/TOKEN_BILLING" 2. 数据流程 用户发送消息 → 预检查余额 → 保存用户消息 → 发布计费事件 → 异步扣费 → 保存账单记录