MySQL高可用架构：16年用户行为视角下的自动容灾实战

　　你说那 MySQL 高可用架构啊？上周五活动上线前十分钟，群里突然炸锅——主库延迟飙到 300 秒，监控屏红得跟过年似的。我原以为又是网络抖动，结果运维小哥冲过来拍桌子：'自动容灾没触发！' 当时我盯着后台实时数据，每三秒刷一次的 UV 曲线，跟心电图似的往下掉，手机电量还剩 17%，饮水机那边'咣当'一声——保洁阿姨在换桶，水溅了一地。

　　这事儿得从 2009 年说起。那年我刚转技术岗，带团队做电商大促，数据库崩了三次。第一次是主从同步延迟，用户下单显示成功，结果库存没扣；第二次是脑裂，两个节点互相抢主，订单表直接锁死；第三次更绝，自动切换脚本里藏了个硬编码 IP，换机房时直接跪了。后来我养了个怪癖——每次活动前必查容灾脚本的注释，要是看到'临时方案'四个字，直接让运维改。

　　可去年双 11 还是栽了。我们用了某大厂的 MGR 集群，宣传说'自动选主零延迟'，结果活动页流量一上来，网络分区直接把三个节点劈成两派。最搞笑的是，监控系统显示'集群健康度 100%'，而用户那边，一半人看到'库存不足'，另一半人下单成功但没扣款。后来复盘发现，那套'智能选主算法'根本没考虑用户行为分布——白天订单集中在北京节点，晚上广东用户涌进来，网络延迟一高，选主逻辑直接懵圈。

　　所以我现在看高可用架构，第一反应是'用户行为模型'。比如去年重构的自动容灾系统，核心就俩原则：一是'优胜劣汰'——不是看节点心跳正常不正常，是看它能不能在 5 秒内处理完 80% 的实时请求；二是'用户无感'——切换时要是发现某个节点的订单支付成功率比平时低 10%，直接隔离，哪怕它自己喊'我没事'。上周五那次延迟，系统其实检测到了，但没触发切换——因为当时广东用户占比突然涨到 65%，而备用节点在华北，网络延迟本来就高，切换过去反而更糟。

　　说到这儿，饮水机那边又'咣当'一声——这次是市场部的小张在换桶，他边换边喊：'活动页的券码怎么少了一位？' 我转头看监控，主库延迟已经降到 50 秒，但 UV 曲线还没回稳。运维小哥蹲在机柜前，手里攥着根网线，嘴里嘟囔：'这交换机端口怎么又松了...' 桌上那张手写的排期表被茶水浸了，'MySQL 压测'那行字晕成一团，像极了去年双 11 凌晨三点的监控屏。

　　我原以为自动容灾就是写好切换脚本，结果发现最难的其实是'判断什么时候该切'。比如 2018 年那次，我们用了 Pacemaker+Corosync，配置了'节点失联 30 秒触发切换'。结果活动当天，某个节点的网络设备抽风，每 25 秒丢一次包，切换脚本被触发了几百次，直接把集群搞崩溃。后来我们改了策略：不光看节点是否存活，还看它能不能在 1 秒内返回用户最近 10 次的订单状态——要是返回不了，甭管心跳多正常，直接踢出集群。

　　可这又引出新问题：怎么定义'正常'？比如去年 618，我们发现广东用户的查询频率比北京高 30%，而备用节点在华东，处理广东请求本来就慢。要是按统一标准切，广东用户肯定骂街；要是不切，北京用户又受影响。最后我们搞了个'用户行为画像库'，把每个地区的请求模式、响应时间、错误率都存起来，切换时先查库：要是当前节点的表现比历史均值差 20% 以上，再触发切换。上周五那次延迟，系统没切就是因为查库发现，备用节点处理广东请求的延迟本来就比主库高 40%，切过去反而更卡。

　　说到这儿，会议室门突然被推开，产品经理举着手机冲进来：'落地页的转化率怎么掉了 5 个点？' 我抬头看监控，主库延迟已经降到 10 秒，但转化率曲线还在往下走。运维小哥从机柜后探出头：'可能是缓存没刷干净，我重启下 Redis？' 我摆摆手：'先别动，等用户行为稳定了再说——你忘了去年双 11 重启缓存导致重复扣款的事？' 他缩回脖子，嘴里嘟囔：'那至少把告警阈值调低点？现在 300 秒才报，等发现早凉了。' 我指指屏幕：'告警阈值是按用户行为动态调的——现在广东用户占比高，网络延迟本来就大，300 秒是安全线。'

　　其实我最头疼的不是技术问题，是排期。上周五活动前，市场部非要加个'裂变分享'功能，说能提升 20% 流量。我原以为就是加个按钮，结果发现要改数据库表结构——用户关系链要存到 MySQL 里，而我们的高可用架构是按订单系统设计的，根本没考虑这种高频写入场景。最后逼着运维通宵改配置，把关系链表拆到单独的实例，结果活动当天，那个实例的 CPU 直接飙到 90%，自动扩容脚本又没触发，差点又崩。

　　现在我看排期表就头疼——产品说'这个功能很简单，就加个字段'，设计说'这个按钮要大点，提高点击率'，而我知道，每个'简单'的改动背后，都是用户行为模型的调整。比如去年加个'收藏'功能，看起来只是多张表，结果发现用户收藏行为和下单行为高度相关，原来的容灾策略根本不适用——收藏请求失败时，用户会反复重试，导致备用节点压力暴增。最后我们不得不重新训练用户行为模型，把收藏和下单的请求模式分开处理。

　　所以我现在跟产品吵架的底气足了——不是我不配合，是用户行为数据摆在那儿。上周五活动前，市场部非要把券码从 6 位改成 8 位，说能防止刷券。我原以为就是改个字段长度，结果发现要改的地方多到离谱：短信模板、活动页输入框、后端验证逻辑、缓存键格式...更要命的是，用户行为数据里存的都是 6 位券码的查询模式，改成 8 位后，查询延迟直接涨了 30%。最后我们折中——券码还是 6 位，但加了动态校验位，既防刷又不用改架构。

文章配图，仅供参考

　　当然，这方法也有局限——比如遇到全新的用户行为模式，比如去年突然爆火的'直播带货'，用户请求模式完全变了，原来的画像库就没用。这时候只能靠人工干预，先限制流量，再慢慢调整策略。所以我现在最盼的是两件事：一是用户行为数据能实时更新，二是自动容灾系统能自己学习新模式——别总让我半夜爬起来改配置。

（编辑：草根网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!