系统存储架构升级分享

京东云开发者
• 阅读 257

一、业务背景

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

系统网络架构:

系统存储架构升级分享

  • 部署架构对切量上线的影响 - 内部管理系统上线对其他系统的读业务无影响
  • 分布式缓存可进行单独扩容, 与存储及查询功能升级无关
  • 通过缓存层的隔离, 系统扩展期间外部系统可保持不变, 只对内部管理系统升级
  • 内部系统上线/验证时, 除了业务场景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 | 43 | 有 | sku | 存在 | 存在 | 1000/1 | 存在写后用户手动再查询操作 | 1、页面创建审批流 2、页面查询审批流 3、页面数据置失效 4、审批平台回调修改 | 否 | | +3亿 | ✅ | ✅ | UI修改后需重新点击"查询"按钮; | | 审批流细目表 (历史数据已清理) | 800W | 4KW | 20 | 有 | 增加sku | 无 | 存在 | 1000/1 | 存在写后用户手动再查询操作 | 1、刷新审批流(删除+增加) 2、查询审核中流程(任务) | 审批通过可转冷备 | | 转冷备 | ✅ | ✅ | | | 业务数据表1 | 3.3KW | 4KW | 15 | 有 | sku | 无 | 无 | 100/1 | | 1、审批流通过后, 创建 2、数据失效, 删除操作 3、后台工具: 同步缓存(存在复杂+分页查询) | 否 | | +3亿 | ✅ | ❌ | ❌ | | 业务数据表2 | 5.9KW | 4KW | 16 | 有 | sku | 存在 (新增后异常按id删除) | 无 | 1000/1 | | 1、业务查询/导出维度1数据 2、业务查询维度2数据2 3、后台工具: 同步缓存 | 否 | | +5亿 | ✅ | 同步大数据推送数据到缓存, 使用creator字段查询; 多个SKU分页查询 | ❌ | | 支持数据表(大数据平台计算后推送) | 1.2KW | 4KW | 12 | 有 | item_sku_id | 无 | 无 | 5/1 | | 1、运维工具: 增加/删除记录 2、清理历史数据(任务) 3、数据查询(显示使用) 4、计算 5、大数据推送数据 | 按日期推送, 目前保留3天 | 历史数据无用 doris? | 一天3~4KW | ✅ | 删除数据dt | ❌ | | ..... | | | | | | | | | | | | | | | | |

(三)、技术方案选型

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

1、存储选型:

结论:

内部分布式DB: 由单分片拓展到多分片, 解决海量数据存储及简单查询

ES: 新引入, 实现复杂查询(分词查询)及全局排序

redis: 保留, 需扩容

Doris: 保留, 容量增大

复杂查询(原因: 前端业务访问存在多表关联场景(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, 保证数据一致性

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

系统存储架构升级分享

数据同步方案选择建议:

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

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

问题:

•双表联合查询场景无法直接使用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分布式事务支持比较弱, 无法保证跨分库时多条记录在一个事务中修改的正确性, 需要提交后进行读取后再验证确保数据正确保存

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

作者:京东零售 王凯

来源:京东云开发者社区 转载请注明来源

点赞
收藏
评论区
推荐文章
面试字节跳动Java工程师该怎么准备?值得收藏!
性能调优影响MySQLServer性能的相关因素1.商业需求对性能的影响2.系统架构及实现对性能的影响3.Query语句对系统性能的影响4.Schema设计对系统的性能影响5.硬件环境对系统性能的影响MySQL数据库锁定机制1.MySQL锁定机制简介2.各种锁定机制分析3.合理利用锁机制优化MySQLMySQL数据库Que
Wesley13 Wesley13
3年前
#分布式系统架构之# 事件驱动模式以及与之匹配的长时间处理过程讨论
     在分布式系统下,可以很多种架构从事设计,或者分布式系统对技术架构本身没有做严格的限制。但是结合自己的实践以及基于《领域驱动设计》的推荐,采用【事件驱动模式】是比较好的一种分布式系统架构方式。该模式充分实现了不同系统之间的代码解耦,所有的业务流转是通过事件广播进行驱动的。所有业务都是在针对名为【事件总线】的组件在编程,也无需知道事件的生产者
Wesley13 Wesley13
3年前
vivo 全球商城:订单中心架构设计与实践
一、背景随着用户量级的快速增长,vivo官方商城v1.0的单体架构逐渐暴露出弊端:模块愈发臃肿、开发效率低下、性能出现瓶颈、系统维护困难。从2017年开始启动的v2.0架构升级,基于业务模块进行垂直的系统物理拆分,拆分出来业务线各司其职,提供服务化的能力,共同支撑主站业务。订单模块是电商系统的交易核心,不断累积的数据即将达到单
Stella981 Stella981
3年前
LVS+Keepalived负载均衡实践与心得补遗
一.实践背景,分析:公司研发的业务系统某个功能频繁出现数据库Mysql性能问题,导致系统使用卡顿,响应慢,且数据库所在服务器CPU负载居高不下,影响其他项目系统的正常数据库访问和使用。除去研发人员优化sql工作外,作为运维人员可以尝试对当前服务架构改造,目前架构大致如下:!(https://static.oschina.net/uploads/i
京东云开发者 京东云开发者
8个月前
系统技术规划的几点概要思路
每年年底或年初都会有各种总结规划,业务部门有业务的规划,研发部门有研发的技术规划,下面分享一下对系统技术规划的几点思路。研发技术规划重点对所负责系统的技术架构升级、技术债问题以及运维问题进行梳理并根据梳理的问题制定匹配的方案,据此方案提前进行技术储备和资源
数字先锋 | 绘就“煤”好未来!
打造信息化系统是中国中煤进行业务模式创新的重要举措,涉及数字化应用能力建设、大数据体系建设与数据治理等多个场景,对系统稳定性、兼容性要求较高;从安全角度来看,信息化系统集成了大量的生产数据及人员信息,因此对现有平台进行安全升级,也是中国中煤关注的重中之重。针对中国中煤的实际需求,天翼云以自研云平台为底座,助力中国中煤信息化系统平台进行上云迁移,能够支持数据连接及业务应用在国产化环境下快速开展,为中国中煤高质量发展注入新动能。
京东云开发者 京东云开发者
2个月前
买药秒送 JADE动态线程池实践及原理浅析
一、背景及JADE介绍买药秒送是健康即时零售业务新的核心流量场域,面对京东首页高流量曝光,我们对频道页整个技术架构方案进行升级,保障接口高性能、系统高可用。动态线程池是买药频道应用的技术之一,我们通过3轮高保真压测最终初步确定了线程池的核心参数。但我们仍面
胖大海 胖大海
2年前
Redis 原理
架构原理Redis组件的系统架构如图所示,主要包括事件处理、数据存储及管理、用于系统扩展的主从复制/集群管理,以及为插件化功能扩展的ModuleSystem模块。!(https://imgblog.csdnimg.cn/i
京东云开发者 京东云开发者
11个月前
2024了,我不想再用AOP收集业务操作日志了 | 京东云技术团队
0.背景在近期的项目中,系统涉及到针对系统的业务操作日志统计功能,由于本系统位于业务链路的中心环节,负责接收上游系统的数据,并将基于用户操作产生的数据传递至下游系统,鉴于业务链路的复杂性和操作场景的多样性,我们计划通过对核心业务数据进行全生命周期的日志记录
京东云开发者 京东云开发者
10个月前
系统存储架构升级分享
一、业务背景系统业务功能:系统内部进行数据处理及整合,对外部系统提供结果数据的初始化(写)及查询数据结果服务。系统网络架构:•部署架构对切量上线的影响\内部管理系统上线对其他系统的读业务无影响•分布式缓存可进行单独扩容,与存储及查询功能升级无关•通过缓存层