什么是同城流？
在日常网络架构中，同城流指的是同一城市内不同数据中心或服务器节点之间的数据传输过程。比如你在杭州，公司有两个机房分别位于滨江区和余杭区，用户请求从一个机房切换到另一个时，就会产生同城流。这种架构设计本意是为了提高容灾能力和访问速度，但在实际运行中却常常遇到各种问题。
延迟波动大，响应忽快忽慢
很多人以为同城距离近，网络一定稳定，但现实并非如此。城市内部的光缆可能要绕行骨干节点，中间经过多个运营商设备，一旦某个环节拥塞，延迟就会上升。曾有团队反馈，两个机房直线距离不到20公里，但高峰期ping值能从5ms飙到60ms以上。这时候用户的操作就像点外卖，明明餐厅就在楼下，却等了半小时。
带宽瓶颈容易被忽视
很多系统在设计初期只考虑业务流量，没预留足够的跨机房同步带宽。当数据库主从复制、日志同步、缓存更新同时进行时，链路很快被打满。结果就是新订单写入后，在另一个机房查不到，用户以为没提交成功，又点了一遍，造成重复下单。这种情况在促销活动期间尤为常见。
典型场景示例
假设你运营一个本地生活平台，用户在A机房下单后，B机房的服务需要实时获取该订单状态来安排配送。如果网络带宽不足或策略不当，B机房看到的数据可能是滞后的：
<!-- 伪代码表示数据同步延迟的影响 -->
if (order.status == "pending" && currentTime - order.timestamp > 3000) {
log("警告：订单状态延迟超过3秒，可能影响配送调度");
}
心跳检测误判引发脑裂
为了保证高可用，系统通常会设置心跳机制判断对端是否存活。但如果网络短暂抖动导致心跳包丢失，就可能触发错误的主备切换。两个机房同时认为自己是主节点，开始对外服务，最终导致数据冲突。这就像两个人打电话突然断线，双方都以为对方挂了，于是各自行动，结果安排重叠。
DNS解析影响流量调度
有些企业用DNS轮询实现同城多机房的流量分发，但本地ISP的DNS缓存可能导致用户长时间固定访问某一个机房。即使其中一个机房已经过载，新用户还是不断被分配过去。更好的做法是结合HTTP层的负载均衡器动态调度，或者使用Anycast IP技术让路由自动选择最优路径。
防火墙策略限制数据互通
运维人员出于安全考虑，常默认关闭跨机房的端口通信。比如Redis集群跨机房部署后发现无法握手，排查半天才发现是防火墙没放开6379端口。这类问题不在技术设计文档里，却实实在在卡住上线进度。建议建立标准化的跨机房通信白名单模板，减少人为疏漏。
监控覆盖不全难定位问题
多数监控系统关注服务器CPU、内存，却忽略链路质量指标。当用户反映“有时快有时慢”，查看服务器一切正常，其实问题出在网络抖动上。应该增加对RTT、丢包率、吞吐量的持续采集，并设置基线告警。例如每5分钟记录一次两机房间的mtr结果，长期积累后可以发现规律性拥堵时段。