万亿级数据流集群无缝迁移方案

前言

在TDBank的接入数据中，有86%的数据流向TDW集群，因此为了减少流量在IDC间穿越，TDBank的集群选择跟TDW部署在同一个IDC。但是，随着业务数据的大规模发展与接入，TDW所在IDC的机器资源已无法满足需求，因此需要迁移到其他IDC。除了因资源不足的迁移外，我们还对重点业务进行隔离的迁移，还有底层架构无法兼容带来的集群的迁移。经过多次迁移经验积累，当前我们基本上可以做到集群的无缝迁移。下面介绍TDBank集群迁移的两种通用方案。

方案一：

先迁移数据源，再迁移后端消费应用。

适用场景：

集群中业务的对数据的实时性要求不高，但是对数据的准确性和可靠性要求高，不允许数据丢失，则需要采用这种迁移方式。另外，在资源紧张的时候，采用该方案更合适，不需要任何资源。

方案优点：

1、迁移不需要任何额外的设备资源，节省成本；

2、迁移不会造成任何数据的丢失；

方案缺点：

1、迁移需要上下游各个模块的负责人同时在线，并且需要上游切换完毕后下游才能开始切换；

2、如果数据源切换失败，需要进行回退会比较麻烦，在将数据源回退写入老集群后，还需要将新集群的数据读取并写入老集群，让后端应用消费。

迁移步骤及示意图如下：

迁移前，需要把新集群的TDBus模块和Tube模块搭建部署完毕，配置好集群ID。

第一步，更改数据源配置，让数据源由发往老集群改变为发往新集群。当前的DB、File、MSG数据源均可以从TDManager动态获取发往的TDBus IP，更改配置后，5分钟左右会动态更新发送IP，让数据源切换到新集群。

第二步，迁移后端消费应用。我们可以通过监控工具动态观察后端应用是否把老集群的数据消费完毕，在消费完毕后，更改读取的tube配置重启，让其从新集群的tube消费数据。从切换数据源到后端消费应用切换，整个过程尽量控制再半个小时完成。至此方案一的切换过程已完成。

方案二：

使用TRC工具，将数据同步转发到新的集群，然后先把后端先消费应用切换，再把前端数据源切换。

适用场景：

集群中业务的对数据的实时性要求高，允许丢失少量数据，但不允许数据持续延迟。另外，该场景还适用一份数据被多份消费，并且消费方由不同人员负责，避免由于沟通协调阻碍迁移进展，让迁移更可靠和把控。

方案优点：

1、消费应用迁移比较灵活，迁移随时进行，迁移出问题可以随时回退；

2、迁移数据源过程可以持续较长时间，迁移过程中新老集群都会有数据，但是消费应用能消费全量数据，并且消费不会延迟，对业务基本没影响；

3、切换数据源出现问题可以随时回退，同时不需要将新集群数据迁移回老集群；

方案缺点：

1、进行消费应用切换过程中，由于无法知道消费应用消费的数据在新集群中的offset位置，因此消费应用启动时需要从最大offset消费数据，因此可能会造成部分数据没有被消费到而丢失，这些数据量约为消费应用重启时间间隔产生的数据量；

2、需要增加额外的资源，包括需要在老集群增加tube一份数据流量的机器，以及转发一份tube数据需要的TRC机器，在资源紧张的情况下不太适用；

迁移步骤及示意图如下：

迁移前，需要把新集群的TDBus模块和Tube模块搭建部署完毕，配置好集群ID。当然跟前面不同的是，我们还需要准备好转发TRC集群。

第一步的主要工作时将老集群的一份数据转发到新tube集群，并对转发的数据进行验证。

第二步迁移消费应用，消费应用根据自己的时间安排，随时从老集群切换到新集群，出现异常时可以随时切换回去。

第三步迁移数据源，更改数据源配置，让数据源由发往老集群改变为发往新集群。当前的DB、File、MSG数据源均可以从TDManager动态获取发往的TDBus IP，更改配置后，5分钟左右会动态更新发送IP，让数据源切换到新集群。迁移可以灰度进行，出现异常时可以随时回退，并且不用进行数据迁移。

第四步 下线转发模块，当数据源全部迁移到新集群后，就可以下线数据转发模块。至此，怎个集群迁移完成。

上面为TDBank通用的两个迁移方案，在实际的运营中，我们根据业务的特性进行选择，并成功完成集群迁移。截止目前为止，上面的迁移方案已成功应用案例包括：TDBank的meta迁移到tube、同乐公共集群迁移坪山IDC、微信集群迁移坪山IDC、广点通重点业务隔离，支持方案中的集群涉及流量达每天一万亿。