消息中间件相关问题整理（持续更新）

1 什么是消息中间件

1.1消息中间件(MQ)的定义
    一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成。
高效：对于消息的处理处理速度快。
可靠：一般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。
异步：指发送完一个请求，不需要等待返回，随时可以再发送下一个请求，既不需要等待。
    消息中间件不生产消息，只是消息的搬运工。
1.2 消息中间件的组成
1) Broker
    消息服务器，作为server提供消息核心服务
2) Producer
    消息生产者，业务的发起方，负责生产消息传输给broker，
3) Consumer
    消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理
4) Topic
    主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播
5) Queue
    队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
6) Message
    消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输
1.3 消息中间件模式分类
点对点
    PTP点对点:使用queue作为通信载体,消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。 消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
发布/订阅
    Pub/Sub发布订阅（广播）：使用topic作为通信载体,消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

2 消息中间件的优势和使用场景

2.1 消息中间件的优势
1)系统解耦
    交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。
2)提高系统响应时间
3)流量削锋
    比如在秒杀系统中，一般会建立消息中间件，客户的秒杀请求会放在消息中间件中
4.3 为大数据处理架构提供服务
    通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持

3 kafka

     kafka是分布式系统中基于发布订阅模式的消息队列，主要应用于大数据实时处理领域。

Questions、面试中的一些问题

https://blog.csdn.net/ThinkWon/article/details/104588612?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase
一、关于CAP原则的取舍
　　1、什么是CAP
　　 CAP定理是指分布式WEB服务无法同时满足以下3个属性
　　 数据一致性：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性
　　服务可用性：所有读写请求在一定时间内得到响应，可终止、不会一直等待
　　分区容错性：在网络分区的情况下，被分隔的及诶单仍然正常对外服务。
二、使用了消息队列会有什么缺点
    系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在 你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低。
　　系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大
三、如何保证消息不被重复消费
　　 分析:这个问题其实换一种问法就是，如何保证消息队列的幂等性?这个问题可以认为是消息队列领域的基本问题。
　　回答:先来说一下为什么会造成重复消费?
　　其实无论是那种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，让消息队列知道自己已经消费过了。那造成重复消费的原因?，就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。
    如何解决?这个问题针对业务场景来答分以下几点
　　(1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
　　(2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
　　(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。