利用redis实现elasticsearch入库去重

背景

公司有一个业务场景，数据库的修改需要同步到Elasticsearch里，但是该场景的修改频率有点高，经常会出现一条记录短时间内多次的变化，如果每次变化都作为一次ES同步任务，那ES肯定是受不住的。

思路

通过估算请求规模，主要有如下2方面的解决思路：

• 高频变化去重：因为同一条记录短时间内多次变化，其实同步一次最终的状态即可，所以可以考虑牺牲一定的实时性，在一定时间窗口内做变化通知的去重。
• 批量导入：每条记录变化作为独立请求推送给ES，实际上远不如多条记录批量推送ES的吞吐要高。

方案

• 在线去重：因为在线业务本身是高频的，所以需要一个高频的存储介质来实现去重，想到redis的set/zset数据结构。
• 离线批量：利用离线JOB定时的将一段时间内去重的变动集合推送给ES，其核心问题在于在线set集合如何离线化，保证互不影响。

 

整体架构如下：

 

假设变动的是用户的积分等高频资产信息，那么在线部分一旦数据库发生变动，则将用户uid向zset_w在线集合写入，可以实现实时去重。

离线JOB则首先检查zset_r离线集合是否有剩余变动任务未处理，若zset_r集合为空则执行redis的rename操作将在线集合zset_w重命名为zset_r，这个过程对redis来说是原子性的。

此后离线JOB继续处理zset_r中已经去重的变化uid集合，而在线部分继续向新的zset_w集合添加最新变动的uid即可，如此往复。

优化

随着在线高频变更量的增多，该方案可以实施横向扩展，即准备N对（zset_w、zset_r）并令在线部分按uid打散流量，从而可以为每一对zset启动独立的离线JOB，实现并行处理。

鉴于在线部分操作redis异常导致通知丢失，可以通过长周期的全库离线补偿实现，在此不做说明。

结论

该业务场景的思想本质包含了2点：

• 流式转批量 换取更高的吞吐。
• 大问题拆小 实现横向的扩展。

总是思考是否有更简单的方案，做到简单可依赖。

 

本条目发布于 2018年5月25日。属于 架构&设计分类。 作者是yuer。

转载于:https://www.cnblogs.com/jpfss/p/10813164.html