大家在日常工作中可能会经常遇到系统更新迭代与集群重建等需求，不可避免会涉及到服务的迁移更换操作。针对不同场景和诉求，具体的处理方式会不太一样，但大致的思想和方法还是具有一定的普适意义。本文主要想和大家分享一下团队最近经历的在保障大数据高并发、低延时、高吞吐读写的同时，如何不停机地在 AWS 上更换关键大数据服务的实践，供感兴趣的同学参考。
类似在飞机高速运行的过程中完成更换关键引擎这个高难度动作
背景与挑战
笔者就职于 FreeWheel，是一家拥有完整广告管理解决方案，为客户提供互联网视频广告的投放、监测、预测、增值等关键服务的公司，目前正在被 90% 以上的美国主流电视媒体和运营商使用。
这次涉及集群重建的关键大数据服务是 Aerospike， 它是一个高性能、可扩展、可靠性强的 NoSQL 解决方案，作为 KV 存储支持 RAM 和 SSD 存储介质，并专门针对 SSD 有相应的特殊优化，目前广泛应用于实时竞价等实时计算领域。它在 FreeWheel 要求高并发、高性能、高可靠性的广告实时投放阶段扮演着重要的角色。由于公司业务场景的需求且数据服务原有的 XDR 功能 (类似 replica sync 的功能) 耗时长、成本高、无法支持数据服务的版本升级等现状，所以我们需要在 AWS 的多个 region 上重建整个 Aerospike 集群， 线上重要的业务服务（广告投放、预测与用户画像实时服务的所有流量）需要全部切到对应的新集群上。
重建和更换过程正值美国疯狂三月各种赛事阶段，面临如下挑战和需求：
对 Aerospike 实时并发百万级的读与写操作需求；
旧集群已有的上百亿条的记录和几十 T 数据量；
更换过程中不能有数据服务停机时间（停机会极大影响平台线上广告投放）；
新集群的数据不能有错漏；
更换时间越短越好，节省双集群并存带来的成本。
如何设计不停机的更换方案？
总体设计
那么如何设计这样一个关键大数据服务不停机无缝切换的方案呢？
通常对于非大数据场景，非常直接的想法就是，在 backup 和 restore 数据到新集群的过程中，暂停写入（Ingestion）端数据的写入，当新集群数据 restore 结束后再打开 Ingestion 端的写入，并且直接写入到新集群，然后用新集群来服务线上即可。
但这个思路对于大数据场景就不太适用了。由于旧集群的数据量大，据 SRE 同学以往的操作经验，backup + restore 这部分数据到新集群大约需要一个星期左右，而 Ingestion 端数据也在每秒百万级写入的量级。直接停掉 Ingestion 端、试图减少新旧集群数据的变化和干扰的方法看上去不太现实，因为会严重影响关键业务数据在线上的使用，对客户的业务和广告实时投放产生影响。
所以我们需要在同时保障数据服务大量写入和读请求的情况下另辟蹊径，以下是我们的思考和设计：
持续双写 + 主从集群灵活切换
在集群数据开启 backup 的那一刻开始，到新集群经历 restore，对齐新旧集群的数据至切换完成，再到旧集群最终下线，一直持续向新旧集群双写（图上 ） Ingestion 端进入的数据。
另外在 Ingestion 端写入数据时，业务上需要先从集群中读取旧数据然后进一步和新数据 merge 后再写回集群，所以在持续双写过程中，会存在主从集群的角色转换，其中主集群负责线上的写入与读取，而从集群主要是保持数据的同步：
阶段 1：在数据对齐前，由旧集群担任主集群角色，新集群进行快照的 restore 和同步写入；
阶段 2：两个集群的数据对齐后，由新集群担任主集群角色，而旧集群继续保持数据的同步写入。
对齐后依然持续双写可以从流程上保证两个集群的数据都不会丢，且系统一直拥有快速切换到旧集群的能力，来保证数据服务高可靠和切换过程中的永远的 Plan B 准备。
充分利用数据服务特性
在数据写入过程中，可以充分利用数据服务特性保证 Ingestion 端的数据拥有高优写入覆盖权限。之所以这么做是因为 Ingestion 端写入同一个 key 的数据版本相对于 backup 和 restore 的数据一定是较新的版本，所以需要确保较新版本的数据不会被 restore 的快照里较旧的数据覆盖。
这时可以充分利用 Aerospike 在 restore 过程中 unqiue 特性：“如果 key 在 Aerospike 里已经存在那么 restore 就不再向集群中写入该条数据”， 来保证 restore 的数据不会覆盖 Ingestion 端的最新数据版本。
加速新旧集群的数据对齐
首先我们看一下新旧集群数据不一致的区间发生在哪里，下面是一个集群切换的大致时序图：
由时序图可直观看到，数据不一致的区间会发生在：开启双写（T1）->开始 backup + restore (T2) -> 结束 restore（T3）-> 暂停写入，开始对齐数据（T4）。
如果需要记录旧集群在这一区间内所有数据变化，那么以 Ingestion 端每秒百万级的写入，可想而知，在进行 restore 和 backup 的这一周积累的数据记录有多大。这样一来通过重放数据来对齐新旧集群的时间势必会拉长。
有没有可能缩短这部分数据对齐的时间呢？
经过仔细分析，只记录 delete key 的数据变化就可以加速新旧集群的数据对齐。
在 Ingestion 端的写入场景下，由于 delete key 数据变化占整体数据写入的比例不到 1% ， 所以该优化可大大减少需要用来对齐差异的数据量，加速数据对齐的过程。大家可能会疑惑，数据服务写入涉及增删改，为什么只记录 delete keys 并且后期只 replay delete keys 就能保证新旧集群最终数据对齐了呢？我们可以一起分析一下原因。
分析
在对齐前，这个数据变化区间里涉及到的旧集群的 keys 有如下几种情况：
通过对以上各种场景的分析可见，delete key 部分相对特殊，可能会存在 Ingestion 端去在新集群中执行删除后的 key 再次被 restore 阶段写回（执行删除操作的时刻早于 restore 的操作），因此会带来新旧集群的差异。而其他场景的最新数据状态已经如实反映在新集群里，无须记录和对齐。
技术选型
技术选型部分考虑用临时的 Aerospike 小集群来记录 delete key，主要考量点有以下几个方面：
Replay 阶段对于服务 scan 的性能要求较高，期望可以在较短的时间内完成，因此对于技术栈的高性能读写具有较高的要求；
Ingestion 端有大量写入 delete key 的请求以及删除已记录的 delete keys 的请求（比如该 key 后期又重新写回集群）下，因此也对技术栈读写的性能有极高的要求；
KV 存储结构可以减少 Key 的冗余，可以减少存储的大校
在对比了 AWS S3，MySQL，Aersopike 后，综合读写高性能要求（Aeropsike 可以保证 800k 每秒的 QPS）和实现维护及 cost 成本，Aerospike 是一个 ROI 更高的选择。
分布式共享配置 + 灰度切换
Etcd 是用于共享配置和服务发现的分布式、一致性的 KV 存储系统。我们通过 etcd 来控制关键流程和灰度切换，比如是否要开启双写、是否开始记录或者停止记录 delete key、 切换 Aerospikey 主从集群、灰度切换线上服务用哪一个 Aerospike 集群等等，只需要修改相应的 etcd 配置即可，无需再修改代码升级上线，使得整个操作更方便、可控，也为随时停止操作切回原有的 workflow 的 Plan B 带来更多的灵活性。
数据验证 + 关键业务指标监控
在做完新旧集群的数据对齐后，我们通过再一轮的数据验证保证数据的准确性。考虑到数据量的大小，同时为了避免验证对线上集群和 Ingestion 的影响，以及由于对比过程是一个非原子性的操作，新旧集群的数据在高 QPS 写的场景下可能会取到不同版本的数据，所以我们采用以下三个维度来做数据验证保证数据的一致：
新旧集群的 object count 需要一致；
对 1% 的数据进行抽样对比，数据差异需要控制在 1 之内；
对于可能检测到的非常少量的差异数据，需要再一次验证新旧集群保证这些“差异”数据完全一致，彻底消除非原子性操作带来的误判。
监控部分由业务模块加上相应的关键指标，比如 Aerospike 里的 hit ratio（有多少发送到 Aerospike 的 key 并且该 key 能在 Aerospike 里找到对应的记录，即 hit_ratio = key_hit_counts / key_query_counts），就可以从另一个侧面监控新旧集群的数据质量是否一致。此外，监控部分也有对 Aerospike 本身的读写性能、QPS 等等的报警指标，帮助时刻关注对线上服务的影响和性能变化。
具体迁移更换步骤
1. 新集群构建、前期设计开发及环境监控指标等准备
按照总体设计开始双写、数据对齐、验证、监控等相关开发工作，与此同时，SRE 同学帮忙准备新集群及临时辅助集群环境，并进行初步的新集群性能测试，保证新集群的性能满足业务需求。
2. 打开双写，设置旧集群为主集群，并记录变化的 delete keys
通过 etcd 打开 Ingestion 端的双写以及记录 delete keys 的相关配置。
3. 开始旧集群数据的 backup 和 restore 过程
开始 backup 旧集群数据，backup 完成后新集群通过 unqiue 特性进行快照数据 restore。与此同时由于持续双写，所以新集群也同步写入 Ingestion 端的数据。整个过程 AWS 上每个 region 的 backup + restore 耗时大约一个星期。
4. 根据 delete 的 keys 通过 replay 对齐数据
通过记录 delete 的 keys 来进行 replay 对齐新旧集群的数据。在进行 replay 的阶段，会暂停 Ingestion 端的数据写入，防止误删后续新加入进来的数据。基于临时 Aersospike 集群的高性能，几个 region 分别根据 delete keys 重放两次的情况下（第二次重放是为了进一步保证数据都彻底删干净），存储的约五亿个 keys 的处理时间总共大约只需一个小时左右。其中由于并不是所有记录下的 delete keys 都真的需要对集群里数据进行实际操作（可回顾“加速新旧集群的数据对齐 ”里对于 delete keys 的情况分析，有一些记录的 delete keys 已经并不存在新集群里了）。实践中实际处理的数据约五千万，命中率约 9%。所以对于 Ingestion 暂停的影响非常小，后续可以通过加大 Ingestion 速率来快速追赶这一个小时的数据。
执行 replay 操作结束后，会通过 Aerospike 记录的上次 Ingestion 暂停时写入的 Kafka offset 来保证数据写入的连续性，并重新恢复 Ingestion 的写入。
5. 数据验证
对齐数据后，分 batch 对新旧集群进行 sampling scan 对比，对比结果需满足设计阶段对于数据验证的要求。
6. 下游线上服务切换至读新集群
数据验证通过后下游线上服务可放心切换至读取新集群的数据。
7. 双写切换新集群为主集群，仍持续进行双写
切换新集群为主集群角色，同时响应线上的服务读取请求和 Ingestion 端的写入请求，并持续通过业务监控指标及报警观察新集群的性能和数据质量。切换后双写依然持续写入，以防极端或者未考虑的场景发生，平台仍具有 Plan B 能力可以迅速切回旧集群。用来辅助数据对齐的 delete keys 模块及临时集群此时可以下线收回。
8. 关闭双写，下线旧集群， 清理环境和代码
持续观察一到二周，线上一切正常，那么可通过 etcd 优雅地关闭双写，并下线旧集群，清理不需要的代码。
成果与体会
这次关键大数据服务的集群更换在较短的时间里圆满完成，整个过程比较平稳，0 事故发生。同时在更新的过程中统一了公司所有的 Aerospike 版本且都升级到最新的 5.x，另外也打开了 Rack Awareness 功能等等，使得广告平台上这个重要的大数据服务在 AWS 上的多 Region、多 AZ、高可用、可扩展和高性能的能力得到进一步保障。
由衷感谢团队小伙伴们通盘地考量、准备、详细的设计和快准稳的付出，以及 SRE、广告投放和预测团队的通力配合，让这个高难度操作的完美交付成为可能！
面对线上关键大数据服务要求不停机地进行更换且不允许出现一丁点儿差错的场景下，前期的设计如何仔细全面都不为过，而永远有灵活且快速的 PlanB 方案 stand by 也是可以让你沉稳地面对线上各种突发状态，并且夜晚也能安然入眠的实用利器。
