系统业务功能：系统内部进行数据处理及整合, 对外部系统提供结果数据的初始化(写)及查询数据结果服务。

系统网络架构:

部署架构对切量上线的影响 - 内部管理系统上线对其他系统的读业务无影响

• 分布式缓存可进行单独扩容, 与存储及查询功能升级无关

• 通过缓存层的隔离, 系统扩展期间外部系统可保持不变, 只对内部管理系统升级

整体实施方案图例:

【1、设立目标】

商品全量渠道化-切量计划（总量为当前10倍）:

目前：

当前数据库常用表均已超过5000W, 其中部分结果表达6000W, 已达到MYSQL数据库表容量峰值, 对于全切量无法支持；

目标：

最高支持9亿：根据切量计划, 全切量后系统约为6.7亿， 保留1/4的冗余, 取8.375亿; 向上取整9亿，此值冗余量较大，可满足未来5年数据支持

时间目标：

8月初方案设定, 8月17~8.22上线及验证, 8.24切量计划开始

【2、当前系统现状】

1、资源使用

• 当前部署结构

——机房分布，Mysql: 1主4从（机房A 1主，3从；机房B只读从）

• 当前业务是否读写分离，读写比例情况

• 各业务场景下，是否可容忍主从延迟？可容忍的延迟时长是多少

——目前业务人员修改操作多数为同步操作, 修改完成后返回操作结果到前端, 从业务方操作+查询结果来说, 无法空忍延迟

• 产品层面，系统出现瓶颈压力时，是否接受限流？是否接受数据延迟展示？

• 团队是否有ES使用经验

2、数据库内部使用情况

使用通用性的盘点框架对系统进行全面性现状梳理：

表内空间，业务场景等信息 （部分）

【3、技术方案选型】

系统特点：单表高并发写、复杂读

1、存储选型:

结论:

Doris: 保留, 容量增大

复杂查询（原因: 前端业务访问存在多表关联场景（2张千万级别表关联查询）, 随着表容量变大, 关联查询性能下降, 已无法满足业务高效需求）

复杂查询决策因素:

2、数据同步方案

A-准实时同步方案：

方案描述：使用DRC平台配置化完成分布式DB到ES的准实时数据同步 （注：DRC为公司内部通用数据同步平台，可在多个数据源之间进行数据同步）

优势：简单无序代码开发；劣势：可能存在业务写后即查场景，数据不一致风险

B-双写强一致方案：

方案描述：双写分布式DB与ES, 保证数据一致性

优势：保障数据写即读场景一致性；劣势：代码开发成本高

数据同步方案选择建议：

先选择A-准实时同步方案 -> 线上验证是否满足业务操作体验-> 再选择是否实施B-双写强一致方案。

数据同步难点及解决方案：

问题:

• 双表联合查询场景无法直接使用DRC平台同步, 需另开发相应的同步模块jar包, 嵌入DRC任务，或放弃使用DRC，直接使用代码同步，都存在开发时间长问题

• ES索引空间占用多，冗余记录条数多，查询结果需排重，查询复杂

难点：流程表与流程细目节点表涉及联合查询, 两表都存在单表增删改的操作；导致同步到ES的数据模型复杂、同步困难

解决方案：（数据库表增加冗余字段, 冗余字段专用于ES查询）

在DB的流程表增加待审人员, 已审人员字段, 字段的值使用空格分隔, 使用ES的分词功能，同时ES可直接使用DRC工具直接同步此表数据， 减少同步的开发时间

方案成本：增加/修改流程细目时同步修改流程表新增字段；开发刷新历史数据工具

【4、分阶段开发及上线实施步骤】

1、系统业务改造-表字段增加（8月10日）

1） 业务表新增分库字段

部分业务表缺少分库字段，无法直接分片。针对业务表新增sku分片字段，同时对现有逻辑改造增加SKU条件，以提升查询效率；

2） ES相关查询冗余字段的增加 （刷数据）

2、分布式DB分库数据同步+验证（8月11日）

1） 完成分布式DB分片库+ ES初始化;

2） 配置DRC完成原单库到分布式DB分片库的全量+增量数据同步；

3） 配置DRC完成分布式DB分片库到ES的全量+增量数据同步；

4） 通过检验工具，定期比对分布式DB单片、分布式DB分片及ES间的数据一致性。

3、读流量切换+验证 （8月17日）

1） 新增AOP切面，通过DUCC配置（erp白名单, 全量读, 结果对比等维度配置），将读请求逐步切量到新应用集群

2） 待产品、业务侧完成验证后，切换全部读流量至新应用集群（注: 新应用集群使用数据库只读帐号）

4、写流量切换（8月21日）

1) 上线前周知业务方及上下游系统，告知上线时间段及预估时长，减少业务影响

2) 新增一个静态页面提示用户系统升级中不可用，切换前端域名至静态页面, 避免用户操作

3) 停止原系统分组，确保原单库不再存有写流量，同时协调DBA对原库执行禁写（关闭worker, 暂停MQ消费）

4) 等待并确保原库数据均同步至目的库后，再次通过手动+自动方式校验新老两个数据库的数据一致性

5) 新系统分组切换为读写帐号, 进行部署

7) 研发及测试人员对新系统分组功能使用测试商品进行功能验证, 无问题后交由业务人员验证（切换静态运维页面）

8) 启动worker及接入MQ

5、上线后效果

上线后系统运行正常，8.23至今已结转商品 2.6亿；目前系统支持商品场维度数据3.16亿；最大DB表数据已有2.84亿；ES数据4356W；

前后对比：erp：xxx；此erp帐号数据29w 原查询9s，新查询1s。

好的建议：

• 全面、清晰的系统现状盘点：可以降低复杂度、提高质量

• 清晰的上线计划：指导人员合理分工、缩短上线时间、降低上线难度

未解决问题：

目前分布式DB分布式事务支持比较弱, 无法保证跨分库时多条记录在一个事务中修改的正确性, 需要提交后进行读取后再验证确保数据正确保存；

业务人员名下商品数据百万时, 查询时间仍然较长, 查询性能将持续优化。