线上问题改造-如何思考、从哪里下手

结构化思维：工作中很需要 WWH ==>WHY 、WHAT、HOW 围绕这几个 其实就能做很多事情

发生场景：以数据量大、需要将DB更换mysql转换成mongo来举例

目前已知：mysql表 t1 数据量约 5000 w，每次流量高峰期会产生大量slow sql

1、为什么需要改造(背景)

改造原因：发生的原因(业务量大时，大量慢sql严重影响服务的运行,必须要进行优化)

2、分析现有结构影响

会有哪些影响？(有哪些服务调用流程图 、调用频率)

3、如何改(怎么改)

3.1 针对分析的结构。设计的方案如何满足呢？

分析现状：每天产生数据大约多少？(统计最近几天的实际量，用数据说明可行性)

方案1、继续针对mysql做服务器升级？分表分库、建索引？—已经无效了，之前已经做过优化了

方案2、换用其他的NOSQl数据库？采用mongo

• 我们对设计的数据是多少？需要分表存储多少？每张表需要存储多少数据？总共需要存储多少数据

• 对应的mongo DB设计(表结构、索引、分表、容量)

3.2 历史数据迁移问题

1、针对t1中存在的数据如何迁移、当天增量的数据如何迁移

2、迁移程序的一个处理、支持中断传输、支持暂停/停止传输、支持查看查看传输进度

3、预估时间处理、大概多久

3.3 对现有的服务影响

列举出影响的服务列表

3.4 变更之后的影响

可能会涉及的问题说明(当节点扩容时是否会高压力、对那些中间件会有影响呢？ ) 列表清单

3.5 风险点(所有可能的问题)

• 改动的范围影响
• 是否能改修改完全
• 上线时资源问题

3.6上线注意要点

• 代码分支提交、合并
• 其他中间键的配置等