2020年，笔者负责的一个高德打车弹外订单系统进行了一次扩分库分表和数据库迁移。该订单系统全局部署在阿里云上，服务应用阿里云ECS部署，数据库采纳阿里云RDS，配置中心基于阿里云ACM自研，数据同步基于阿里云DTS自研以及自研分库分表组件、分布式ID组件等等。 此次进行扩分库分表的背景是，原4实例4库、各个库64张表一共256张表，部分单表已超千万量级，按目前每日单量量级，一年内单表会达到上亿条记载，单表数据量过大会带来数据库性能问题。 4实例（16C/64G/3TSSD），4库（各个实例一个库），每库64张表，共256张表。 经过RDS后台一键诊断功能，来计算表空间应用情形（这里拿测试情境数据库举例）。 数据库的瓶颈主要表现在：磁盘、CPU、内存、互联网、联结数，而联结数主要是受CPU和内存作用。CPU和内存可以经过动态升配来提高，可是SSD磁盘容量最大支持到6T（32C以下最大3T、32C及以上最大6T）。 可是现阶段兼顾成本，可先将实例扩容一倍，采纳8个实例(16C/64G/3TSSD)，各个实例建4个库（database）、各个库128张表（这里实质上是一个成本取舍的流程，理论上应该采取”多库少表”的准则，单库128张表其实太多了，单库建议32或64张表为宜）。 接下来如果实例压力提高可进行实例配置改进(16C/128G、32C/128G、32C/256G等)；将来如出现单实例升配无法解决，在考虑扩容实例，只需求将database迁移至新实例，迁移成本较小。 按单表最多1000w条数据评估，4096张表可支持日5000w单3年(10.1压测标准)、日2000w单5年的架构。（因业务表比较多，此处忽略掉单条数据大小的计算流程） 32个库，各个库128张表。将来可最大扩容到32个实例，无需rehash，只需求迁移数据。 阿里云RDS规格和价钱一览 因扩分库分表涉及到rehash流程（256表变4096表），而阿里云DTS只支持同构库数据迁移，所以我们基于DTS的binlog转kafka实力自研了数据同步中间件。 整体数据迁移工作包含：前期预备、数据同步环节（历史数据全量同步、增量数据实时同步、rehash）、数据校验环节（全量校验、实时校验、校验规章配置）、数据修复工具等。 在进行数据同步前，需求先整理一切表的惟一业务ID，只有确定了惟一业务ID才学兑现数据的同步操作。 需求重视的是： 一旦表中没有惟一索引，就会在数据同步流程中造成数据重复的危险，所以我们先将没有惟一索引的表依据业务场景增加惟一索引（有也许是联合惟一索引）。 在这里顺便提一下，阿里云DTS做同构数据迁移，应用的是数据库自增ID做为惟一ID应用的，这种情形如果做双向同步，会造成数据覆盖的问题。解决案例也有，之前我们的做法是，新旧实物采纳自增ID单双号解决，担保新旧实例的自增ID不会出现冲突就行。由于这次我们应用的自研双向同步组件，这个难题这里不细聊。 分表规章不同决定着rehash和数据校验的不同。需逐个表整理是用户ID纬度分表还是非用户ID纬度分表、是否只分库不分表、是否不分库不分表等等。 数据同步全局案例见下图，数据同步基于binlog，独立的中间服务做同步，对业务代码无侵入。 后续对每一个环节进行介绍。 单独一个服务，应用游标的方法从旧库分批select数据，通过rehash后批量插入（batchinsert）到新库，此处需求配置jdbc联结串参数rewriteBatchedStatements=true才学使批处理操作生效。 另外特殊需求重视的是，历史数据也会存在不断的更新，如果先开启历史数据全量同步，则刚同步达成的数据有也许不是最新的。所以这里的做法是，先开启增量数据单向同步（从旧库到新库），此时只是开启积压kafka消息并不会真正消费；然后在开始历史数据全量同步，当历史全量数据同步达成后，在开启消费kafka消息进行增量数据同步（提升全量同步效率变少积压也是核心的一环），这样来担保迁移数据流程中的数据一致。 增量数据同步考虑到灰度切流稳定性、容灾和可回滚实力，采纳实时双向同步案例，切流流程中一旦新库出现稳定性问题或者新库出现数据一致问题，可迅速回滚切回旧库，担保数据库的稳定和数据稳妥。 增量数据实时同步采纳基于阿里云DTS的数据订阅自研数据同步组件data-sync兑现，主要案例是DTS数据订阅实力会自动将被订阅的数据库binlog转为kafka，data-sync组件订阅kafka消息、将消息进行过滤、合并、分组、rehash、拆表、批量insert/update，最后再上交offset等一系列操作，最终达成数据同步工作。 整体流程中有几个问题需求重视： 问题1：怎样预防因异步消息无顺序而致使的数据一致问题？ 第一kafka异步消息是存在顺序问题的，可是要知道的是binlog是顺序的，所以dts在对具体进行kafka消息投递时也是顺序的，此处要做的就是一个库担保只有一个顾客就能保障数据的顺序问题、不会出现数据状态覆盖，从而解决数据一致问题。 问题2：是否会有丢消息问题，假如顾客服务重启等情形下？ 这里没有采纳自动上交offset，而是每次消费数据最终入库达成后，将offset异步存到一个mysql表中，如果顾客服务重启宕机等，重启后从mysql拿到最新的offset开始消费。这样惟一的一个问题也许会出现瞬间部分消息重复消费,可是由于上面介绍的binlog是顺序的,所以能担保数据的最终一致。 问题3：update转insert会不会丢字段？ binlog是全字段发送,不会存在丢字段情形。 问题4：循环消息问题。 后面进行单独介绍。 前文有提到，由于是256表变4096表，所以数据每一条都需求通过一次rehash重新做分库分表的计算。 要说rehash，就必须先介绍下目前订单数据的分库分表策略，订单ID中冗余了用户ID的后四位，经过用户ID后四位做hash计算确定库号和表号。 数据同步流程中，从旧库到新库，需求拿到订单ID中的用户ID后四位模4096，确定数据在新库中的库表位置；从新库到旧库，则需求用用户ID后四位模256，确定数据在旧库中的库表位置。 想象一下，业务写一条数据到旧实例的一张表，于是诞生了一条binlog；data-sync中间件接到binlog后，将该记载写入到新实例，于是在新实例也诞生了一条binlog；此时data-sync中间件又接到了该binlog……不断循环，消息愈来愈多，数据顺序也被打乱。 怎样解决该问题呢？我们采纳数据染色案例，只要能够标识写入到数据库中的数据使data-sync中间件写入而非业务写入，当下次接收到该binlog数据的时候就不必进行再次消息流转。 所以data-sync中间件需求，各个数据库实例创建一个事务表，该事务表tb_transaction只有id、tablename、status、create_time、update_time几个字段，status默认为0。 再回到上面的问题，业务写一条数据到旧实例的一张表，于是诞生了一条binlog；data-sync中间件接到binlog后，如下操作： 此时data-sync中间件将上面这些语句打包全体上交到新实例，新实例更新数据后也会生产对应上面语句的binlog；当data-sync中间件再次接收到binlog时，只要推断碰到tb_transaction表status=1的数据开始，后面的数据都直接舍弃不要，直到碰到status=0时，再陆续接收数据，以此来担保data-sync中间件只会流转业务诞生的消息。 数据校验模块由数据校验服务data-check模块来兑现，主要是基于数据库层面的数据对照，逐条核对每一个数据字段是否一致，不一致的话会通过配置的校验规章来进行重试或者报警。 通过数据校验，一旦发觉数据不一致，则需求对数据进行修复操作。 数据修复有两种案例，一种是适用于大范围的数据不一致，采纳重置kafkaoffset的方法，重新消费数据消息，将有问题的数据进行覆盖。 全局灰度案例：SP+用户纬度来兑现，SP纬度：凭仗灰度情境切量来做，用户纬度：依靠用户ID后四位百分比切流。 灰度切量的流程肯定要配合停写（秒级），为什么要停写，由于数据同步存在肯定拖延（正常毫秒级），而一切业务操作肯定要保障都在一个实例上，否则在旧库中业务刚刚调整了一条数据，此时切换到新库如果数据还没有同步过来就是旧数据会有数据一致问题。所以流程应该是： 虽然在切流之前，在测试情境进过了大量的测试，可是测试情境毕竟和生产情境不相同，生产情境数据库一旦出问题就也许是灭顶之灾，虽然上面介绍了数据校验和数据修复步骤，可是把问题拦截在发生之前是做服务稳定性最重大的工作。 因此我们提出了ABC验证的概念，灰度情境ABC验证预备： 详细灰度案例和数据源切换步骤： 整体数据迁移流程还是比较复杂的，时光也不是非常充裕（流程中还穿插着十一全链路压测改变），在有限的时光内集大家之力重复探讨发掘也许存在的问题，然后论证解决案例，不放过任何一个也许出现问题的环节，还是那句话，把问题拦截在发生之前是做服务稳定性最重大的工作。 流程中的细节还是非常多的，从数据迁移的预备工作到数据同步测试，从灰度步骤确定到正式生产切换，尤其是融合业务和数据的特色，有非常多需求考虑的细节，文中没有一一列出。 最终通过近两个月的紧张工作，无业务代码侵入、零事故、平稳地达成了扩分库分表和数据迁移的工作。

在网络相关的业务中，高弹性是往往被提及的一个架构设计目的，前两个我就碰到一个用户需求我们帮助设计一个高弹性的架构以承载他们周期性暴增的业务压力，用户90%以上的业务压力都集合在业务高峰期，因此在设计这个架构之初，我和用户就在纠结，到底是采纳更了解的“堆”服务器的想法呢，还是采取更具弹性的容器化的案例呢？其实作为一个技术人员，在问这个难题的时候就已经有确定的答案了，最终我们设计出了这样的一个架构： 容器平台选择阿里云的ACK（阿里云容器服务Kubernetes版）。其中ACK分成专有版和托管版，区分是专有版的管控节点需求用户自行预备，而托管版应用阿里云的资源进行资源管控，在托管版中又分成标准版和Pro版，其中Pro版有确定的SLA保障，生产系统建议选择Pro版。同时为了保障worker节点的内容安全，建议为充当worker节点的ECS配置云安全中心服务进行主机安全防护。 除了ACK，阿里云还提供无服务器架构的ASK，区分是ACK有ECS服务器充当worker节点，创建POD所需的资源经过ECS进行安排，而ASK没有worker节点，ASK直接在阿里云的分享资源池中经过ECI（弹性容器节点）来安排资源创建POD。 在这个项目中为了担保永远有肯定量的稳定资源供给，我们决定应用ACK再融合阿里云的ECI来兑现资源的弹性供给。ECI资源的申请和释放可经过ACK的ack-virtual-node插件出自动达成，动态增加的POD将自动运行在ECI之上。 考虑到业务高峰期和平常存在庞大的应用量落差，选择应用按流量的方法购入手互联网带宽资源，并经过购入手分享流量包将一切的互联网流量进行集合抵扣。这个项目所用到的互联网流量主要有如下三个： 鉴于ECI节点上服务的启动需求肯定的时光，而业务流量也许瞬间到达峰值，因此经过MQ来缓冲瞬时的业务压力，为运行在ECI弹性资源上的服务争取启动时光。 阿里云MQ服务依据访问协议的不同分成RocketMQ、AMQP、Kafka三个系列，对于海量的业务交易场景建议选择通过双十一检验的RocketMQ系列，在RocketMQ系列中又分成一般版和公司铂金版两个版本，公司铂金版采纳独享硬件资源，能够更充分的保障峰值吞吐实力，对于瞬时业务峰值高的业务，建议尽也许选择铂金版。 数据库采纳云原生数据库PolarDB，PolarDB可以从2个节点扩容到16个节点，单节点可改进至88核710G规格，集群采纳分布式分享存储架构，单个集群可存储100TB的数据，有赖于其采纳分布式分享存储的架构，PolarDB集群增加节点时无需进行大量的数据拷贝，因此可以在分钟级达成集群的横向扩容。 我觉得这个架构对于大部分“腰部”级其他网络行业用户都是适用的，因此共享出来，盼望对大家有所协助。

腾讯云MySQL迁移至阿里云注意事项废话不多说 ，直接分享。 1、DTS在执行全量数据迁移时将占用源库和目标库一定的读写资源，可能会导致数据库的负载上升，在数据库性能较差、规格较低或业务量较大的情况下(例如源库有大量慢SQL、存在无主键表或目标库存在死锁等)，可能会加重数据库压力，甚至导致数据库服务不可用。因此您需要在执行数据迁移前评估源库和目标库的性能，同时建议您在业务低峰期执行数据迁移(例如源库和目标库的CPU负载在30%以下)。 2、如果源数据库没有主键或唯一约束，且所有字段没有唯一性，可能会导致目标数据库中出现重复数据。 3、对于七天之内的异常任务，DTS会尝试自动恢复，可能会导致迁移任务的源端数据库数据覆盖目标实例数据库中写入的业务数据，迁移任务结束后务必将DTS访问目标实例账号的写权限用revoke命令回收掉。 4、在项目的实际运营中，我们时常会有进行升级或更换服务器，此篇我们来看一下常见的从腾讯云转阿里云一些需要注意关注的地方： 5、首先，慎重! 更换服务器的使用对于一个项目来说是大事情，也是有风险的，小编提醒您不要因为一些小利益就做这个决定。 6、关于域名备案： 腾讯云备案的域名，转阿里云后，不需要重新备案，但，要在阿里云进行接入申请。接入的申请流程，在阿里云搜索“接入备案和取消接入”就可以看到详细的图文介绍了。这个备案接入是不影响您的网站的使用的。 7、关于域名续费： 小编认为，从腾讯云转到阿里云，域名备案在阿里云接入就可以了，续费继续在腾讯云即可。这个是比较简单的，毕竟后续的数据迁移是更大的事情。 8、数据迁移之备份： 不管你采用的是什么工具、软件，不管你的技术多高行事多有条理，都必须先做备份。 9、数据库和图片的迁移： 腾讯云MySQL迁移至阿里云方法方案 方法1(推荐)，在阿里云文档里搜索“使用DTS从腾讯云云数据库迁移MySQL到阿里云RDS”，可以查看到使用DTS进行迁移到详细图文介绍。 需要注意的是，由于腾讯没有提供云数据库的公网访问方式，所以需要通过mysql proxy配置公网访问代理，执行代码也写在了帮助文档上，用mysql-proxy语句。 方法2(ftp自行迁移)：通常包括以下几个步骤：在阿里云服务器安装操作系统和网站运行环境;配置好操作系统后，可以远程终端登录到服务，完成相关服务器应用环境的安装;接下来将网站代码通过FTP上传到服务器上，配置好站点;将网站数据库导出、上传、导入到云服务器中。 方法3(阿里云迁云工具，免费，推荐)：迁云工具支持在线迁移物理机服务器、虚拟机以及其他云平台云主机至 ECS 经典网络平台或专有网络平台，实现统一部署资源的目的。 方法4(土豪玩家)：选择阿里云迁云咨询服务、阿里云网站上云数据迁移服务、阿里云迁云实施服务等，如果您是大型项目，那由阿里云技术专家来实施或帮助实施，风险会非常小，但价格也会很高。 腾讯云MySQL迁移至阿里云操作步骤如下 登录腾讯云MySQL数据库实例，查看详情页面的外网地址，包括域名和端口。 说明 若未开启外网地址，请单击开启并在弹出的对话框中单击确定。 　　登录DTS控制台。 在左侧菜单栏单击数据迁移，单击右上角创建迁移任务。 填写源库和目标库信息，具体参数配置说明如下：   库类别 参数 说明 源库 实例类型 源库实例类型，这里选择有公网IP的自建数据库。 实例地区 如果您的实例进行了访问限制，请先放开对应地区公网IP段的访问权限后，再配置数据迁移任务。 说明 可以单击右侧获取DTS IP段查看、复制对应地区的IP段。 数据库类型 源数据库类型，这里选择MySQL。 主机名或IP地址 腾讯云数据库的外网地址的域名部分。 端口 腾讯云数据库的外网地址的端口部分。 数据库账号 腾讯云数据库的默认高权限账号：root。 数据库密码 腾讯云数据库root账号的密码。 目标库 实例类型 目标实例的类型，这里选RDS实例。 实例地区 目标实例的地区。 RDS实例ID 对应地区下的实例ID，这里选择想要迁移到的目标实例的ID。 数据库账号 目标实例的拥有读写权限的账号。 数据库密码 目标实例的对应账号的密码。 连接方式 有非加密传输和SSL安全连接两种连接方式，选择SSL安全加密连接会显著增加CPU消耗。 　　填写完毕后单击测试连接，确定源库和目标库都测试通过。 单击授权白名单并进入下一步。 勾选对应的迁移类型，在迁移对象框中将想要迁移的数据库选中，单击 　　移动到已选择对象框。 说明 为保证迁移数据的一致性，建议选择结构迁移+全量数据迁移+增量数据迁移。 　　单击预检查并启动，等待预检查结束。 说明 如果检查失败，可以根据错误项的提示进行修复，然后重新启动任务。 　　单击下一步，在购买配置确认对话框中，勾选《数据传输(按量付费)服务条款》并单击立即购买并启动。 说明 结构迁移和全量迁移任务暂不收费，增量迁移根据链路规格按小时收费。 等待迁移任务完成即可。