5G消息综合计费方案研究_赵鸿.pdf

2023年 第2期0引言随着5G消息开始规模化商用，在支持5G消息的终端占比不足的背景下，形成了5G原生消息、5G阅信、5G视信等多模式消息共存，以实现全终端业务覆盖。针对CSP（Chatbot服务提供商）的5G消息平台中预付费企业账户多模式5G消息的发送计费问题，本文分析了多模式5G消息发送的背景和特点，阐述各种消息模式的判别方法。15G消息计费背景5G消息为企业应用和个人之间可信联系带来了全新的方式。在支持原生5G消息终端覆盖率不足的情况下，随着5G消息技术发展，形成了面向原生支持UP2.4协议终端的5G消息、面向主流安卓终端的5G阅信（基于文本短信的智能解析技术）消息、面向其他终端的5G视信（多媒体消息）等多模式全终端消息覆盖方案，以满足商用要求，并产生商业价值。CSP接入运营商5G消息通信网关，以Chatbot的形式，为企业提供5G消息相关服务，使企业业务通过5G消息直接触达终端。在商业模式上，5G消息向企业侧收费，终端侧免费。CSP 5G消息平台在面向全终端5G消息覆盖场景时，针对企业预付费账户，其通信计费面临如下挑战：a）单账户多模式计费。为了实现全终端覆盖，CSP 5G消息平台需实现5G原生消息计费、5G阅信计费、5G视信计费三种不同的计费模式。其中，5G原生消息又分为5G文本消息、5G多媒体卡片消息、5G会话消息三种子模式；5G阅信分为解析成功（多媒体卡片）、未解析成功（文本消息）两种子模式，不同模式单价不同、计数方法不同。b）单账户大并发计费。单账户大并发主要体现在同一个企业账户会同时运营多个Chatbot、同一个Chatbot会瞬时发送大量多模式消息两个方面。另外，会话消息是由终端用户主动上行并触发，兼具随机性和集中性的特点。多消息模式交织发送导致单预付费账户并发计费成为常态。c）单账户统一计费。常规方案是将各种消息模式设计成独立的计费单元，企业客户自行为每个计费单元单独充值，系统单独计费。该方案虽然简化了系统设计，但不利于企业侧业务连续性。统一计费要求多消息模式共享同一个账户总余额，客户只需关注其账户总余额是否足够即可。d）单账户异步计费。根据行业标准，消息发送成功才能计费。一条消息发送后，需异步等待终端返回接收（解析）状态回执后，才能确定该消息是否发送成功，所以，消息的发送和状态确认是两个异步过程，必然出现时间差，最长可达72 h，甚至部分消息最终没有返回状态回执。这就要求CSP 5G消息平5G 消息综合计费方案研究赵鸿1，高比布2（1.上海大汉三通通信股份有限公司，上海市201203；2.复旦大学工程与应用技术研究院，上海市200433）摘要分析多模式5G消息发送的背景和特点，阐述各种消息模式的判别方法。针对消息发送后状态回执的异步性和延迟性，提出一种消息发送前预计费和发送结果修正计费相结合的综合计费方案，确保5G消息计费的及时性和非负性。在此基础上，研究和设计一套面向5G消息平台的计费装置，并详细阐述实现方法，用于指导实际生产。关键词5G消息；计费；Redis；分布式系统技 术 交 流102023年 第2期台在实现异步计费的同时，要保证该账户余额非负。25G消息计费方案CSP 5G消息平台承载多企业账户、多Chatbot同时运营，并且同一个企业账户可能有1到多个Chatbot在同时发送消息。面对每条消息计费场景，平台需解决的主要问题有：a）准确判别最优消息计费模式。b）实现消息的高并发计费、异步计费、准确计费。c）确保账户余额非负。d）利用尽量少的服务器资源达成上述目标。显然，使用传统数据库加锁等方式不能有效支撑数据表中单记录（即单账户余额）每秒数万次甚至更高的更新频率。另外一种方法是将每条消息的消费金额进行队列排队，通过批量扣减来达到计费目的，虽然该方法能大幅度降低数据库更新频率，但不能解决异步计费问题，会出现账户当前可用余额判断不及时，导致账户余额瞬间远小于零的情况，造成经济损失。综上所述，需要设计一种全新的软件装置，来达到高并发、分布式、高精准度、异步、低资源利用率条件下的计费目标。2.1消息计费模式判别为了保证消息能完整覆盖全网终端，企业账户在5G消息平台制作待发送消息模板时，需准备一套包括原生5G消息以及配套的5G阅信和5G视信，组成全终端消息模板。发送时，5G消息是下发主体，5G阅信或5G视信是配套的回落模板，回落模板二选一。运营商网关在5G消息发送失败后，会使用配套的回落模板重试补发。从终端体验效果来排序，优先选择5G消息+5G阅信配套回落，其次是5G消息+5G视信配套回落。下发消息模板时，由5G消息平台根据终端能力选择使用何种搭配模式下发，不同模式的消息计费模式不同。5G消息计费模式判别及下发总体流程如图1所示。在发送前实时判别每条消息的配套模式，以达到终端体验和消息成功率的最大平衡。终端是否支持5G阅信是判别的关键，5G阅信是主流安卓终端支持的短信增强解析技术，支持在终端手机上携带已向终端厂商报备过URL链接的传统短信，自动提取URL（统一资源定位系统）报备信息，自动解析为可交互的富媒体卡片进行展示，以提升终端体验。当前技术可通过手机号码单向检索其所属终端操作系统是否支持5G阅信。利用该能力，CSP 5G消息平台可先判断终端是否支持5G阅信，支持则使用5G消息+5G阅信回落模式下发，不支持则使用5G消息+5G视信回落模式下发。运营商5G消息网关会将最终的发送消息模式及终端接收状态异步返回到CSP 5G消息平台。2.2消息发送预计费每条全终端消息的实际消费金额，需要异步等待运营商网关返回的消息最终发送模式及对应发送状态报告后才能确定。另外，为了避免在大并发场景下企业账户的余额为负，CSP 5G消息平台设计了预计费方式，在消息发送前扣除该消息消费额度。a）5G消息+5G阅信：使用5G消息和5G阅信中单价高者作为本次预计费金额。b）5G消息+5G视信：使用5G消息和5G视信中单价高者作为本次预计费金额。2.3消息实际计费5G消息实际修正计费流程如图2所示。消息发送后，CSP 5G消息平台异步等待运营商通信网关的消息发送状态报告回传后，便可确定该消息的最终发送模式及发送状态；再与预计费金额对比，判断是否需要修正计费误差，完成实际计费。如果消息发送失败则返还预计费金额。另外，如果平台等待消息状态报告回传的时长超过72 h，则也认为该消息最终发送失败，触发平台返还预计费金额。35G消息计费实现3.1计费装置总体设计思路a）利用Redis，实现账户余额的内存化快速判断，避免大并发查询数据库。b）利用Redis，实现分布式消息的消费金额内存化、原子化累加（减）操作，实现并发计费，同时兼容并发充值。c）设计后台分布式调度任务，定期执行，完成消费金额定期从Redis持久化到数据库、账户新余额从数据库同步到Redis。技 术 交 流112023年 第2期图15G消息计费模式判别及下发总体流程d）面对大并发账户，可一个账号独享一个Redis集群。理论上只要一个账户的通信并发数小于Redis集群支持的最大并发即可，即单企业账户支持的最大计费并发数，取决于一个Redis集群的最大并发数。根据各云商Redis集群产品指标，均支持并发量10万以上，可以满足商用需求。3.2计费装置实现方法5G消息计费装置的总体结构如图3所示。Redis中，每个账户有两个Key，一个存放账户余额（Key1），一个存放账户临时消费金额（Key2）。临时消费金额是指当前账户已消费但还未持久化到数据库的消费额度。Key1为普通key-value数据存储，用于内存化查询；Key2为String数据结构，使用INCRBY/DECRBY命令对数据进行原子增值/减值操作。另外，在Redis中还为每个账户创建一个“余额变更队列”。该队列存放该账户日常除消费外的余额变更记录信息，包括：a）客户主动充值加款。b）管理端手动变更账户余额：运营管理员操作图25G消息实际修正计费流程技 术 交 流122023年 第2期加款、退款及其他情况下需要手动增加、扣减账户余额的场景。c）消息修正计费数据：包括消息状态回传后的实际修正计费金额，及消息等待状态超时后的返还金额。当上述操作发生时，将对应变更信息放到Redis账户“余额变更队列”中。该队列可表示为Q=（q1，q2，qn），其中，qi（1in）代表一个余额变更对象，包含变更类型、变更时间、操作人等基本信息，还包含变更额度，表示为Quota。当发生账户充值、加款等操作时，Quota值大于0；当发生账户扣费、退款、修正计费等操作时，Quota值小于0。企业账户发送消息，触发账户余额预计费逻辑。账户余额预计费算法见表1。接收到消息状态报告，或者消息等待状态报告时长超过阈值，触发实际修正计费。根据消息实际下发状态和下发模式，计算出该消息的修正金额。修正金额为0则说明预计费正确，无需修正计费；为负则说明需要返还，将修正计费信息写入账户“余额变更队列”中。a）实际下发状态失败，则该消息预付费金额需全部返还。b）消息下发状态成功，但实际下发模式与预计费模式（价高者）不一致，返还差价。c）等待消息状态报告时长超过最大阈值，则该消息预计费金额全部返还。后台调度任务，面对每个账户，定期（1 min）执行。账户临时消费金额持久化及新余额同步执行过程见表2。CSP 5G消息平台的后台调度任务，在任意时刻，每个账户只有一个线程在处理，保证了单账户串行处理。同时也可以看到，账户充值、消息修正计费返还等余额变更操作，最大生效时长为1 min。3.3后台任务实现框架后台分布式调度任务的目标，是实现Redis中缓存数据定期批量持久化以及账户余额数据同步到Redis。在分布式集群结构环境中，要保证数据同步准确，要求每个账户同一时刻只能被一个后台任务执行，同时还要保证各任务进程运行的无状态性。后台任务实现有两种实现思路。a）master slave模式。只有master进程在执行后台任务，如果master进程失效，则由其他slave进程争抢master角色。争抢到的进程接管后台任务，执行任务时判断自己是否是master，如果不是则不执图35G消息计费装置技 术 交 流132023年 第2期表2账户临时消费金额持久化及新余额同步2.if临时消费金额 0:then执行Redis：DECRBY账户key2临时消费金额；update：数据库中该账户余额=数据库中该账户余额-临时消费金额获取Redis中账户“余额变更队列”，合并数据并持久化到数据库3.if Redis中该账户“余额变更队列”有数据：then取出队列Q中指定数量N的数据，合并余额值：Sum_quotaNi=1QiQuotaupdate：数据库中该账户余额=数据库中该账户余额+Sum_quota同步账户最新余额到Redis4.Redis中该账户余额key1值=数据库中该账户余额获 取Redis中 账 户 临 时 消 费 金额，持久化到数据库1.临时消费金额=Redis中该账户临时消费金额（key2的值）程序名程序语句表1账户余额预计费获取账户余额2.if Redis中存在该账户余额key1:then账户余额=Redis中该账户余额key1的值else账户余额=数据库中该账户余额；设置Redis中该账户余额key1的值=账户余额获取账户临时消费金额3.if Redis中存在该账户临时消费金额key2:then账户临时消费金额=Redis中该账户临时消费金额key2的值else账户临时消费金额=0账户余额预计费4.if账户余额账户临时消费金额+本条消息消费额度:then原子操作key2，执行Redis命令：INCRBY key2本条消息消费额度else禁止发送，账户余额不足获取本条消息消费额度1.本条消息消费额度=消息模板中单价高者的单价计费条数程序名程序语句技 术 交 流行。在2B业务中，账户数量规模不大的情况下，该模式可以较低成本使用，最少3台服务即可。b）分布式调度框架。由核心调度器负责账号分组，定期生成基于账号分组的任务分片，交由各任务142023年 第2期（上接第9页）的