之前的文章中我有谈到过我们有一个需求：对一些数据需要准实时效果，但这些数据往往是不能通过直接查询业务数据来反映的，大多都需要经过一系列复杂的运算才能体现出来,于时这些数据的实效性就是一个很大的问题。
我们一个业务数据点的触发，实际上会影响到多个数据指标的变化，每个指标数据都是一个具体的业务逻辑，如果将这众多的指标放进一个事务中执行显的不太可能，第一是执行时间，第二是随着处理过程过程的复杂，事务提交失败的可能性会增大。如果将每个点当成原子操作，那么如何保证最终的数据是完整准确，就是问题所在，即一个业务数据触发后，不允许出现一部分统计数据准确，有一小部分不准确的现象。
解决众多原子操作数据完整性的一个方案是将每个原子操作的处理过程全程记录下来，如果发现最后处理完成后，有没有成功的，将用程序的方式回滚之前已经成功修改的数据。这种方案有两个缺点：
第一：回滚逻辑比较复杂；
第二：如果计算服务发现不可用，此时业务系统的数据将不能触发数据计算，最后导致这些数据无法参与计算。
解决方案：将业务系统数据发送给MSMQ，WCF封装成MSMQ形式，它会监听MSMQ，如果有消息收到就会处理。和原方案一样，将每个原子数据操作的结果记录下来，如果最终发现有一个失败，就会将此消息发送给异常消息队列，再由专门的服务对这些有计算失败的消息进行处理，异常处理服务根据消息处理日志就能够区分出哪些是需要重新计算的，因为有一些数据是已经计算成功过的，这样可以避免重复计算。同样由于MSMQ可选用磁盘化的存储，所以即使计算服务当时不在线，这些消息也会在服务正常启动后再次发送,避免数据丢失。
异步计算框架的结构：
1：异步计算代理，它负责接收业务系统提交的数据，然后提取任务配置信息，最后通过软负载方式，将消息发送给不同级别的计算服务进行运算。
2：一组计算服务，它们根据优先级分成高，中，低等等，高优先级的服务数量最多，比如是这样的方式高3，中2，低1。如果有100个请求，高优先级来运算，每个服务只需要处理不到40个讲求，如果中优先级来处理，每服务需要处理50个，最差的低优先级需要处理100次。
3：异常计算服务，处理前面的计算服务中，有计算出现错误的消息，如果此时再次失败，将消息进行持久化，供人工解决。
4：持久化存储，这里采用mongodb，我们在进行大量日记记载时能够获得最大的性能优势。
异步计算框架的数据流向图：
