每日一句
You must try things that may not work. And you must not let anyone define your limits because of where you come from. Your only limit is your soul.
千万不要怕失败，也不要因为出身低就让别人限制了你的发展，成败在于你自己。
概述
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。
常见的消息中间件有：
- ActiveMQ
- RabbitMQ
- Kafka
- RocketMQ
传统Http协议调用接口存在的缺陷
传统方式 采用同步的形式调用接口，如果调用的过程非常耗时间的话，客户需要等待非常久的时间才会响应；这样对客户端体验非常不好。
比如用户注册 调用数据库新增插入会员信息需要3s、调用优惠券接口需要3s、调用第三方短信接口需要3s 一共需要9s的时间才会返回信息，这样用户的体验是非常不好；
MQ 的作用
通常我们采用MQ来进行以下操作
- 流量削峰
- 应用解耦
- 异步调用
流量削峰
如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。
但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。
使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好
应用解耦
以电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障，都会造成下单操作异常。
当转变成基于消息队列的方式后，系统间调用的问题会减少很多。
- 物流系统因为发生故障，需要几分钟来修复。
- 在这几分钟的时间里，物流系统要处理的内容被缓存在消息队列中，用户的下单操作可以正常完成。
- 当物流系统恢复后，继续处理订单信息即可，中单用户感受不到物流系统的故障，提升系统的可用性
异步处理
有些服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完。
以前一般有两种方式：
- A 过一段时间去调用 B 的查询 api 查询。
- A 提供一个 callback api，B 执行完之后调用 api 通知 A 服务。
这两种方式都不是很优雅，使用消息总线，可以很方便解决这个问题。
- A 调用 B 服务后，只需要监听 B 处理完成的消息
- 当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。
这样 A 服务既不用循环调用 B 的查询 api，也不用提供 callback api。同样B 服务也不用做这些操作。A 服务还能及时的得到异步处理成功的消息。
常见的 MQ 对比分析
1.Kafka
Kafka 主要特点是基于Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka 了。
2.RocketMQ
天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。
3.RabbitMQ
结合 erlang 语言本身的并发优势，性能好时效性微秒级，社区活跃度也比较高，管理界面用起来十分方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的 RabbitMQ。
美文佳句
苏轼曾经说过：“古之立大事者，不惟有超世之才，亦必有坚忍不拔之志。”我们或许无法有出类拔萃的才能，但我们都可以有坚韧不拔的意志。已经努力了一年，也许现在的你有些累了，但每个人的人生都需要砥砺前行，无论何时，都不要轻言放弃。请相信，你的坚持，不会被辜负。
如果时光可以倒流，很多人想做的，只是过好当时的那一刻。
你好，我是yltrcc，日常分享技术点滴，欢迎关注我：ylcoder