[TOC]
第13章 消息队列思路
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。
引入消息队列
- 出现的问题：消息被处理的过程相当于流程A被处理。我们这里以一个实际的模型来讨论下，比如用户下单成功时给用户发短信，如果没有这个消息队列，我们会选择同步调用发短信的接口，并等待短息发送成功，这时候假设短信接口实现出现问题了，或者短信调用端超时了，又或者短信发送达到上限了，我们是选择重试几次还是放弃，还是选择把这个放到数据库。过一段时间再看看呢，不管怎样，实现都很复杂。
- 引入消息队列：我们可以将发短信这个请求放在消息队列里，消息队列按照一定的顺序挨个处理队列里的消息，当处理到发送短信的任务时，通知短信服务发送消息，如果出现之前出现的问题，那么把这个消息重新放到消息队列中。我们可以将发短信这个请求放在消息队列里，消息队列按照一定的顺序挨个处理队列里的消息，当处理到发送短信的任务时，通知短信服务发送消息，如果出现之前出现的问题，那么把这个消息重新放到消息队列中。
消息队列特性
- 业务无关：只做消息分发
- FIFO：先投递先到达
- 荣灾：结点的动态增删和消息的持久化
- 性能：吞吐量提升，系统内部通信效率提高
为什么需要消息队列
【生产】和【消费】的速度或稳定性等因素不一致
例如短信发送、 调用远程系统下订单、把用户请求搜集到队列里
消息队列的好处
业务解耦。一个事务只关心本质的流程，需要依赖其他事情但是不那么重要的时候，有通知即可，无需等待结果。
短信发送时只要保证放到消息队列中就可以了，接着做后面的事情就行。每个成员不必受其他成员影响，可以更独立自主，只通过一个简单的容器来联系。
对于我们的订单系统，订单最终支付成功之后可能需要给用户发送短信积分什么的，但其实这已经不是我们系统的核心流程了。如果外部系统速度偏慢（比如短信网关速度不好），那么主流程的时间会加长很多，用户肯定不希望点击支付过好几分钟才看到结果。那么我们只需要通知短信系统“我们支付成功了”，不一定非要等待它处理完成。
最终一致性。通过在队列中存放任务保证它最终一定会执行。最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。 当然有个时间限制，理论上越快越好，但实际上在各种异常的情况下，可能会有一定延迟达到最终一致状态，但最后两个系统的状态是一样的。
业界有一些为“最终一致性”而生的消息队列，如Notify（阿里）、QMQ（去哪儿）等，其设计初衷，就是为了交易系统中的高可靠通知。
以一个银行的转账过程来理解最终一致性，转账的需求很简单，如果A系统扣钱成功，则B系统加钱一定成功。反之则一起回滚，像什么都没发生一样。
然而，这个过程中存在很多可能的意外：- A扣钱成功，调用B加钱接口失败。
- A扣钱成功，调用B加钱接口虽然成功，但获取最终结果时网络异常引起超时。
- A扣钱成功，B加钱失败，A想回滚扣的钱，但A机器down机。
可见，想把这件看似简单的事真正做成，真的不那么容易。所有跨JVM的一致性问题，从技术的角度讲通用的解决方案是：
- 强一致性，分布式事务，但落地太难且成本太高，后文会具体提到。
- 最终一致性，主要是用“记录”和“补偿”的方式。在做所有的不确定的事情之前，先把事情记录下来，然后去做不确定的事情，结果可能是：成功、失败或是不确定，“不确定”（例如超时等）可以等价为失败。成功就可以把记录的东西清理掉了，对于失败和不确定，可以依靠定时任务等方式把所有失败的事情重新搞一遍，直到成功为止。
回到刚才的例子，系统在A扣钱成功的情况下，把要给B“通知”这件事记录在库里（为了保证最高的可靠性可以把通知B系统加钱和扣钱成功这两件事维护在一个本地事务里），通知成功则删除这条记录，通知失败或不确定则依靠定时任务补偿性地通知我们，直到我们把状态更新成正确的为止。
广播。
消息队列的基本功能之一是进行广播。如果没有消息队列，每当一个新的业务方接入，我们都要联调一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。
提速。假设我们还需要发送邮件，有了消息队列就不需要同步等待，我们可以直接并行处理，而下单核心任务可以更快完成。增强业务系统的异步处理能力。甚至几乎不可能出现并发现象。
削峰和流控。不对于不需要实时处理的请求来说，当并发量特别大的时候，可以先在消息队列中作缓存，然后陆续发送给对应的服务去处理。
上下游对于事情的处理能力是不同的。比如，Web前端每秒承受上千万的请求，并不是什么神奇的事情，只需要加多一点机器，再搭建一些LVS负载均衡设备和Nginx等即可。但数据库的处理能力却十分有限，即使使用SSD加分库分表，单机的处理能力仍然在万级。由于成本的考虑，我们不能奢求数据库的机器数量追上前端。
这种问题同样存在于系统和系统之间。如短信系统可能由于短板效应，速度卡在网关上（每秒几百次请求），跟前端的并发量不是一个数量级。但用户晚上个半分钟左右收到短信，一般是不会有太大问题的。如果没有消息队列，两个系统之间通过协商、滑动窗口等复杂的方案也不是说不能实现。但系统复杂性指数级增长，势必在上游或者下游做存储，并且要处理定时、拥塞等一系列问题。而且每当有处理能力有差距的时候，都需要单独开发一套逻辑来维护这套逻辑。所以，利用中间系统转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候，再处理这些消息，是一套相对较通用的方式。
总而言之，消息队列不是万能的。对于需要强事务保证而且延迟敏感的，RPC是优于消息队列的。
对于一些无关痛痒，或者对于别人非常重要但是对于自己不是那么关心的事情，可以利用消息队列去做。
支持最终一致性的消息队列，能够用来处理延迟不那么敏感的“分布式事务”场景，而且相对于笨重的分布式事务，可能是更优的处理方式。
当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的“漏斗”。在下游有能力处理的时候，再进行分发。
如果下游有很多系统关心你的系统发出的通知的时候，果断地使用消息队列吧。
消息队列举例
当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发的Notify、MetaQ、RocketMQ等。
Kafka
Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。
Kafka 有如下特性：
- 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。
- 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
- 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。
- 同时支持离线数据处理和实时数据处理。
- Scale out：支持在线水平扩展。
kafka的术语
- Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker。
- Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
- Partition：Partition是物理上的概念，每个Topic包含一个或多个Partition。
- Producer：负责发布消息到Kafka broker。
- Consumer：消息消费者，向Kafka broker读取消息的客户端。
- Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
kafka使用参考我的文章：Kafka流处理平台
RabbitMQ
下面来介绍RabbitMQ里的一些基本定义，主要如下：
RabbitMQ Server：提供消息一条从Producer到Consumer的处理。
Exchange：一边从发布者方接收消息，一边把消息推送到队列。
producer只能将消息发送给exchange。而exchange负责将消息发送到queues。Procuder Publish的Message进入了exchange，exchange会根据routingKey处理接收到的消息，判断消息是应该推送到指定的队列还是是多个队列，或者是直接忽略消息。这些规则是通过交换机类型（exchange type）来定义的主要的type有direct,topic,headers,fanout。具体针对不同的场景使用不同的type。
queue也是通过这个routing keys来做的绑定。交换机将会对绑定键（binding key）和路由键（routing key）进行精确匹配，从而确定消息该分发到哪个队列。
Queue：消息队列。接收来自exchange的消息，然后再由consumer取出。exchange和queue可以一对一，也可以一对多，它们的关系通过routingKey来绑定。
Producer：Client A & B,生产者，消息的来源,消息必须发送给exchange。而不是直接给queue
Consumer：Client 1，2，3消费者，直接从queue中获取消息进行消费，而不是从exchange中获取消息进行消费。
RabbitMQ的使用：略
第14章 应用拆分思路
前面我们已经提到单个服务器再优化，它的处理能力都是有上限的，因此我们选择多扩容以及使用缓存和消息队列等对程序进行优化。
下面介绍另一种方法，随着项目需求完成越来越多，应用自然也会越来越大，架构师将一个应用整体拆分成多个应用。
拆分的原则
业务优先，确定业务边界
循序渐进，边拆分边测试
兼顾技术：重构、分层
可靠测试
拆分的思考
应用之间的通信：RPC（dubbo等）、消息队列
消息传输适用于传输数据包小但是数据量大，对实时性要求不高的场景。比如下单成功后通过短信通知用户。而选用RPC框架实时性更高一些。你应该知道的 RPC 原理
应用之间的数据库设计：每个应用都有独立的数据库
避免事务操作跨应用，分布式事务是一个非常消耗资源的问题。这样应用和应用的耦合度降低。
框架举例
服务化——Dubbo
微服务——SpringCloud
Dubbo
Dubbo是一种分布式的服务框架 
SpringCloud
微服务
要实践微服务要解决4个问题：
客户端如何访问这些服务
API Gateway提供统一的服务入口，对前台透明，同时可以聚合后台的服务，提供安全过滤流控等api的管理功能
服务之间是如何通信的
异步的话使用消息队列，同步调用使用REST或者是RPC，Rest可以使用springboot，RPC通常使用Dubbo
同步调用一致性强但是出现调用问题，REST一般基于http实现，能够跨客户端，同时对客户端没有更多的要求。
RPC的传输协议更高效，安全也更加可控。特别是在一个公司内部如果有统一的开发规范和统一的框架，它的开发效率会更加明显。
而异步消息在分布式系统中有特别广泛的应用，它既能减少调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方。同时保证调用方的用户的体验，继续干自己的活。付出的代价是一致性的减慢，需要接受数据的最终一致性。
如何实现如此多服务
在微服务架构中一般每一服务都会拷贝进行负载均衡，服务如何相互感知，如何相互管理，这就是服务发现的问题了，一般都是进行服务注册信息的分布式管理。
服务挂了该如何解决，有什么备份方案和应急处理机制
分布式最大的特性就是网络是不可靠的，当系统是由一系列的调用链组成的时候，其中任何一个出问题都不至于影响到整个链路。
相应的手段有：重试机制、应用的限流、熔断机制、负载均衡、系统降级
