背景

在京东到家订单中心系统中，无论是外部商家的订单消费还是上下游系统的依赖，订单查询的调用量都非常大，形成了一种读多写少的情况。订单数据最初存储在MySQL中，但由于MySQL难以应对复杂查询，订单中心系统引入了Elasticsearch（ES）来缓解查询压力。

目前，订单中心ES集群已达到10亿个文档，日均查询量高达5亿次。随着业务的迅速发展，ES集群架构也在不断演进，以确保系统的稳定性和性能。

ES集群架构演进之路

初始阶段

订单中心ES集群最初没有任何明确的架构设计，配置较为随意，且存在单点故障的风险。因此，需要逐步优化架构，以应对高并发查询的需求。

集群隔离阶段

为了避免混布集群带来的资源竞争问题，订单中心ES集群被迁移到高配置的物理机上，并实现了物理隔离。这一举措显著提高了ES集群的稳定性和性能。

节点副本调优阶段

为了充分利用硬件资源，ES集群采用了每个节点部署在独立物理机上的方案。同时，为了应对单节点瓶颈，将默认的“一主一副”配置升级为“一主二副”，并通过增加物理机来扩展集群的吞吐量。

主从集群调整阶段

由于订单中心业务对实时性要求很高，主集群的任何异常都会影响查询服务。为此，我们搭建了一个备用集群，采用双写策略，确保主集群出现异常时，查询流量可以无缝切换到备用集群。

实时互备双集群阶段

为了适应最新的ES版本和提升功能，我们对主集群进行了版本升级。在此过程中，备用集群临时接管了所有查询请求，以确保业务不受影响。升级后的主集群存储全量数据，而备用集群则专注于存储近期的热点数据，从而优化了整体性能。

ES订单数据的同步方案

订单中心ES采用了直接通过ES API写入订单数据的方式，这种方式灵活高效，满足了订单数据实时性的需求。对于写入失败的情况，系统会记录异常，并通过后台任务进行补救，以确保数据一致性。

遇到的一些坑

实时性要求高的查询走DB

ES的刷新机制会导致数据并非立即可见，因此对于实时性要求高的查询，应直接从数据库获取数据，以确保准确性。

避免深分页查询

ES的分页查询机制可能导致性能问题，因此应尽量避免深分页查询，以免影响整体性能。

FieldData与Doc Values

FieldData会占用JVM内存，容易引发性能问题。因此，推荐使用Doc Values，它是一种列式存储结构，不会占用JVM内存，且在新版ES中更为稳定。

总结

架构的快速迭代源于业务的快速发展，订单中心系统的架构也在不断优化升级。未来，更高的吞吐量、更好的性能和稳定性将是系统发展的目标。