如何解决高并发场景下，缓存冷启动导致mysql负载过高，甚至瞬间被打死的问题

由于mysql是一个连接给一个线程，当并发高的时候，每秒需要几百个甚至更多的线程，其中创建和销毁线程还好说，大不了多耗费点内存，线程缓存命中率下降还有创建销毁线程的性能增加问题---这个问题不是特别大，重点是mysql底层瞬间处理这几百个线程提交的sql（有时候一个页面会有10多条sql，cpu一次只能处理一条sql）会导致cpu的上下文切换，性能抖动，然后性能下降。

1. group_replication_member_expel_timeout
行为：
当某节点意外离线达到（5 秒 + group_replication_member_expel_timeout 秒）后，MGR 将其踢出集群。
如果节点意外离线时间较短，MGR 可以自动接续消息，仿佛节点从未离开。
优点：
网络等发生意外时，该参数越大，越不需要人工参与，集群可自动恢复。
成本：
该参数越大，就需要更多的消息缓存。
成本：
节点未被踢出集群时，可以从该节点读到过期数据。
该参数越大，读到过期数据的概率越大。
2. group_replication_message_cache_size
优点：该参数越大，可缓存的消息越多，故障节点恢复后自动接续的概率越大，不需要人工参与运维。
成本：消耗内存。
小贴士大家在选择 MGR 参数时，建议从以下几个方向考虑，达成平衡：
对环境不稳定的容忍程度
自动化程度（是否需要人工参与）
读过期数据的概率
物理资源消耗