同城双活：交易链路的稳定性与可靠性探索

知易行难，双活过程中遇到了非常多的问题，但是回过头看很难完美的表述出来，之所以这么久才行文也是这个原因，总是希望可以尽可能的复现当时的思考、问题细节及解决方案，但是写出来才发现能给出的都是多次打磨、摸索之后的我们认为偏合理的方案；不过换个角度看，给大家展示出来一个正确答案，是否有更积极的参考价值呢？

以及，涉及到容器、发布平台、底层网络运维、监控等组件的内容，限于视野及技术能力并未包含在内，仅聚焦在业务团队及中间件组件的设计及改造上。

背景

2022年，基于对稳定性的焦虑...和思考，交易平台联动中间件平台启动过异地多活项目的探索，虽然完成了核心应用及基础组件的改造，但在疫情&降本增效的影响下并未真正投产，同时也缺乏充分的测试以及线上流量的大规模验证；后续在不断的业务迭代中，相关设计及代码被冲击的面目全非，相关的多活自动化测试case也并没有沉淀下来。

随着近期外部友商时有严重故障出现，比如

以上林林总总出现的故障都给我们敲响了警钟，必须建设快速恢复的能力。出现问题几乎不可避免，但如果能控制影响范围、缩短影响时间，也就能把损失降到最低。

我经历过的公司，做交易的和做中间件的往往是最容易焦虑也最容易心态失衡的两拨技术人；一方面所有问题都会暴露在C端用户面前，影响范围大且不像toB/toM的场景 避开高峰期甚至有可能无人知晓；另一方面流量高，压力大，容易面临突发流量及突发事件，稳定性这根弦需要始终绷紧；所以往往是面向稳定性(的焦虑)设计，当然熬过去成长也最快。

回到我们的现状，得物目前的交易应用及中间件基础组件都是基于某云部署，且前期为了降低跨机房调用产生的网络损耗，较多应用都绑定了存储组件(db/redis/hbase)及核心依赖下游的所在可用区，对此，为了避免在极端情况下，得物的交易主链路出现长时间不可用的情况，团队决定提前预防，启动同城双活项目。

为了避免在极端情况下，得物的交易主链路出现长时间不可用的情况，团队决定启动同城双活项目，目标是快速建设流量动态切换能力及快速恢复能力，同时降低改造难度、减少改造工作量，不增加大量额外成本。团队讨论决策绕过之前最复杂也最容易出问题的数据同步(db双向同步、redis双向同步等)，同时也不需要在流量切换时做db禁写，整体具有比较大的可操作可实施性。

多说一句，同城双活也有做数据双向同步的case，当然更彻底--每个机房都有全量的数据及应用，某个机房出问题 可以完全自闭环承接流量，不过带来的复杂度上升、成本上升也会比较明显，所以这次并没有选择这条路。换句话说，个人更倾向于小成本低风险快速落地，实现从0到1的功能建设，而不是大而全的方案，万一期间遇到问题只能徒呼奈何。当然在现阶段，通过建设相对低风险低投入的同城双活，积累更多基础能力的同时锻炼团队，选择最合适当下的方案，解决目前排在第一位的问题，怎么想都觉得还是一件挺划算的事儿。

画一幅简图来区分下我们这次同城双活的方案和业界异地双活方案的差异。

异地双活

主要特点：

1. 存储相关有两份，双机房内各自读写，双向同步

2. 数据的循环赋值需要重点考虑如何处理

3. 数据间的同步延迟问题会比较明显，不过各自机房内基本上可自闭环调用

4. 对于用户、商家资产的处理比较复杂，比如用户券、卖家库存等，一般需要考虑在某个机房维护(gzone)，避免数据同步问题带来的超卖、超用

5. 切流时需要做目标机房的局部数据禁写，避免脏数据产生

同城双活

特点：

1. 只有一份数据源，不需要考虑数据同步的延迟问题及切流时的禁写逻辑，不过若数据所在机房出问题，另一个机房无法正常承接流量(只能承接部分兜底流量，如cdn、缓存等有兜底数据的场景)

2. 不需要考虑具备中心节点性质的数据问题，如用户券、库存等

3. 跨机房访问较多，尤其是数据层面的读写，可能会造成RT的大幅上涨

不管是同城还是异地、双活还是多活(双活只是多活里最简单的场景，双活到三活难度飙升范围应该不亚于<羊了个羊>里第一关和第二关的难度)，都是为了以下目标：

1. 提高可靠性：通过在不同的物理位置部署服务，减少单点故障的风险。即使一个机房发生故障，其他机房也可以接管服务，确保业务连续性。

2. 负载均衡：可以灵活分配用户请求流量，避免单个机房过载，尤其随着业务规模的扩大 单个云厂商的机房已经无力提供更多资源的情况下。

3. 灾难恢复：通过流量的调度切换来快速恢复某个机房的故障问题，减少业务中断时间。

4. 云成本：在技术成熟度较高的前提下，做同云、跨云甚至云+自