各位朋友,我是老周，干CDN这行十几年了，每天跟服务器、节点、回源打交道，今天咱不整那些云山雾罩的术语，就唠唠这个“探活机制”——听着挺玄乎，其实说白了，就是CDN怎么知道你源站是活蹦乱跳，还是已经咽气了。
你开个网站,流量一大，肯定得用CDN，CDN把你的网页、图片、视频缓存到全国各地的节点上，用户就近访问，爽，但问题来了：用户访问的是缓存，可缓存总有过期的时候，或者用户运气不好，非要看个没缓存的新内容，这时候CDN就得回源——去你真正的服务器上取数据，可你的服务器要是挂了，CDN还傻乎乎地往那儿冲，用户页面转圈转半天，最后给你来一句“502 Gateway Timeout”，那你这生意还做不做了？
CDN必须有一套“探活机制”，像心电图监护仪一样，时时刻刻盯着你的源站，它不直接等用户访问时才去碰运气，而是在后台每隔几秒或者几十秒，就给你的源站发个“心跳”信号——比如一个HTTP HEAD请求，或者一个TCP连接，你源站回了个“我活着，一切正常”，CDN就记下“这哥们儿状态良好”，继续正常回源；要是连续几次都不理人，或者回了个超时、错误码，CDN立刻把你标记为“宕机状态”，然后启动应急预案。
探活机制，CDN的心跳监护仪，到底是怎么知道你家服务器挂没挂的？
这应急预案是啥？降级”或“容灾”，你源站挂了，但CDN节点上还存着之前的缓存副本啊，这时候CDN会把这些缓存强行设置为“新鲜”，哪怕过期了也继续给用户用，这叫“缓存兜底”，就算用户撞上一个没缓存的请求，CDN也不去回源了，直接返回一个自己生成的友好错误页，或者把请求指到你的备用源站——前提是你配置了多个源站，探活机制就像个交通指挥员，一看主路堵死了，马上引导车辆走辅路。
光说原理没劲,给您来个真实案例，前两年我手头有个电商客户，双十一大促，流量猛增，结果半夜三点，他们家的应用服务器内存泄漏，直接宕机，可整个大促期间，用户下单愣是没受大影响，为啥？因为CDN的探活机制在宕机后第6秒就发现了异常，比他们运维团队收到告警还早了40多秒，探活确认源站无响应后，CDN自动把所有静态资源和接口的兜底响应切到了缓存，虽然下单功能暂时没法用，但商品详情页、促销页面照常秒开，用户至少能逛、能加购物车，最后等他们运维强制重启服务器，探活机制又检测到恢复，自动把流量切了回去，整个过程中，用户感知到的只是“偶尔下单按钮转圈几秒”，几乎没有流失，要是没有探活机制，那天晚上可能直接变技术事故直播现场。
探活机制这东西,用好了是神器，用不好也坑人，我见过太多人栽在几个误区里，第一个误区：探活就是“ping一下”，兄弟，ping只测IP通不通，不测你的Web服务活没活，哪怕你服务器上的Nginx已经挂了，系统照样能ping通，探活必须走应用层，比如真正发一个HTTP请求，看你80/443端口有没有正常响应，甚至要检查响应状态码是不是200，你要是图省事只做ICMP探活，那你探了个寂寞。
第二个误区：探活频率越高越好，有人觉得，我每秒探一次，多保险啊，错了！探活本身也消耗资源，太频繁了，你的源站没被正常流量压垮，反倒被CDN的监控请求打趴下了，尤其那些小水管服务器，每秒十几条探活请求，带宽直接占满，正常用户全卡死，合理频率是5秒到30秒一次，根据你的业务容忍度来调，别瞎折腾。
第三个误区：一探活失败，立马切换备用源，这个更危险，网络是有抖动的，偶发一两次超时，可能是机房丢包，也可能是你的源站正在重启服务——比如你刚部署了个新版本，进程重启那两三秒内，探活肯定失败，你要是设置成“失败一次就切换”，那好了，流量在主力源和备用源之间来回弹，用户每次请求都可能在两个机房之间跳来跳去，体验更稀碎，正确做法是设置连续失败阈值，比如连续3次失败才判定宕机，而且要有“抖动容忍”时间窗口。
探活机制的真正精髓,在于“区分故障类型”，是源站硬死（断电、进程崩溃），还是软死（响应极慢、内存泄漏但进程还在）？硬死很好办，直接切换；软死最恶心，因为探活请求可能还能收到200，但实际业务请求全在排队超时，这就需要更聪明的探活——不光看响应，还要看响应时间，如果某次探活响应耗时突然从50毫秒飙到3秒，那就得触发“性能劣化”告警，提前把流量分担走，别等彻底卡死再动手。
最后跟您交个底：探活机制不是CDN厂商自己闷头玩的，它允许你自定义，你在配置CDN时，可以设置探活路径——比如专门做一个/healthcheck接口，返回一个极简的JSON，不查数据库不查缓存，只返回“OK”，这样探活精准，还不影响业务逻辑，别用首页当探活路径，因为首页可能依赖很多动态数据，偶尔慢一下很正常，容易误报。
探活机制就是CDN的神经末梢,让你源站的生命体征暴露在阳光底下，别嫌它麻烦，也别过度依赖它，理解了它的脾气，你的网站才能真正“躺平”无忧，行了，今天先唠到这儿，下回再说说回源超时那点破事。
发表评论