某互金平台的架构重构,数据迁移步骤,以及注意要点

作者: admin 分类: 异常处理 发布时间: 2018-01-18 21:44  阅读: 378 views

背景:某互金平台根据用户量进行一次重构迁移。 考虑各种风险|隐患,根据步骤制作流程表,按步操作,防止遗漏。

数据:平台用户数百万+, 活跃用户数20w+,日PV30w+,每日交易量3000w左右。

 

语言 PHP【80%业务】
JAVA【20%业务】
JAVA【核心业务】
PHP【活动类】
数据库 Mysql一主三从
两个库
Mysql/mycat
十三个库
中间件/工具 Mongodb【日志记录】
Redis Redis
RabbitMQ RocketMQ
Dubbo/zookeeper Dubbo/zookeeper
Dms/job/xdiamond等
日志 Log4g Log4g
应用服务 PHP23个taskJAVA4个服务 JAVA11个服务等
服务器 30多台中高配 100多台中低配
工种 JAVA/PHP/前端/运维 JAVA/PHP/前端/DBA/架构师/运维
人数 12 43
开发周期 半开发式,三个月 7个月

目的:正常上线,阿弥陀佛

步骤

  • 外灰:201x-0x-0x下午老平台回完款后开始,持续至1月x号:

注:(产品协调)100名老用户+未注册过的人众员工 ,发真实的标:7天、R计划2期,分别测试回款、续投功能。

二、对外开放上线(全量迁移)

时间一:201x-0x-0x 18:00至00:30

前置: 上线当晚(测试)标的准备–(产品)

通知公测用户,公司参与上线当晚迁移用户,测试标全部不展示-1月18号完成,第二/三天(1月21号/1月22号):发标:数量少/金额小,降低处理问题的风险

时间二:201x-0x-0x 18:00至18:30

公测账号全部禁止操作—JAVA处理

DBA把外灰数据库全部备份一下。兑付数据核实,注册/强更(老平台控制),测试验证:验证老平台

加白名单—->(用户/标的/债转白名单,老平台负责人提供sql,dba执行);不强更,期间财务不能发起提现审核–财务

全量迁移第9批

标的投满(运营)

时间三:201x-0x-0x 18:30至19:00

(1)充值/提现等各种都回调完—模块负责人

(2)老平台异步通知:负责人

  1. 企业绑卡–对上线无影响
  2. 成标出账–确保成标出账成功后再迁移数据—技术负责人
  3. 充值(网关、快捷)–确保充值回调完成–技术负责人
  4. 借款人线下还款–确保线下还款回调完成–技术负责人
  5. 提现–确保提现回调完成–技术负责人
  6. 平台充值(商户)–对上线无影响
  7. 平台提现(商户)–对上线无影响
  8. 清算通知–对上线无影响
  • 一些任务调整
  1. task任务停止(负责人协调:单标 – 老平台技术负责人A,大小标-老平台技术负责人B,接收资产端数据-相关负责人C)
  1. 停掉服务之前,技术核实;
  2. 脚本:05:10批量投标/php所有的task停止(运维负责);
  3. 停掉之后,技术核实;

时间四:201x-0x-0x 19:00-20:00 清洗迁移数据(DBA)

时间五:201x-0x-0x 20:00-22:00

5.1执行各种新库表、数据脚本(dba/相关负责人):2小时

校验数据(活跃/资金大的用户):

包括投资记录、待收待还总条数、未还已还金额。

5.2执行库2的各种脚本(DBA/相关负责人):DBA:1.5小时

批量投标金额变动到冻结- 相关技术人员A

5.3兑付平台数据迁到生产,历史数据加字段进行迁移:30分钟(DBA/相关负责人)

5.4活动引擎/对标系统(相关负责人)

时间六:201x-0x-0x 22:00-24:00测试

测试:未参与内测,外灰的剩余人众员工、测试组(技术/产品部确定名单)

冒烟测试用例—测试负责人

6.1重构新系统解禁账号,进行测试—-技术负责人

6.2校验数据:迁移前后,数据校验

6.3功能验证:推送到兑付平台(相关技术负责人)

时间七:201x-0x-0x 21:00-21:30 正式上线

前置:安卓强更接口联调—APP相关负责人(2017-12-29完成)

7.1如果出现严重问题,重构项目不上线,继续使用原来的老平台。

  • 第9批白名单删除,注册限制;
  • task启动:运维/相关负责人
  • 公司内部第9批用户:比对老平台/重构数据,手工处理

7.2如果没有严重问题,经评估后,切域名,对外开放。

三:开放

登陆注册,black名单去掉(相关技术人员)

开启强更接口(控制负责人)

成长红包激活(相关技术人员)

Boss后台强更配置(IOS/android的相关技术人员)

(防止DNS缓存,前端提醒页面—运维/相关前端)

  • 注意点
  1. 压力测试(外灰前完成,2017-12-28开始)/ 阿里云全链路压测PTS(运维|DBA|技术相关人员)

1.1注意垃圾数据

1.2压测场景:首页/登陆/投标/个人中心/活动 (测试人员·)

  1. 外灰时,老平台满标,新平台批量投标及后续流程校验(测试人员/财务负责人)
  2. 老平台异步通知梳理,并评估是否对上线计划有影响。(技术负责人)
  3. 上线前一天,老平台5点以后不要发标,而且尽量减少发标数量。(产品)
  4. 期间app控制不能强更新。(移动端负责人)

 

备注:

可能由于牵头人没有足够的经验,一些步骤还是缺失了细节。导致上线过程跌跌撞撞的。

还是发生了一些小插曲。

  1. 上线前,由于部分项目程序没有完全停止,导致停服后,依然后数据查询或者数据进入,致使DBA在导数据的时候发生中断,延时30分钟左右

处理:先检查所有项目运行状态【老平台项目已经全部关闭,新平台服务开启但是禁用状态,后台管理没有限制,发现首页刷新、后台操作有影响,先把新平台的所有服务都关闭了。保证数据的正常迁移导入】,处理时间1个小时30分钟

2. 数据迁移出错

原因:在测试阶段,包括内灰、外灰阶段,没有对这种整体迁移数据进行完全演练。导致107张表的数据,有2张表遗漏。可能会影响之后的回款、投资等操作。

处理:根据需求,进行需求数据分析,根据备份库表的对应关系,进行数据sql整理,导入成功。 处理时间2个小时【3个人】.

3. 一个查询操作,在上线前一天进行了调整。由于用了DynamicDataSource进行数据源的动态切换。可能导致并发情况下,产生严重的系统问题。

处理:功能回归上个版本,【上线前,还是不要进行太大的变动,以及没有验证过的功能,影响未知,风险太大】,紧急回退处理2个小时

4. 13个服务,每个服务4个节点,查看后台日志不是太方便,也查到一些报错,或者连接超时问题。

处理:dubbo超时时间处理,慢sql优化加索引 ,功能禁用屏蔽。根据问题进行处理

5. 开发全服时,发生解禁失败,在到达用户可以访问的时间的时候,全面无法登陆,boss暴怒。影响面太广

处理:始作俑者不在,立马电联处理,几个技术联合处理,各种状态处理。【测试不到位,基本工作没有做好】,处理1个小时左右

6. 其他个别小问题

7. 凌晨,行政点了一波外卖火锅。大家吃的不亦乐乎,哎!,就是容易坏肚子。

 

总算上线成功了,比预计时间要花了7个小时以上。还是要多多总结,多多考量,综合大家多想想可能发生的问题环节,进行提前预防处理。劳神损身的熬夜最起码是有效果的。好好休息休息,开始迎接新的一天吧

 

后期出现了问题:

  1. 一个小伙做发放优惠券的活动,几十万的数量,开启了成千上万个线程。搞奔溃了一个优惠券服务节点。导致影响了投标、资金问题。需要对账很多数据,以及熬夜伤身
  2. 主从库的问题。程序在主库修改了数据之后,没有即刻更新到从库,可能存在200ms的延时。而程序在修改完数据之后要立马修改查询从库,可能10ms左右。误差时间导致各种程序问题。幸亏是偶发性的。部分数据进行调整即可。
    1. 在监测压力时,数据库的连接数时在正常阈值以内的。只不过流量会有飙升。【注:11点左右发生,运维发现服务奔溃之后没有及时通知,而是在晚上10点在告知,导致排查问题有影响。在做程序的时候没有对主从更新时间有延时进行考虑。全部都有影响。】

  1. 18-01-26日,出现了MQ阻塞情况。 由于rocketMQ运用不熟练,导致在配置consumer的时候,全部队列都只在这一个consumer消费。各种业务掺杂在一起 ,导致出现等待的情况。后期进行了拆分,根据业务服务的量大小拆分。后期效果明显,但是由于量多,consumer消费还是较慢。 应该对于MQ的消费配置做多重配置,分业务配置。保证不同业务的独立消费。避免阻塞。
  2. 出现了deadlock情况,需要重新启动数据库。由于日志服务中的事务长度过长,出现了等待的情况。影响面较小。但是也是一个隐患。后期进行事务拆分。避免事务过大。

   原创文章,转载请标明本文链接: 某互金平台的架构重构,数据迁移步骤,以及注意要点

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

更多阅读