日均 5 亿查询量的京东订单中心，为什么舍 MySQL 用 ES ?

日均5亿查询量的京东订单中心舍弃MySQL而选择Elasticsearch（ES），主要基于以下原因：

1. 应对读多写少的业务场景

订单中心业务中，订单查询调用量极大，数据呈现明显的读多写少特征。MySQL作为关系型数据库，在高并发读场景下性能受限，而ES作为分布式搜索引擎，专为海量数据的高效检索设计，能够更好地支撑大规模查询压力。
示例：订单中心ES集群日均查询量达5亿，存储数据量超10亿文档，需通过ES的横向扩展能力满足需求。

2. 支持复杂查询需求

3. 高可用性与稳定性保障

集群架构演进：京东订单中心ES集群经历了初始阶段、集群隔离、节点副本调优、主从集群调整、实时互备双集群等阶段，逐步优化为高可用架构。例如：
节点副本调优：通过增加副本数量（一主二副）和物理机扩容，提升集群吞吐量。
实时互备双集群：主集群存储全量数据，备集群存储热点数据，两者可互相降级，确保查询服务无单点故障。
数据同步方案：采用业务双写（同步写主集群、异步写备集群）和补偿机制（数据库插入补救任务），保障ES数据与MySQL的最终一致性。

4. 性能优化与资源隔离

硬件资源优化：ES集群从弹性云迁移至高配置物理机，避免混布导致的资源抢占问题，并通过“一节点一物理机”部署方式最大化利用资源。
分片策略调整：根据查询类型（单ID查询、分页查询）动态调整分片数量，平衡横向扩容规模与查询性能。例如：
分片数过多会提升单ID查询吞吐量，但降低聚合分页查询性能；
分片数过少则反之。通过多次压测选择最优分片数。

5. 应对业务时效性要求

近实时搜索能力：ES默认每秒执行一次Refresh操作，文档变化在1秒内对搜索可见。对于实时性要求高的查询（如订单状态变更），仍需通过MySQL保障数据准确性，但ES可满足大部分近实时场景需求。
热点数据优化：备集群仅存储近几天的热点数据，文档量约为主集群的1/10，在相同部署规模下性能更优，可快速响应高频查询。

6. 版本升级与功能迭代

主集群从ES 1.7升级至6.x版本，利用新版本性能优化和功能增强（如Doc Values替代FieldData）。Doc Values将排序数据存储在Lucene文件中，避免占用JVM Heap内存，解决线上查询超时问题。

7. 避免深分页查询陷阱

ES分页查询通过from和size参数实现，但深分页（如from=10000, size=10）会导致每个分片构造长优先队列，消耗大量CPU和带宽。订单中心通过优化查询逻辑避免此类问题。

总结

京东订单中心选择ES替代MySQL，核心原因在于ES的分布式架构、高效检索能力、高可用性设计以及灵活的资源扩展方案，能够更好地满足海量订单数据的复杂查询需求。同时，通过双集群架构、热点数据优化和版本升级等手段，ES集群在稳定性、性能和实时性方面达到业务要求，支撑了日均5亿查询量的高并发场景。

热门标签