RabbitMQ_的Confirm机制优化.docxVIP

RabbitMQ 的Confirm机制优化背景：RabbitMQ的confirm是于生产者与MQ之间的确认机制，确保消息确实投递到了MQ。在许多对可靠性要求比较高的应用场景下都需要使用该机制确保消息不丢。测试显示，该功能开启与否对性能影响很大，在单台服务器上开8个queue，消息持久化，1kb大小的消息，不开confirm 时QPS 28k，开启confirm后QPS降到21k。源码分析：开启confirm后，生产者与RabbitMQ之间通过发送确认序号来对消息进行确认，该序号是per channel的。对消息进行确认就是简单的将该消息对应的序号发回给生产者，但RabbitMQ收到消息后并不是立即回ack，在不同配置下，回ack的时机是不同的。Confirm的过程伴随着消息在MQ中整个处理流程，为此接下来我们从整个消息的生命周期来分析confirm的处理机制。以下是confirm机制的主干流程。Rabbit_channel 接收到新消息后根据路由规则确定该消息应该被投递给哪些queue, 为每个消息生成一个全局唯一标识msgid,当然每个消息也有per channel的确认序号，后面还会有别的序号，为了避免冲突我们将该确认序号命名为ch_seq_no。在将该消息以及对应的msgid，ch_seq_no投递给相应queue进程后，记录下unconfirmed消息。dtree:insert(MsgSeqNo, QPids, XName,State#ch.unconfirmed)}.Rabbit_amqqueue_process收到信息以后记录为未确认的消息maybe_record_confirm_message({eventually, SenderPid, MsgSeqNo, MsgId}, State = #q{msg_id_to_channel = MTC}) - State#q{msg_id_to_channel = gb_trees:insert(MsgId, {SenderPid, MsgSeqNo}, MTC)};其中MsgId是消息的全局唯一表示，SenderPid是接收该消息的channel进程，MsgSeqNo是该消息的确认序号。（2）交给backing_queue做持久化3. backing_queue收到新消息后（1）记录为未确认的消息 UC1 = gb_sets_maybe_insert(NeedsConfirming, MsgId, UC), （2）将消息投递给rabbit_msg_store4. rabbit_msg_store收到新消息后（1）记录为未确认的消息record_pending_confirm(CRef, MsgId, State) - update_pending_confirms( fun (_MsgOnDiskFun, CTM) - dict:update(CRef, fun (MsgIds) - gb_sets:add(MsgId, MsgIds) end, gb_sets:singleton(MsgId), CTM) end, CRef, State).（2）定期或者在切换消息存储文件时，对消息进行确认internal_sync(State = #msstate { current_file_handle = CurHdl, cref_to_msg_ids = CTM }) - State1 = stop_sync_timer(State), CGs = dict:fold(fun (CRef, MsgIds, NS) - case gb_sets:is_empty(MsgIds) of true - NS; false - [{CRef, MsgIds} | NS] end end, [], CTM), ok = case CGs of [] - ok; _ - file_handle_cache:sync(CurHdl) end, lists:foldl(fun ({CRef, MsgIds}, StateN) - client_confirm(CRef, MsgIds, written, StateN) end, State1, CGs).client_confirm(CRef, MsgIds, ActionTaken, State) - update_pending_confirms( fun (MsgOnDiskFun, CTM) - case dict:find(CRef, CTM) of {ok, Gs} - MsgOnDiskFun(gb_sets:intersection(Gs, MsgIds), ActionTaken), MsgIds1 = rabbi