千万短信发送量的架构设计

客户端将计费信息（扣的条数、费用…..）提交到计费子系统，计费子系统收到请求，将数据缓存到本地Cache(可以是内存、或者其他Cache，本地缓存数据结构是Key-Quue, key为用户标识，Queue用于存放用户计费信息)，并且通知任务分配服务为其分配一个线程处理扣费信息（只分配一次，以后这个线程就出来这个用户），一条处理扣费线程可处理多个用户,但一个用户不能分配到多个处理扣费线程中。通知完后立即返回响应。（由于只有分配一次，所以只有第一次稍后会慢个零点几毫米，后面几乎响应耗时为0）。

  处理扣费服务启动后，将根据自己持有处理用户Key,去从本地缓存中获取到该用户Key引用的队列实例，直接从实例中读取该用户的计费信息进行扣费即可，为了处理速度快，可以从队列中批量读取，合计后一次性从数据库中扣除。扣除完成后，更新本地余额缓存。

 

接口设计：1.提供一个计费接口

              2.提供一个获取余额接口

协议类型：通信协议建议采用Socket。

客户校验余额：直接获取内存中的余额，避免对库开销太大。

分布式集群：对本地缓存和任务分配服务设计成共享，即可分布式和集群。

Queue：建议所使用实现“无等待 (wait-free)”算法算法的队列。

处理扣费服务：对处理的用户数量可配，在用户扣费信息量非常非常大时，可设置成一个线程一个用户，用户量少时可以一个线程处理多个用户，以节省资源。（也可以写一个简单的算法去只能判断一下当前的用户计费信息量）

下面看下架构的草图