系统存储架构升级分享-Toy模板网

这篇具有很好参考价值的文章主要介绍了系统存储架构升级分享。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、业务背景

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

系统网络架构:

部署架构对切量上线的影响 - 内部管理系统上线对其他系统的读业务无影响
分布式缓存可进行单独扩容, 与存储及查询功能升级无关
通过缓存层的隔离, 系统扩展期间外部系统可保持不变, 只对内部管理系统升级
内部系统上线/验证时, 除了业务场景1相关的初始化操作, 仍可提供读服务，降低上线影响

二、本次升级整体实施方案:

整体实施方案图例:

（一）、设立目标

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

目前：

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

目标:

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

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

（二）、当前系统现状

1、资源使用

•当前部署结构

——机房分布，Mysql: 1主4从(机房A 1主, 3从; 机房B只读从)

——机房分布，Doris: 32C, 63个节点, 3副本

•当前应用容器（docker）数量，db最大连接数

——应用容器数量: 62 (Web分组: 25, Worker分组: 31, MQ分组: 6)

——db最大连接数100 (每个容器配置)

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

——无读写分离

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

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

——后台任务场景, 对于中间数据处理, 可以容忍主从延迟

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

——对外服务接口本次不涉及开发，服务接口不受影响；业务页面访问量少，可接受短时间内的延迟

•团队是否有ES使用经验

——部分了解, 未在项目中使用

2、数据库内部使用情况

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

表名

当前表记录数（单位：万）

最大支持条数（单位：万）

表字段数

是否可拆分出分片键

分片键字段

是否存在不带分片字段的SQL

是否有跨表查询场景

数据记录读写比

是否存在写后立即查询

使用场景

数据是否可截转

可接受的截转时长

切量后预估量

分布式DB

ES 判断条件：是否有复杂查询

ES直接双写判断条件：写后立即查询

审批流表

3.5KW

4KW

有

sku

存在

1000/1

存在写后用户手动再查询操作

1、页面创建审批流 2、页面查询审批流 3、页面数据置失效 4、审批平台回调修改

否

+3亿

✅

UI修改后需重新点击"查询"按钮;

审批流细目表 (历史数据已清理)

800W

4KW

有

增加sku

无

存在

1000/1

存在写后用户手动再查询操作

1、刷新审批流(删除+增加) 2、查询审核中流程(任务)

审批通过可转冷备

转冷备

✅

业务数据表1

3.3KW

4KW

有

sku

无

100/1

1、审批流通过后, 创建 2、数据失效, 删除操作 3、后台工具: 同步缓存(存在复杂+分页查询)

否

+3亿

✅

❌

业务数据表2

5.9KW

4KW

有

sku

存在 (新增后异常按id删除)

无

1000/1

1、业务查询/导出维度1数据 2、业务查询维度2数据2 3、后台工具: 同步缓存

否

+5亿

✅

同步大数据推送数据到缓存, 使用creator字段查询; 多个SKU分页查询

❌

支持数据表(大数据平台计算后推送)

1.2KW

4KW

有

item_sku_id

无

5/1

1、运维工具: 增加/删除记录 2、清理历史数据(任务) 3、数据查询(显示使用) 4、计算 5、大数据推送数据

按日期推送, 目前保留3天

历史数据无用 doris?

一天3~4KW

✅

删除数据dt

❌

.....

（三）、技术方案选型

1、存储选型:

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

复杂查询决策因素:

		分布式DB（mysql）	es	doris	TiDB
决策指标	产品定位	数据库（OLTP）	搜索引擎	数据库（OLAP）	数据库（OLTP+80%OLAP）
	优势	1、高并发、高吞吐量事务处理 2、稳定性 3、数据实时（写后即读）	1、全文索引 2、复杂结构化查询	高并发查询分析	1、兼具事务处理+数据分析 2、自动拓展 3、数据实时（写后即读）
	劣势	1、大量数据分析 2、手动拓展	1、事务处理 2、实时（写后即读）	1、事务处理 2、实时（写后即读）	高并发、高吞吐量事务处理
	可靠性	高（多机房）	高（多机房）	低（共享集群）	低（单机房）
	拓展性	库维度：平台管理表维度：应用控制	平台管理		库维度：平台管理表维度：应用控制
	数据一致性	最终一致性	最终一致性		强一致性
	运维支持	DBA	分公司运维	无专业运维团队	分公司DBA
	总结	复杂业务查询慢无法支持大数据量跨表查询、多维度复杂查询及全局排序单表使用分片字段查询性能快	复杂业务查询性能高	部署结构为共享集群，（特别是）写性能受外部影响大	部署架构为单机房，无法满足0级系统可靠性要求

	架构目标
结论	海量存储及高并发写	✅ 大数据量存储，基于分库字段单表查询性能高, 单库事务处理	2、数据同步方案 A-准实时同步方案：方案描述：使用DRC平台配置化完成分布式DB到ES的准实时数据同步 (注: DRC为公司内部通用数据同步平台, 可在多个数据源之间进行数据同步) 优势 B-双写强一致方案：方案描述：双写分布式DB与ES, 保证数据一致性优势数据同步方案选择建议：数据同步难点及解决方案：问题: •双表联合查询场景无法直接使用DRC平台同步, 需另开发相应的同步模块jar包, 嵌入DRC任务, 或放弃使用DRC，直接使用代码同步, 都存在开发时间长问题 •ES索引空间占用多, 冗余记录条数多, , 查询结果需排重, 查询复杂难点：流程表与流程细目节点表涉及联合查询, 两表都存在单表增删改的操作; 导致同步到ES的数据模型复杂、同步困难解决方案：（数据库表增加冗余字段, 冗余字段专用于ES查询）在DB的流程表增加待审人员, 已审人员字段, 字段的值使用空格分隔, 使用ES的分词功能, 同时ES可直接使用DRC工具直接同步此表数据, 减少同步的开发时间方案成本: 增加/修改流程细目时同步修改流程表新增字段; 开发刷新历史数据工具（四）、分阶段开发及上线实施步骤 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分布式事务支持比较弱, 无法保证跨分库时多条记录在一个事务中修改的正确性, 需要提交后进行读取后再验证确保数据正确保存业务人员名下商品数据百万时, 查询时间仍然效长, 查询性能将持续优化作者：京东零售王凯来源：京东云开发者社区转载请注明来源文章来源地址https://www.toymoban.com/news/detail-776958.html