消息中间件

消息队列：
    就是一个队列结构的中间件，消息放入这个中间件后就可以直接返回，不需要系统立即处理，而另外会有一个程序读取这些数据，并按顺序进行逐次处理
    
    消息队列主要解决了应用耦合，异步处理，流量削锋等问题。
    
    应用场景：
        1、系统解耦：使用消息系统后，入队系统和出队系统是分开的，一个系统崩溃了，不会影响另一个系统的正常远行，两个系统不需要相互依赖
        2、流量削锋：使用消息队列的方式来调用某个系统，那么消息将在队列中排队，由消费者自己控制消费速度。配合缓存来使用消息队列，能够有效的顶    住瞬间访问量，防止服务器承受不住导致崩溃
        3、异步通信：向消息队列发送完消息之后就可以做其他事情了
        4、消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用作消息通讯。比如实现点对点消息队列或者聊天室等
    
    消息队列选型总结：
        对消息队列功能和性能没有很高的要求，只需要一个快速上手易于维护的消息队列，建议使用RabbitMQ;
        如果使用消息队列处理在线业务，比如在交易系统中用消息队列传递订单，需要低延迟和高稳定性，建议使用RocketMQ;
        如果需要处理海量的消息，像收集日志，监控信息等这类数据或是大量使用了大数据，流计算，那Kafka是最适合的

    如何保证消息即使重复消费或者生产者重复发送都没有问题？（保证消息可靠传输）
        在消费者端实现幂等性，保证就算重复消费也不会有问题。通过幂等性也能解决生产者重复发送消息的问题。

    如何保证消息不丢失或者消费者一定能够消费到？
        1、生产者发送消息时，要确认broker确实收到并持久化了这条消息，比如RabbitMQ的confirm机制，Kafka的ack机制
        2、broker要等待消费者真正确认消费到了消息才删除消息，这里通常就是消费端ack机制。消费者收到一条消息后，如果确认没问题了，就给broker发    送一个ack，broker接受到ack后才会删除消息

    死信队列和延时队列：
        死信队列用来存放那些咩有成功消费的消息的
        延时队列用来存放需要在特定时间被处理的消息的队列，通常可以用来处理一些具有过期性操作的业务，比如十分钟内未支付则取消订单

一、Kafka
    使用Kafka需要：1）Java JDK；2）Kafka安装包

    1、特性：
        高吞吐量：每秒可以处理几十万条消息，延迟最低只有几毫秒
        可扩展性：Kafka集群支持热扩展
        持久性，可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
        容错性：允许集群中节点失败（若副本数量为n，则允许n-1个节点失败）
        高并发：支持数千个客户端同时读写
    2、应用场景：
        日志收集：
        消息系统：解耦生产者，消费者，缓存消息
        用户活动跟踪：
        运营指标：用来记录运营监控数据。如报警
    3、通信模式
        点对点模式：发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动去拉取消息进行消费，所以在消费者端    需要额外的线程去监控
        发布订阅模式：生产者将消息放入队列后，队列会将消息推送给订阅过该类消息的消费者
    4、工作流程
        1）生产者从集群获取分区的leader；
        2）生产者将消息发送给leader；
        3）leader将消息写入本地文件；
        4）follower从leader pull消息；
        5）follower将消息写入本地后向leader发送ACK
        6）leader收到所有副本的ACK后向生产者发送ACK

    注意⚠️：通过ACK应答机制来确保消息不丢失，生产者向队列写入数据的时候设置参数来确定是否确认Kafka是否接受到消息，这个参数值为0，1，all。
        0:代表生产者往集群中发送消息不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高
        1:代表生产者往集群发送消息只要leader应答就可以发送下一条，值确保leader发送成功。
        all：代表生产者往集群发送消息需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份，安全性最    高，但是效率最低

    注意⚠️：Kafka读取特定消息的时间复杂度是O(1)。

二、RocketMQ

三、Rabbitmq
    1、名词介绍
        publisher：生产者
        consumer：消费者
        Channel：如果每一次访问Rabbitmq都建立一个connection，，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在    connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel ID帮助客户端和    broker识别channel，所以channel之间是完全隔离的。
        Broker：接收和分发消息的应用，Rabbitmq server就是message broker
        Exchange：message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去
        routing key：生产者将消息发送到交换机时会携带一个key来指定路由规则
        binding key：在绑定Exchange和queue时，会指定一个bindingkey，生产者发送消息携带的routingkey会和binding key对比，若一致就将消息分发至    这个队列
        vHost虚拟主机：每一个Rabbitmq服务器可以开设多个虚拟主机，每一个vHost本质上是一个mini版的Rabbitmq服务器，拥有自己的“交换机exchange、绑定binding、队列queue”，更重要的是每一个vhost拥有独立的权限机制，这样就能安全地使用一个Rabbitmq服务器来服务多个应用程序，其中每个vhost服务一个应用程序

    2、交换机类型
        1）direct Exchange（直接交换机）：匹配路由键，只有完全匹配消息才会被转发
        2）fanout Exchange（扇出交换机）：将消息发送到所有的队列
        3）topic Exchange（主题交换机）：将路由按模式匹配，此时队列需要绑定在一个模式上，符号“#”匹配一个或多个词，符号“*”只匹配一个词
        4）header Exchange：在绑定Exchange和queue的时候指定一组键值对，header为键，根据请求消息中携带的header进行路由

    3、工作模式
        1）simple（简单模式）：一个消费者消费一个生产者生产的消息
        2）work queue（工作模式）：一个生产者生产信息，多个消费者进行消费，但是一条消息只能消费一次
        3）publish/subscribe（发布订阅模式）：生产者首先投递消息到交换机，订阅了这个交换机的队列就会收到生产者投递的消息
        4）routing（路由模式）：生产者生产消息投递到direct交换机中，扇出交换机会根据消息携带的routing key匹配相应的队列
        5）topic（主题模式）：生产者生产消息投递到topic交换机中，路由模式是完全匹配路由键，而主题模式是模糊匹配，只要有合适规则的路由就会投递    给消费者