互联星空计费系统设计和海量计费的实现 (转载)

互联星空计费系统设计和海量计费的实现

互联星空系统上每月发生上百万条消费记录（四川的数据），这里的消费记录包括本地消费（包括宽带消费-BIMS）和异地跨省消费（与其他省平台通信）和与SP平台发生异步扣费请求的消费，情况复杂，又要求交易的实时性，所以对于计费系统地设计和满足海量计费要求（设计指标为每月3千万条详单记录），在设计上是一个不小的挑战。这里既要兼顾效率，还需要满足异步扣费的同时实现实时计费和满足跨域跨平台的事务性所以在设计上也需要特殊的结构才行。

–支持海量用户（千万级）

–支持实时计费（最大延时4-6秒）
–支持漫游计费（最大延时6-10秒）
–实时帐务数据同步（最大延时10秒）
–失败恢复（最大恢复时间10-16秒)

----------------------------------------------------------------------------------

下面是计费系统的结构图





在这里计费专门部署在计费服务器上，提供了WebService,Remoting,Radius(这个没用)三种方式的接口，这些接口直接把Web发过来的计费请求通过BizTalk Server缓存起来，一旦记入BizTalk成功马上返回true，提示Web计费成功了。这个时候就向计费锁定表插入记录。这个过程相当的快，所以很快就能返回，客户感觉马上就计费成功了可以消费了，但是事实上并没有立即写入详单表，当BizTalk处理到这条记录的时候会调用数据库服务器上的一个Remoting接口，把锁定表里的锁定记录入详单。这样子就实现了一个计费流程。

这里使用Biztalk作为中间件来保障计费流程的事务性，因为Biztalk具备超长事务的能力，可以跨月回滚数据，所以基本上可以杜绝掉单的情况。

这里可能会有疑惑为什么要用一个锁定表？锁定表是用来处理异步消费的时候用的，因为异步消费需要的到SP端的认证，还有的就是比如看电影，看了一半网络断了事不能给用户计费的，这个时候就需要用锁定表预锁定一部分金额，当实际消费达成，得到SP的确认的时候在根据实际消费进行扣费，而这一部分操作都是在后台默默地进行，因为用户在点消费的时候已经返回了，所以不会感觉到缓慢，根据实测，消费到入单的延时在2秒以内。

Biztalk在这里实际上可以用MSMQ替代，因为现在为止从来没回滚过，要是那天回滚了的话，估计电信就要抓狂了：}

而且这玩意儿也很贵，好几十万那。

摘自：亚历山大