Campaign Message Center Design - luohuazju/superduty GitHub Wiki

整个设计如上图

1. 管理员会调用我们后台管理页面，添加Campaign事件，调用时间毫秒级，相对稳定（多机负载均衡）。这类事件一般有如下要素：

   a. 时间要素，比如 圣诞节的前一天；Black Friday打折的前一周的每天中午12点等等

   b. 地理位置要素，比如，只发送给正在店里面的客户；只发送给某个门店的客户，告诉他这个门店的打折信息；发送给某新开门店的周边4个门店的客户，告诉他们有新门店开张，打折；

   c. 和手机信息，客户信息相关的要素， 比如 发送给购物车中有某商品的客户；发送给iOS5的用户，告诉他们iOS的东东打折

   这一步的接口调用时间不长，只是存储这些规则在业务数据库中。

2. 存储规则进数据库，这里有用到MYSQL（主备）和CASSANDRA(主备)数据库，调用时间毫秒级，相对稳定。

3. 产生Campaign的同时，异步调用调度接口，产生一条相关调度任务（任务本身是耗时操作，所以是采用调度接口，且远程调用接口HTTP链接，返回时间不一定，所以采用异步调用），调度接口本身（多机负载均衡）

4. 存储进MYSQL数据库（主备）

5. 到了制定的触法条件，比如到了每天的12点，或者圣诞节前一天，调用任务开始计算。（这里是耗时操作，业务规则也主要集中在这里）

   比如这里就会去查询满足在店铺内的客户有2000个，购物车中有某商品的有500，其中是iOS的客户有100，最后决定把这100个放进下一步操作。

   也可能这里是取得数据库中所有安装这个品牌app应用的客户，200万个，直接放进队列

6. 队列服务器本身是多机负载均衡，如果有重启或者宕机，数据是存储在本机的文件中

7. 队列服务器中有各种任务，比如发送某商品打折信息给iOS的100个用户，那么consumer会调用对应的one to one信息发送程序，发送信息给apple的服务器。这个过程是不可控，依赖于网络和其它因素，一般需要几秒来完成，如果当时apple服务器或者网络不可用，网络忙，任务回回到队列，重新执行。

   如果是发送信息给200万个用户，会有业务逻辑，重新整理所有的手机ID，去掉重复，按照id的字母进行分类分组，1000个手机组成一条批量发送请求之后，发送给apple或者google。这里是1000条，1000条的批量执行。

   目前的执行情况是遇到发送给200万个用户的需求，10个consumer，每个consumer10～20个线程，大概能在20分钟之内发送出200万消息。

8. 调用第三方官方服务器，发送请求