京东到家订单查询服务演进

备集群存储的是线上近几天的热点数据，数据规模远小于主集群，大约是主集群文档数的十分之一左右。集群数据量小，在相同的集群部署规模下，备集群的性能要优于主集群。然而在线上真实场景中，线上大部分查询流量也来源于热点数据，所以用备集群来承载这些热点数据的查询，而备集群也慢慢演变成一个热数据集群。之前的主集群存储的是全量数据，用该集群来支撑剩余较小部分的查询流量，这部分查询主要是需要搜索全量订单的特殊场景查询以及订单中心系统内部查询等，而主集群也慢慢演变成一个冷数据集群。

同时备集群增加一键降级到主集群的功能，两个集群地位同等重要，但都可以各自降级到另一个集群。双写策略也优化为：假设有A B集群，正常同步方式写主(A集群)异步方式写备(B集群)。A集群发生异常时，同步写B集群(主)，异步写A集群(备)。

ES订单数据的同步方案：

Mysql数据同步到ES中，大致总结可以分为两种方案：

(1) 方案1：监听mysql的binlog，分析binlog将数据同步到ES集群中

• 优点：业务与ES数据耦合度低，业务逻辑中不需要关心ES数据的写入
• 缺点：binglog模式只能使用ROW模式，且引入了新的同步服务，增加了开发量以及维护成本，也增大了ES同步的风险

(2) 方案2：直接通过ES API将数据写入到ES集群中

• 优点：简洁明了，能够灵活的控制数据的写入
• 缺点：与业务耦合严重，强依赖于业务系统的写入方式

考虑到订单系统ES服务的业务特殊性，对于订单数据的实时性较高，显然监听binlog的方式相当于异步同步，有可能会产生较大的延时性。且方案1实质上跟方案2类似，但又引入了新的系统，维护成本也增高。所以订单中心ES采用了直接通过ES API写入订单数据的方式，该方式简洁灵活，能够很好的满足订单中心数据同步到ES的需求。

由于ES订单数据的同步采用的是在业务中写入的方式，当新建或更新文档发生异常时，如果重试势必会影响业务正常操作的响应时间。所以每次业务操作只更新一次ES，如果发生错误或者异常，在数据库中插入一条补救任务，有worker任务会实时的扫这些数据，以数据库订单数据为基准来再次更新ES数据。通过此种补偿机制，来保证ES数据与数据库订单数据的最终一致性。

遇到的一些坑：

1. 实时性要求高的查询走db

对于ES写入机制的有了解的可能会知道，新增的文档会被收集到indexing buffer，然后写入到文件系统缓存中，到了文件系统缓存中就可以像其他的文件一样被索引到。然而默认情况文档从index buffer到文件系统缓存(即refresh操作)是每秒分片自动刷新，所以这就是我们说ES是近实时搜索而非实时的原因：文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。当前订单系统ES采用的是默认refresh配置，故对于那些订单数据实时性比较高的业务，直接走数据库查询，保证数据的准确性。

2. 避免深分页查询

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!