broker主从复制机制
同步复制:
等Master和Slave均写成功后,才反馈给客户端写成功状态;
如果Master出故障, Slave上有全部的备份数据,容易恢复,但是同步复制会增大数据写入延迟,降低系统吞吐量。
异步复制:
只要Master写成功,即可反馈给客户端写成功状态。后面再通过异步的方式和slave同步。
较低的延迟和较高的吞吐量,如果master故障,有可能因为某些数据没有被写入slave,造成丢失。
复制流程分为两步,元数据同步、消息数据复制
元数据同步:Slave Broker 定时任务每隔 10 秒会同步元数据,包括主题,消费进度,延迟消费进度,消费者配置。
同步主题时, Slave Broker 向 Master Broker 发送 RPC 请求,返回数据后,首先加入本地缓存里,然后持久化到本地。
消息数据复制:
1、Master 启动监听指定端口
2、Slave 启动 HaClient 服务,和 Master 创建 TCP 链接
3、Slave 向 Master 上报存储进度
4、Master 接收进度,消息文件中检索该偏移量后的所有消息,并传输给 Slave
5、Slave 接收到数据后,将消息数据 append 到本地的消息存储。
Master和Slave之间是怎么同步数据的呢
通过raft协议
在broker收到消息后,会被标记为uncommitted状态
然后会把消息发送给所有的slave
slave在收到消息之后返回ack响应给master
master在收到超过半数的ack之后,把消息标记为committed
发送committed消息给所有slave,slave也修改状态为committed
工作流程
1、启动NameServer,NameServer启动后监听端口,等待Broker、Producer、Consumer连上来,相当于一个路由控制中心。
2、Broker启动,跟所有的NameServer保持长连接,定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后,NameServer集群中就有Topic跟Broker的映射关系。
3、收发消息前,先创建Topic,创建Topic时需要指定该Topic要存储在哪些Broker上,也可以在发送消息时自动创建Topic。
4、Producer发送消息,启动时先跟NameServer集群中的其中一台建立长连接,并从NameServer中获取当前发送的Topic存在哪些Broker上,轮询从队列列表中选择一个队列,然后与队列所在的Broker建立长连接从而向Broker发消息。
5、Consumer跟Producer类似,跟其中一台NameServer建立长连接,获取当前订阅Topic存在哪些Broker上,然后直接跟Broker建立连接通道,开始消费消息。
Master支持读和写,Slave仅支持读,也就是 Producer只能和Master连接写入消息;Consumer可以连接 Master,也可以连接Slave来读取消息。
持久化机制(刷盘)
同步刷盘:在返回写成功状态时,消息已经被写入磁盘。具体流程是,消息写入内存的PAGECACHE后,立刻通知刷盘线程刷盘, 然后等待刷盘完成,刷盘线程执行完成后唤醒等待的线程,返回消息写成功的状态。响应时间比异步多10%,用在对消息可靠性比较高的
异步刷盘:在返回写成功状态时,消息可能只是被写入了内存的PAGECACHE,写操作的返回快,吞吐量大;当内存里的消息量积累到一定程度时,统一触发写磁盘动作,快速写入。用在吞吐量比较高的
配置:Broker配置文件里的flushDiskType,SYNC_FLUSH(同步刷盘)、ASYNC_FLUSH(异步刷盘)
如何保证消息不丢失,保证消息的可用性/可靠性
producer:消息成功发送
同步发送,broker返回成功后,表示数据送到了
broker:消息持久化
消息持久化到commitLog
刷盘,同步刷盘和异步刷盘,将消息存储
master和slave的同步机制,同步双写可以保证在master宕机时,slave还可以有消息给consumer消费。
consumer:标记已经消费的消息offset
consumer中也保存了一个offset,用来表示消费成功却已经发回broker的消息下标,发回失败时也会定时重试,offset是持久化的。
消息存储结构
CommitLog:
消息主体与元数据的存储主体,文件默认大小是1G,CommitLog 存储的数据是在当前这个broker中的所有的topic的数据
consumerQueue:
只记录具体某个topic下的数据,一个topic下有多个consumerQueue,作为消费索引,它记录了指定topic的队列消息在CommitLog中的位置(物理位置偏移量offset
indexFile
indexes 里记录了 key的hash值,在commitLog中的偏移量,与 beginTimestamp的差值,下一个索引的值(记录key和offset的对应关系。
零拷贝
RocketMQ为什么速度快
是因为使用了顺序存储、Page Cache和异步刷盘。
我们在写入commitlog的时候是顺序写入的,这样比随机写入的性能就会提高很多
写入commitlog的时候并不是直接写入磁盘,而是先写入操作系统的PageCache
最后由操作系统异步将缓存中的数据刷到磁盘
如何保证顺序
顺序由producer发送到broker的消息队列是满足FIFO的,所以发送是顺序的,单个queue里的消息是顺序的。多个Queue同时消费是无法绝对保证消息的有序性的。所以,同一个topic,同一个queue,发消息的时候一个线程发送消息,消费的时候一个线程去消费一个queue里的消息。RocketMQ给我们提供了MessageQueueSelector接口,可以重写里面的接口,实现自己的算法,比如判断i%2==0,那就发送消息到queue1否则发送到queue2。