系统业务功能在系统内进行数据处理和集成，向外部系统提供结果数据的初始化（写入）和查询数据结果服务。
系统网络架构
部署架构对切入上线的影响——分布式缓存可以单独扩容，不会对其他系统的读取业务产生任何影响，这与存储和查询功能的升级无关，通过缓存层的隔离，在系统扩容过程中外部系统可以保持不变， 并且只有内部管理系统升级总体实施方案图例：
全产品渠道化-切割方案：（总量为当前金额的10倍）：
目前：
当前数据库有较常用的表5000w，部分结果表示 6000W，已达到 MySQL 数据库表的峰值容量，无法支持全切
目标：
最高支持9亿：根据切割计划，系统约为67亿，保留1 4的冗余，取十亿;四舍五入到9亿，这个值有大量的冗余，可以满足未来五年的数据支持。
时间目标：8月上旬节目定档，8月17日822 在线和验证，824 削减量计划开始。
当前部署结构。
数据中心分布，mysql：1个主站和4个从站（机房一个1个主站，3个从站;房间 B 只读）。
数据中心分布，doris：32C，63节点，3副本。
应用程序容器 （Docker） 的数量和最大数据库连接数。
应用程序容器数量：62（Web 组：25，工作线程组：31，MQ 组：6）。
最大数据库连接数为 100（按容器配置）。
当前服务是否为读写分离，读写比例如何。
无读/写分离。
每个业务场景都能容忍主从延迟吗？什么是可容忍的延迟。
目前业务人员的修改操作大多是同步操作，修改完成后操作结果返回前端，从业务端操作+查询结果来看，延迟是不能容忍的。
在后台任务场景中，中间数据处理可以容忍主从延迟。
在产品层面，当系统出现瓶颈压力时，是否接受电流限制？你们接受延迟数据显示吗？
本次开发不涉及外部服务接口，服务接口不受影响业务页面的访问量较低，可以接受短时间的延迟。
团队是否有使用 ES 的经验。
部分理解，未在项目中使用。
使用通用清单框架全面梳理系统的当前状态。
表中的空间、业务场景等信息（部分）。
系统特点：高并发写入，单表读取复杂。
结论：内部分布式数据库：从单分片扩展到多分片，解决海量数据存储和简单查询问题。
ES：新引入，实现复杂查询（分词查询）和全局排序。
redis：保留，需要扩展。
Doris：保留，容量增加。
查询复杂（原因：前端业务接入中存在多表关联场景（两千万个表相关查询），随着表容量的增加，关联查询的性能下降，已无法满足业务的高效需求）。
复杂的查询决策因素：
方案描述：使用DRC平台配置分布式DB到ES的准实时数据同步（注：DRC是公司内部通用的数据同步平台，可以同步多个数据源之间的数据）。
优势：：简单无序的**发展弊：写入服务后立即检查的场景可能存在数据不一致。
方案描述：双写分布式DB和ES，保证数据一致性。
优势：：保证数据读写场景的一致性弊:* * 开发成本高。
首先选择A-准实时同步方案，>满足业务运营体验、>，然后选择是否实现B-双写强一致性方案。
问题：在两表联合查询的场景下，不能直接使用DRC平台进行同步，需要开发对应的同步模块JAR包，嵌入DRC任务，或者放弃使用DRC直接使用**同步，存在开发时间长的问题。
ES索引占用空间大，冗余记录数大，需要重新加载查询结果，使查询复杂。
难点：流程表和流程明细节点表涉及联合查询，两表都有单表增删改操作因此，同步到 ES 的数据模型复杂且难以同步。
解决方案：在数据库表中添加冗余字段，冗余字段专用于 ES 查询
在DB的流程表中添加待审核人员和已审核人员的字段，字段的值用空格分隔，并使用ES的分词功能，ES可以直接使用DRC工具直接同步该表的数据，减少同步的开发时间。
解决方案成本： 新增 修改流程详情时同步修改流程表中的新字段开发用于刷新历史数据的工具。
1）业务表中新增分库字段。
部分业务表缺少数据库分片字段，无法直接分片。 在业务表中添加SKU分片字段，并在已有逻辑修改中添加SKU条件，提高查询效率
2）新增ES相关查询的冗余字段（刷数据）。
1）完成分布式分片库+ES的初始化
2）配置DRC将原单库全量+增量数据同步到分布式分片数据库
3）配置DRC将分布式分片数据库中的全量+增量数据同步到ES
4）通过校验工具，定期对比分布式数据库单体、分布式数据库分片和ES之间的数据一致性。
1）新增AOP切片，采用DUCC配置（ERP白名单、全量读取、结果对比等维度配置），逐步将读取请求切换到新的应用集群。
2）产品端和业务端完成验证后，将所有读流量切换到新的应用集群（注意：新的应用集群使用数据库只读账号）。
1）上线前通知业务方和上下游系统，告知上线的时间段和预计时间，减少业务影响。
2）增加静态页面，提醒用户系统升级时系统不可用，并将前端域名切换为静态页面，避免用户操作。
3）停止原系统分组，确保原单库不再有写流量，并配合DBA禁止写原库（关闭worker，暂停MQ消费）。
4）等待并确保原库所有数据同步到目标库后，通过手动+自动模式再次验证新旧库的数据一致性。
5） 将新系统组切换为读/写帐户进行部署。
7）研发和测试人员使用测试产品对新系统分组功能进行功能验证，无问题后交给业务人员进行验证（切换静态运维页面）。
8） 启动 worker 并连接到 MQ
系统上线后运行正常，823 大宗商品结转至今 26亿;目前系统支持商品字段维度数据316亿;最大数据库表数据为 284亿;ES 数据 4356W;
前后对比：erp：xxx;对于原始查询，此 ERP 帐户数据为 29w 9s，对于新查询，此 ERP 帐户数据为 1s
全面而清晰地盘点系统当前状态：降低复杂性，提高质量。
明确的上线计划：引导人员合理分工，缩短上线时间，降低上线难度。
目前分布式DB分布式事务支持比较薄弱，跨数据库时无法保证一个事务中修改的多条记录的正确性。
当业务人员名下的产品数据为百万时，查询时间仍然很长，查询性能会持续优化。
作者：京东零售王凯.
*：京东云开发者社区 **请注明**。