之前在讲RPC通信的各种好处，特别好用，但是RPC并不是万能的，也并不是适用于各种场景的，因为他是同步的；现如今很多场景下的调用都是异步的，系统A调用B后，并不需要知道B的结果，而且对B的结果无所谓，甚至你B挂了都无所谓，那么这个时候使用消息队列是十分OK的。
最简单的场景就是发送短信和email，主机不需要知道是否发送成功与否，就算失败了，哪怕再发一次也无所谓。
常见的MQ主要有JMS，RabbitMQ，ActiveMQ，Kafka以及RocketMQ，值得一提的是RocketMQ是阿里出的开源消息队列，很好用噢。
简单来说MQ可以支持点对点，点对多，订阅模式的各种消息，非常使用。举个非常我们自己使用过的例子，我们每周一三五的凌晨会有运维人员手动来执行一些数据操作，每个操作的实际大约20分钟，任务有先后顺序，执行完后需要查看上一个操作是否完毕再进行下一个操作，这样导致运维人员会很累，所以后来采用MQ来做这些任务，定时任务开始运行后，那么每个任务完成后只要调用对应的MQ就能达到人工的效果。一举两得。
关于消息队列的一些文章在之前都有写过，具体可以参考以下链接：
RabbitMQ 一二事(3) - 订阅模式（微信公众号模式）的应用
RabbitMQ 整合Spring 实现多客户端发送消息队列
分布式系统的数据一致性（在这里先不讲事务的一致性，后面会讲）
当数据被分在多地存储的时候，那么数据被读取的时候的一致性对用户是需要做保障的。这里分为强一致性和弱一致性
强一致性：保证用户不论何时何地，在华北还是华南，中国还是美国，同一时间访问到的数据是一致的，并不会出现差异性，这样的做法其实不多，消耗代价十分绝大，对运维团队的考验也十分严格。
弱一致性：保证用户访问数据的速度是OK的，但是数据内容可能随着时间的不同地点的不同会有差异。比如我在公司VPN环境下访问到的一些电商数据基本是实时的，更新速度很快。而我在下班以后在家访问却发现白天发布的数据并没有更新，需要在凌晨访问的时候数据才会更新过来，这样的做法就是数据的持续更新，服务端不会在乎客户访问的内容如何，虽然有时间地点的偏差，但是保证你能够访问到即可。