项目总结

1.订单里程碑

彩票订单在生命周期中，有很多重要历史事件，如下单、预订、出票等。可以定义出所有重要的历史事件，并在相关事件发生时记录日志，以方便关注订单的重大事件。彩期里程碑同订单里程碑。

2.操作的原子性和可回溯性

3.追号(套餐)子订单的生成策略

在彩期开期时，触发生成子订单及明细，这样做的好处是避免了在下单时生成大量的子订单及明细，同时也避免了彩期停售（春节）对追号的影响。

4.消息有序性方案线上事故

方案原理：为保证某一类型的消息执行的有序性，采用如下方案：在处理某一消息时，依据created检测此消息之前生成且未处理结束的消息，如果有，则不执行，延迟到下次遍历投入线程池后再做处理，通过这种方式保证了先生成的消息先处理。线上事故：生产消息的速率不变，消费消息的线程因为某些原因处理不及时，导致积压的消息越来越多，处理越来越慢。原因：对于某一类型的消息，消息1，消息2，消息3。。。。。。。消息1、消息2、消息3投入线程池，并发处理，消息2的处理线程发现消息1处理未完成，所以延迟不做处理，因消息2未做处理，消息3及之后投入的此类消息都延迟处理，积压越来越多，因为遍历程序从小到大依次遍历，所以遍历一次实际上只处理一条消息。 解决方案：对于此种消息有序性方案的使用有一前提，消息的生产速率远远慢于消息速率。

5.追号汇总的无状态性

原有方案：追号父订单依赖消息进行汇总，消息记录了关联的子订单，汇总的手段依赖

于关联的追号子订单的相关状态。

现在方案：追号父订单依赖消息进行汇总，消息记录了关联的子订单，汇总的手段并不依赖于关联的追号子订单，而是直接汇总当前的相关状态。

6.多代理商的支持

在预订时，根据策略选择并确定代理商，在预订失败（明确的预订失败或网络等原因导致的失败）或出票失败（明确的定义）时，可改变代理商，在出票成功后代理商不可更改。

代理商的关闭分为两个级次：1.禁止预订，即关闭之后不会向此代理商投注。禁止预订后仍然会从代理商处取得赛果、奖金等级和中奖名单等。2.完全禁止的级别高于禁止预订，完全禁止会检测是否存在出票成功（或有可能出票成功）的订单，如果有，无法禁止，如果无，则禁止，禁止后不会从此代理商取奖金等级、赛果和中奖名单等。3.禁止一切，除了2之外，所有未出票成功的包括支付未预订和已预订未出票的一律切换到其他的接口。

对于多代理商，未完全禁止的代理商，必须全部取得赛果并对比一致后，方可以去取奖金等级，奖级等级完全一致后可以去取中奖名单，可以手工修改单个代理商的赛果和奖金等级，也可以手工去重新获取名单。

获取到代理商的中奖名单后，即进行算奖比对，中奖的优先处理，只对对比不一致的提供手工修改的功能，当存在大量对比不一致的，可提供重新获取名单的功能，获取到中奖名单，对于对比一致的不做处理，对比不一致或者未比对的重新处理。运营需要手动结期，手动结期时会对未中奖订单进行计算金额对比，无问题后奖结束。

7.代理商的选择策略

根据预订、出票和彩期信息综合打分。

每个代理商的出票时间、出票截止时间、出票反馈时间等都不一致，可以根据不同的策略，如设置一个主代理商、或者总取最晚时间等的方式来处理

8.支付方式

支付方式可以手动设置，前台的显示依赖于后台的缓存等。

9.连接池获取不到连接，得到的总是空闲连接

1.找错，看连接池的配置，是不是连接池没有配置启动Evictor，将闲置的连接及时清除，而DB管理端将长时间未访问DB的连接置为闲置（参见技术总结）。

2.查找是不是有的连接没有释放，某个应用在使用完连接后，没有close

3.侦测DAO层方法的执行时间，看一下是不是某个SQL长时间未执行完毕