Tip: 此篇已加入.NET Core微服务基础系列文章索引
一、预备知识：数据一致性关于数据一致性的文章，园子里已经有很多了，如果你还不了解，那么可以通过以下的几篇文章去快速地了解了解，有个感性认识即可。
（1）左正，《保证分布式系统数据一致性的6种方案》
（2）成金之路，《分布式系统的数据一致性解决方案》
（3）E_Star，《分布式环境下数据一致性的设计总结》
必须要了解的点：ACID、CAP、BASE、强一致性、弱一致性、最终一致性。
CAP理论由加州大学伯克利分校的计算机教授Eric Brewer在2000年提出，其核心思想是任何基于网络的数据共享系统最多只能满足数据一致性(Consistency)、可用性(Availability)和网络分区容忍(Partition Tolerance)三个特性中的两个（由此我们知道在分布式系统中，同时满足CAP三个特性是不可能的），三个特性的定义如下：
C：数据一致性（Consistency）：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性（Strong Consistency）（又叫原子性Atomic或线性一致性Linerizable Consistency）
A：服务可用性（Availability）：所有读写请求在一定时间内得到响应，可终止、不会一直等待
P：分区容错性（Partition-Tolerance）：在网络分区的情况下，被分隔的节点仍能正常对外服务
强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。=> 在传统单体式应用中，大部分都是强一致性的应用，想想我们写过多少工作单元模式的Code？
弱一致性：系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。
为保证可用性，互联网分布式架构中经常将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。
在微服务架构中，各个微服务之间通常会使用事件驱动通信和发布订阅系统实现最终一致性。
更多背景知识，还是得看上面列出的参考文章，这里不再赘述。
二、MassTransit极简介绍MassTransit 是一个自由、开源、轻量级的消息总线, 用于使用. NET 框架创建分布式应用程序。MassTransit 在现有消息传输上提供了一组广泛的功能, 从而使开发人员能够友好地使用基于消息的会话模式异步连接服务。基于消息的通信是实现面向服务的体系结构的可靠和可扩展的方式。
官网地址：，GitHub地址：https://github.com/MassTransit/MassTransit （目前：1590Star，719Fork）
类似的国外开源组件还有NServiceBus，没有用过，据说MassTransit比NServiceBus更加轻量级，并且在开发之初就选用了RabbitMQ作为消息传输组件，当然MassTransit还支持Azure Service Bus。类似的国内开源组件则有园友savorboard（杨晓东）的CAP，这个我会在MassTransit学习结束后去使用使用，CAP在GitHub上已经有了超过1000个Star，是NCC的几个千星项目之一。另外，张善友大队长在他的NanoFabric项目中推荐我们使用Rebus和Ray，如下图所示：