Question

mysql消息队列满的时候怎么处理

Answer 1

① 请求消息处理线程
负责端口监听，如果有新连接进入则验证连接合法性，如果成功则加入连接池，连接池只能容纳一定量的连接
监听连接池中所有连接是否有消息输入，如果有则读取请求消息
处理连接非协议性关闭（如断电）

② 将请求消息写入消息队列
这时必须换过消息格式，在原来的消息头中加入进队列的时间戳和所属连接。

③ 通知连接无法处理请求
由于消息队列可容纳的消息个数有限，并且消息队列是循环可丢弃型的，只有在消息处理线程组太忙而客户又有大量请求进来时才须要抛弃最旧的消息。在抛弃最旧消息时查一下时间戳，如果未超时则可产生一个‘系统太忙未处理请求’的结果消息加到结果队列去。
如果消息队列已满，可以考虑动态增加处理线程的个数，但处理线程组的个数必须是有限的。

Answer 2

MGR 相关的参数：

1. group_replication_member_expel_timeout

• 行为：当某节点意外离线达到（5 秒 + group_replication_member_expel_timeout 秒）后，MGR 将其踢出集群。如果节点意外离线时间较短，MGR 可以自动接续消息，仿佛节点从未离开。

• 优点：网络等发生意外时，该参数越大，越不需要人工参与，集群可自动恢复。

• 成本：该参数越大，就需要更多的消息缓存。

• 成本：节点未被踢出集群时，可以从该节点读到过期数据。该参数越大，读到过期数据的概率越大。

2. group_replication_message_cache_size

• 优点：该参数越大，可缓存的消息越多，故障节点恢复后自动接续的概率越大，不需要人工参与运维。

• 成本：消耗内存。

小贴士

大家在选择 MGR 参数时，建议从以下几个方向考虑，达成平衡：

对环境不稳定的容忍程度

自动化程度（是否需要人工参与）

读过期数据的概率

物理资源消耗