这个《堕落的圣痕：夜行传令》说白了，就是我三年前鼓捣的一个P2P同步工具。当时图便宜，找了个海外的小服务器跑。跑得好好的，上个月突然他妈的嗝屁了。我上去一看，直接被服务商封号了，邮件都没收到一封，真鸡贼。
我知道这玩意儿不能停，好多老用户还指着它同步一些私房数据。我赶紧翻箱倒柜，把我那个吃灰的树莓派翻了出来。这玩意儿性能虽然差，但跑个地址同步和低频数据传输还是够的。关键是，它在我手里，不会突然就没了。
第一步：部署和编译的狗屎之路
我花了一整天，把树莓派的系统刷了一遍，然后把夜行传令的几个核心服务全套部署了上去。这个过程真的是一坨屎，因为以前的代码是按X86架构写的，我不得不手动修改了好多库的引用路径，编译得我头都炸了。光是环境配置，就干掉我一个晚上，眼珠子都熬红了。
新服务器地址（也就是树莓派的内网IP加端口映射）确定了，问题来了。我怎么把这个新地址告诉所有还在用旧地址的用户？
第二步：找到后门，强行推送配置
一开始我想的是群发邮件，但是这太慢了，用户不一定看。我记得，夜行传令的启动脚本里，我他妈留了个后门。这后门平时是用来做版本热更新的，但现在被我用来强行推送新配置了。当时留这玩意儿就是为了防止服务器突然暴毙，没想到真用上了。
- 我先登录了旧服务器，还好被封之前还能读写配置文件。
- 然后我找到了那个隐藏的配置文件，里面存着一个备用地址列表。
- 我把那个列表清空了，塞进了我树莓派的新公网映射地址。
- 我触发了一个强制更新指令。
干完这些，我心想这下应该稳了。结果，有他妈的四分之一的用户报告说，地址更新失败，还是连接到那个已经烂掉的旧地址上。我当场就骂出声了。
第三步：深入挖掘，发现缓存才是真凶
我当时真的想砸电脑。我抓了好几个用户的日志，一行一行比对。发现，问题出在缓存上。这帮用户用的客户端，他妈的把地址写死了，只在第一次连接失败后才去读我的备用地址列表。如果第一次连接成功过，他就会死抓着旧地址不放。
怎么办？我他妈不能让剩下的四分之一的用户都去手动改配置文件？那不得被骂死？
我琢磨了一下，既然强制更新命令能发，那我能不能发一个更狠的命令？我翻出了当初写客户端的代码，找到了一个隐藏的远程执行脚本功能。这个功能我本来是留着给自己维护用的，现在正好派上用场。
我直接构建了一个执行命令，让客户端在连接旧地址失败三次后，强制删除本地配置文件中关于旧地址的缓存，然后重新请求备用列表。
这个操作风险很大，搞不好直接把用户的数据也搞没了。但是没办法，总不能让服务彻底停摆。我忐忑不安地执行了命令，然后盯着控制台看。五分钟后，连接数开始噌噌地往上涨。我松了一口气，成了。
妈的，为了这么个破事，我连着熬了三天夜。我老婆问我干嘛，我说我在抢救我的精神食粮。她白了我一眼，说：“你那破玩意儿值几个钱？” 我跟她说，这不是钱的事儿，这是面子的事儿。以后得长个教训，核心地址，必须放在自己手里，不能相信任何的服务商。