高性能面试知识点

1:读写分离

2:分库分表

3:均衡负载

4:消息队列

4.1优势

异步、解耦、削峰

缺点：可用性降低、复杂性提高、一致性问题

4.2 JMS VS AMQP

4.2.1 JMS-API

JMS（JAVA Message Service,java 消息服务）是 java 的消息服务，JMS 的客户端之间可以通过 JMS 服务进行异步的消息传输。JMS（JAVA Message Service，Java 消息服务）API 是一个消息服务的标准或者说是规范

① 点到点（P2P）模型
② 发布/订阅（Pub/Sub）模型
ActiveMQ 就是基于 JMS 规范实现的。

4.2.2 AMQP -协议

一个提供统一消息服务的应用层标准 高级消息队列协议（二进制应用层协议）

4.3 常见

4.4 Kafka

4.5 RocketMQ

4.5.1模型

4.5.1.1主题模型

4.5.1.2队列模型

4.5.2 架构

RocketMQ 技术架构中有四大角色 NameServer 、Broker 、Producer 、Consumer。

4.5.2.1 Broker

Broker： 主要负责消息的存储、投递和查询以及服务高可用保证。说白了就是消息队列服务器嘛，生产者生产消息到 Broker ，消费者从 Broker 拉取消息并消费。

4.5.2.2 NameServer

注册中心 ，主要提供两个功能：Broker管理 和 路由信息管理 。

4.5.2.3 Producer

4.5.2.4 Consumer

4.5.3 顺序消费和重复消费

4.5.3.1 顺序消费

所谓普通顺序是指 消费者通过 同一个消费队列收到的消息是有顺序的 ，不同消息队列收到的消息则可能是无顺序的。普通顺序消息在 Broker 重启情况下不会保证消息顺序性 (短暂时间) 。

所谓严格顺序是指 消费者收到的 所有消息 均是有顺序的。严格顺序消息 即使在异常情况下也会保证消息的顺序性 。

处理的仅仅是将同一语义下的消息放入同一个队列(比如这里是同一个订单)，那我们就可以使用 Hash取模法 来保证同一个订单在同一个队列中就行了。

4.5.3.2 重复消费-幂等

使用 写入 Redis 来保证，因为 Redis 的 key 和 value 就是天然支持幂等的。当然还有使用 数据库插入法 ，基于数据库的唯一键来保证重复数据不会被插入多条。

4.5.4 分布式事务-事务消息加上事务反查机制

在 RocketMQ 中就是使用的上述的事务反查来解决的，而在 Kafka 中通常是直接抛出一个异常让用户来自行解决。

4.5.5 消息堆积

4.5.5.1 生产者-限流降级

4.5.5.2 消费者

是否是消费者出现了大量的消费错误 ，或者打印一下日志查看是否是哪一个线程卡死，出现了锁资源不释放等等的问题。

4.5.6 回溯消费

Broker 要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒。

4.5.7 刷盘

队列中的消息又是如何进行存储持久化的呢？

4.5.7.1 同步和异步刷盘

4.5.7.2 同步和异步复制

• 同步复制： 也叫 “同步双写”，也就是说，只有消息同步双写到主从节点上时才返回写入成功 。
• 异步复制： 消息写入主节点之后就直接返回写入成功 。

异步复制会不会也像异步刷盘那样影响消息的可靠性呢？

答案是不会的，因为两者就是不同的概念，对于消息可靠性是通过不同的刷盘策略保证的，而像异步同步复制策略仅仅是影响到了 可用性 。为什么呢？其主要原因是 RocketMQ 是不支持自动主从切换的，当主节点挂掉之后，生产者就不能再给这个主节点生产消息了。

比如这个时候采用异步复制的方式，在主节点还未发送完需要同步的消息的时候主节点挂掉了，这个时候从节点就少了一部分消息。但是此时生产者无法再给主节点生产消息了，消费者可以自动切换到从节点进行消费(仅仅是消费)，所以在主节点挂掉的时间只会产生主从结点短暂的消息不一致的情况，降低了可用性，而当主节点重启之后，从节点那部分未来得及复制的消息还会继续复制。

4.5.8 存储机制-CommitLog 、ConsumeQueue 和 IndexFile

CommitLog： 消息主体以及元数据的存储主体

ConsumeQueue： 消息消费队列，引入的目的主要是提高消息消费的性能

IndexFile： IndexFile（索引文件）提供了一种可以通过key或时间区间来查询消息的方法。

问题：RocketMQ常见面试题总结 | JavaGuide

4.6 RabbitMQ