银行系统消息队列 各个消息队列的优缺点

1. 为什么要使用消息队列

1. 解耦，解决频繁的接口修改
2. 异步，解决快速返回的问题
3. 削峰，解决高峰期系统压力的问题

2. 消息队列的优缺点

1. 系统可用性降低：mq挂掉，生产者无法放消息进mq，消费者无法消费
2. 系统复杂性变高

1. 一条消息多次发送
2. 消息丢失
3. 消费端消费顺序问题
4. 积累大量消息后，mq挂掉

3. 一致性问题：发送请求后，等后续所有成功才返回，但当后续中某一个系统失败，结果返回成功

3. kafka、activemq、rabbitmq、rocketmq区别以及适合场景

	activemq	rabbtimq	rocketmq	kafka
单机吞吐量	万级，比rocketmq和kafka低	万级，比rocketm和kafka低	十万级	十万级别，一般用于大数据类系统进行实时统计日志采集等场景
时效性	毫秒级	微秒级	毫秒级	毫秒级以内
可用性	高，基于主从框架	高，基于主从框架	非常高，分布式架构	非常高，基于分布式，一个数据多个副本，少数机器宕机，数据不会丢失，不会导致不可用
消息可靠性	有较低的几率丢失数据		经过参数配置可以做到0丢失	经过参数配属可以做到0丢失

1. rabbitmq高可用性

1. 普通集群模式  多台机器没太机器都有一个rabbitmq实例，某一个是咧中有queue的元数据和实际数据，当请求到实际数据节点时，无实际数据的节点会找到有实际数据的节点，拉取数据并交给消费者。 提高吞吐量：缺点1、内部阐释大量数据传输2、可用性几乎没有什么保障
2. 镜像集群模式 每一个节点都会包含queue的完整的所有的数据，写消息到任何一个节点，都会有消息同步到其他节点上去，相当于每个节点都有一个queue的镜像，这个镜像包含queue的元数据以及实际数据，消费者从任何一个节点消费queue的数据都有完整的数据，只有在写消息的时候才会进行同步和传输。

2. kafka高可用性

1. 部署多台机器，在没太机器谁给你启动一个broker进程，生产者写入多条数据到topic，分配到多个partition中，相当于分配到多个机器中。
2. 问题 当某一台机器挂条，是否会丢失一部分数据 ：0.8以后有高可用机制，会做一个replica副本，具有相同的数据，一个partition多个副本，会选举一个leader，其他的都叫follower，生产者只能往leader中写数据，消费者也只能从leader中读数据，leader会把写入的数据同步到follower中

3. kafka出现消息重发消费的问题

1. 按照数据进入kafka的顺序，kafka都会给每天数据发票一个offset，代表这个数据的序号，消费者消费的时候，会按照这个顺序进行消费，消费者会去提交offset就告诉kafka已经消费了offset=某个值的这条数据（基于zookeeper实现，只要提交了这个offset，zookeeper就会进行记录，然后kafka会感知到消费者消费那条数据），消费者定时定期提交offset

4. rabbitmq消息丢失问题

1. 生产者丢失数据

1. rabbitmq支持事务，打开事务try{发送消息}catch{胡滚重发}同步锁机制导致阻塞卡
2. 设置channel信道设置为confrim模式->发送消息->成功，回调生产者通知成功->失败回调生产者通知失败，再次发送，异步不会阻塞，吞吐量会比较高一些

2. rabbitmq丢失数据

1. 设置queue持久化，设置消息持久化

3. 消费者丢失数据

1. 关闭autoack机制，手动通知是否消费完毕消息

5. kafka消息丢失

1. 生产者丢失
2. kafka丢失

1. 设置一个topic至少有俩个副本
2. 至少一个flower与leader保持通信
3. 必须写入到所有的flower才算成功
4. 无限次重试

3. 消费者关闭

1. 消费者关闭自动提交offset，手动提交offset

6. rabbitmq消费顺序

1. 增 改 删->删 改 增 一个queue被多个消费者消费
2. 解决 需要抱着顺的数据一个queue被一个消费者消费

7. kafka消费顺序问题

1. 对需要有顺序的数据设置一个key，然后这个可以的数据会被写入到一个partition中，kafka抱着写到一个partition中的数据有顺序的。
2. 问题：当消费者多线程处理消息的时候出现顺序错乱情况，可以功能键key来做一个内存队列来抱着每个消费线程的顺序性