消息中间件部署及比较：rabbitMQ、activeMQ、zeroMQ、rocketMQ、Kafka、redis

一发一存一消费，没有最好的消息队列中间件(简称消息中间件)，只有最合适的消息中间件。
消息队列常用的使用场景：

• 非实时性：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。主要解决了应用耦合、异步处理、流量削锋等问题。
• 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；（如：订单->库存）
• 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；(点对多场景，广播场景(注册发短信，发邮件)等等)
• 限流削峰：应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；(根据服务承受度设置队列大小，超过了就返回活动结束了，咱们经常各大商城秒杀，心里还没有点B数吗)减少压力,避免服务挂掉。
• 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；(分工处理(各自对应相应的队列)，灵活应用(收到就处理/定时处理))

消息队列是异步RPC的主要手段之一

两种模式：

1. 点对点：每个消息只有一个消费者（Consumer），不可重复消费(一旦被消费，消息就不再在消息队列中)
2. 发布/订阅：微信公众号(Topic)，大伙(订阅者)订阅关注之后，微信公众号运营平台(发布者)发布信息后，大伙微信就都收到信息了，这里其实还分pull/push的。一个是主动推送，一个是被动拉取
   基于发布/订阅模式做扩展就是横向扩展，多个队列及消费分组订阅(提高消费能力)

• pull：主动权在于消费方，优点是按需消费(吃自助餐，能吃多少拿多少)，而且服务端队列堆积的消息处理也相对简单(不用记录状态啊，状态都消费端)；缺点就是消息延迟(不知道啥时候去拉取更新)，这时候有小伙伴会问，那为啥不叫服务端通知一下呢(有句话叫不在其位不谋其政，服务端通知必然要记录通知状态和增加之间的通信带宽；当然也可以根据实际情况来选择和push组合起来用(男女搭配干活不累嘛)来提高消息的实时性)
• push：主动权就在服务方了，优点是实时性高，服务端可以统一管理来进行负载，不过也容易导致慢消费(就得考虑消费方受不受得了，毕竟你说你了解，但也只有对方才清楚你有多了解)；缺点就是发送消息的状态是集中式管理，压力大啊(要分发消息还要记录状态还要做备份，又当爹来又当妈，你说累不累)
  对于顺序消息，这种场景有限且成本太高的方式就得慎重考虑了，对那种全局有序但允许出现小误差的场景(日志推送)，pull模式就非常适合了(所以说kafka为啥常用于日志处理、大数据等方面)，要问为什么？自己去领悟

实际开发中消息中间件选型基于几个方面：

1. 功能：这个就多了，优先级队列、延迟队列(划分不同的延迟队列来避免重新排序消耗性能，缺点嘛自己悟)、死信队列(放没有推送成功的)、消费模式(pull/push)、广播消费、消息回溯(可追溯嘛，不然被卖了都不知道是谁)、消息堆积+持久化、消息追踪(链路条，方便定位)、消息过滤(根据规则过滤啊，不同类别消息发送到不同topic)、多协议支持(通用性)、跨语言支持(流行程度)、流量控制(嘿嘿嘿，上面有)、消息顺序性(还要再说一遍？)、安全机制(身份认证，权限认证(读写))、消息幂等性(承诺知道不，答应人家的事就一定要做到)、事务性消息(不想说)等
2. 性能：一般是指其吞吐量(统一大小的消息体和不同大小的消息体生产和消耗能力)，性能和功能很多时候是相悖的，鱼和熊掌不可兼得。
3. 高可靠、高可用：先说可靠，主要在于消息的持久化这一块(消息只要写入就一定会被消费，不会因为故障导致数据丢失(这个就很好测试出来了吧))。如果是从系统的角度来看就得从整体的维度去衡量了(不能单单只靠消息中间件本身，要从生产端、服务端、消费端三个维度去保障)。
   再说可用，主要在于一个是对外部服务的依赖性(像kafka依赖zookeeper)，依赖也分强依赖和弱依赖，一个在于本身的备份机制所带来的保障性(像主从复制这种备份啊，增加多个slave来加强保障同时也会存在资源浪费，大部分时候Slave可能是空闲的)。
4. 运维：通常有审核评估啊、监控啊、报警提醒啊、容灾啊、扩容啊、升级部署等等，一方面看中间件支撑的维度，一方面就看结合自动化运维的难易度
5. 社区力度及生态发展：这个好理解吧，使用开源框架最开始基本上愉快的奔跑，但时不时的总会掉坑里，能不能爬出来一方面看自身的实力，一方面就看社区的力度了
6. 成本&