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验证预备： 详细灰度案例和数据源切换步骤： 整体数据迁移流程还是比较复杂的，时光也不是非常充裕（流程中还穿插着十一全链路压测改变），在有限的时光内集大家之力重复探讨发掘也许存在的问题，然后论证解决案例，不放过任何一个也许出现问题的环节，还是那句话，把问题拦截在发生之前是做服务稳定性最重大的工作。 流程中的细节还是非常多的，从数据迁移的预备工作到数据同步测试，从灰度步骤确定到正式生产切换，尤其是融合业务和数据的特色，有非常多需求考虑的细节，文中没有一一列出。 最终通过近两个月的紧张工作，无业务代码侵入、零事故、平稳地达成了扩分库分表和数据迁移的工作。

腾讯云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消耗。 　　填写完毕后单击测试连接，确定源库和目标库都测试通过。 单击授权白名单并进入下一步。 勾选对应的迁移类型，在迁移对象框中将想要迁移的数据库选中，单击 　　移动到已选择对象框。 说明 为保证迁移数据的一致性，建议选择结构迁移+全量数据迁移+增量数据迁移。 　　单击预检查并启动，等待预检查结束。 说明 如果检查失败，可以根据错误项的提示进行修复，然后重新启动任务。 　　单击下一步，在购买配置确认对话框中，勾选《数据传输(按量付费)服务条款》并单击立即购买并启动。 说明 结构迁移和全量迁移任务暂不收费，增量迁移根据链路规格按小时收费。 等待迁移任务完成即可。

阿里云ECS服务器购买配置的选择不仅仅包括CPU核数、内存及宽带多少，还需要根据实际业务场景选择对应的规格族，我们在选择阿里云服务器的时候，云服务器的实例规格、CPU、内存、带宽是选择流程中应该要点重视的地方，普通来说，我们只知道自己网站的类型、网站的访问量大约有多大，在知道网站类型和访问量的情形下，在选择阿里云服务器配置的时候，我们应该按照如下的想法进行选择： 唯一网络是阿里云福建/广东省级代理商提供阿里云各产品均可享受代理价折扣哦，详情可以咨询客服哦。 这是非常多新手用户最难选择的，由于阿里云服务器的实例规格有入门级的突发性能实例t5、突发性能实例t6、分享型S6等，还有公司级的通用型、计算型、内存型、大数据型、GPU型、本地SSD型、高主频型、FPGA型、弹性裸金属等实例规格，在实质选择的时候，第一我们依据网站类型决定选择入门级还是公司级云服务器实例规格，比如一些纯静止展示型网站，应用入门级实例规格就足够了，如果实在不知道怎么选择，可以参照阿里云官方对于实例规格和配置选型的介绍：1.实例规格族2.场景配置选型 公司在选择云服务器时CPU是云服务器的一个关键诱因，虽然CPU性能越优秀越能提升对网站程序和数据的处理实力，但这样的云服务器价钱也会非常高。所以公司在选择云服务器时肯定要依据本身的实质情形来决定。不要只考虑质量而不考虑价钱，对于普通的公司网站或者个人网站来说，选择单核或者双核的CPU就可以满足要求，如果是大型论坛或者页面游戏，在为网站选择云服务器时最好选择4核以上CPU的云服务器。 公司网站制作时一定要考虑网站上线后的同时在线人数，这个数据会对公司网站选择多大的云服务器内存起着十分重大的影响。内存容量越大，能经受同时在线访问就越多，可是需求明确的一点是，并不是内存越大越好，公司需求依据自己网站的承受实力来决定。 第四：带宽大小的选择互联网带宽随着网络通信技术的提升，其速度也在不断的提升。互联网带宽是公司网站的内容进出通道，这个通道的大小同会对网站访问的速度有作用。速度越快越容易被用户所接受，所以公司在选择带宽时，不仅要考虑到云服务器的内存（吞吐量），还需求考虑互联网在高峰时期带宽所能承受的范围。 阿里云服务器带宽选择上，普通前期可以先选择带宽小一点，后期随着访问量的增加，我们再增加云服务器的带宽是最经济实惠的。 网站安全是公司网站制作时不得不考虑的问题，而网站安全与云服务器的安全有着亲密的干系。网站云服务器也会受到病毒或是黑客的攻击，所以我们一定要提前考虑好安全问题，否则当服务碰到问题或是不是瘫痪时想要再补救就有些晚了。 云服务器的安全问题可以经过防火墙来担保，在选择云服务器时最好以自带防火墙类型为主，肯定要在云服务器上安装相应的防火墙软件。这样可以起到保护公司网站及其云服务器的影响。参照资料：阿里云web运用防火墙 阿里云购买如何省钱 第一：优惠购入手引荐：在确定好云服务器的实例规格、CPU、内存、带宽之后，在实质购入手流程中，也可以上阿里云小站领取最新版的代金券之后，在经过支付阿里云服务器等云产品订单的时候，可以勾选应用代金券，可以在节约一笔成本。 第二：寻找阿里云代理商，可以拿到比阿里云官网还低的折扣哦。比如：唯一网络的唯云官网，就是阿里云福建地区总代理。折扣优惠你懂的，详情可以咨询客服。