mq怎么存消息：
mq高可靠性能的要求，所以要存在磁盘中
1、mq收到消息，返回ack响应给生产者，并且存储消息到硬盘中。
2、mq发送消息给消费者，消费者响应ack给mq，mq标记消息已消费，如果没有得到响应，mq会不断的把消息推送给消费者；
3、mq会定期删除过期的消息。
消息存储介质
索引的建立和维护要有一定的开销，mq放弃这种方式，采用直接存储文件的方式来保存消息
直接写速度为什么不慢？
顺序写：提前在磁盘申请空间，写消息时一个一个的往下写,固态硬盘很快。(正常的写是随机写，每次写都要在磁盘中随机开辟一个空间)
0拷贝：linux分为内核态和用户态。文件存在操作系统中，属于内核态，app(属于用户态)对文件读写需要把内核态的文件读到自己的运用内存中。写的时候也是一样，先写到用户态，再写到内核态。文件的读要经过两次拷贝，文件的写也要经过两次的拷贝，这效率就很低了。
mMap方式：app读取文件时，不拷贝文件，只读取文件的映射(比如在磁盘中的地址，长度)，操作只正对映射来做。写文件的时候，直接写到内核态中，不需要经过app内存中。减少一半拷贝次数。
mMap的缺点：文件不能太大，否则不能实现0拷贝，阿里云对这个缺点做了很多优化，并且mq的文件大小有限制。
消息存储结构
commitLog：存储消息的元数据，消息都会顺序存入到commitLog文件中。会维护一个索引文件
consumerQueue：记录一个队列，不存消息内容，只存消息索引，(过滤消息要使用tag来过滤，因为在索引中，所以很快)
indexFile：为了消息查询提供了一种自定义key或者时间区间来查询消息的方法，通过indexFile来查找消息的方法不影响发送与消费消息的主流程。
刷盘机制：
mq要把消息放到磁盘上，保证持久化，也能突破内存的限制。
同步刷盘：在消息从pageCache内存写入磁盘后才将成功状态返回。
异步刷盘:仅仅将消息写道pageCache中就返回成功标志，当消息积累到一定程度时才将消息写入到磁盘中。
消息主从机制：
如果broker以一个集群的方式部署，会有一个master节点和多个slave节点。消息需要从master复制到从节点上，而消息复制的方式分为同步复制和异步复制。
同步复制：当消息写入主节点和从节点都写入成功时，再反馈给客户端，这样主节点故障了，从节点上有着主节点所有的数据。
异步复制：消息写到master就马上反馈给客户端，再异步将消息复制给从节点。速度快，但是主节点故障会丢失部分的数据。
负债均衡
生产者的负载均衡：以MessageQueue为单位默认轮询的发送，顺序消息打破了这个机制。
消费者的负载均衡：以MessageQueue为单位进行负载均衡，分为集群模式，广播模式；
广播模式：所有的消息会往每一个消费者去推；
集群模式：一组topic下面的messagequeue，要把消费分发到不同的消费者上。并且当消息被发过一次，其他消费者就不会再接收到了。
通过订阅的方式：比如broker1下有消息队列，消息队列2 ，消3，broker2下有，消3，消4，消5，面对三个消费者，consumer1，consumer2，consumer3.这时通过订阅绑定。消息1，消息2绑定consumer1，消息3，消息4绑定consumer2，消息5，消息6绑定consumer3。绑定后，该队列的所有消息由指定的消费者来消费。
分配的策略：
默认平均分配策略，将消息队列平均的分配给消费者
轮询分配：轮流的分配消息给消费者；
按机房分：把同一个机房的消息队列和消费者分配在一起。 等等
消息重试：消息只要消费不成功就会进行重试，消息返回的状态consume_success（成功），reconsume_later(失败),或者异常，或者null。就会创建一个重试队列。为每一个消费者组创建一个队列，每当消息失败就会进行重试，默认16次，从秒到小时，一共有16个级别。(可以进行一定的修改，16次之后的间隔就都是2小时)，如果重试了16次还不成功就变成了死信队列(由mq自动给我们创建)。
出现了死信队列需要我们人工的去操作。一个死信队列对应一个消费者组，而不是某个消费者实例。
死信队列默认配置的是2，既不能读也不能写，需要手动改成6，可读可写(还有一个状态是4可读不可写)。
消息幂等：
消息幂等有三种实现语义：
最多一次，最少一次，刚刚好一次。
最多一次：直接使用异步发送；
最少一次：使用sendOneWay来保证；
刚刚好一次没办法保证，只能用户自己通过业务上的处理进行保证。使用唯一的Message ID进行保证刚刚号一次。Message ID不会改变，可以保证全局的唯一性。
