系統業務功能在系統內進行資料處理和整合，向外部系統提供結果資料的初始化（寫入）和查詢資料結果服務。
系統網路架構
部署架構對切入上線的影響——分布式快取可以單獨擴容，不會對其他系統的讀取業務產生任何影響，這與儲存和查詢功能的公升級無關，通過快取層的隔離，在系統擴容過程中外部系統可以保持不變， 並且只有內部管理系統公升級總體實施方案圖例：
全產品渠道化-切割方案：（總量為當前金額的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分布式事務支援比較薄弱，跨資料庫時無法保證乙個事務中修改的多條記錄的正確性。
當業務人員名下的產品資料為百萬時，查詢時間仍然很長，查詢效能會持續優化。
作者：京東零售王凱.
*：京東雲開發者社群 **請註明**。