[分布式项目]应用对大量Message处理方案的一些思考

问题背景

问题来源于之前公司做的项目,组内维护有 调度任务 的应用,对全量商品的每日价格信息进行离线计算,结果用于分析和制定售卖策略。计算周期根据商品的特点,设置在半小时到一天。
随着应用的推广以及业务上的需求,使用方对数据的新鲜度有了更高的要求,而当前的计算频率不能做到结果的实时性。为了提高应用的能力,满足更多的业务需求,需要对应用的实时性进行升级。
影响价格的因素有很多,根据调研,商品的价量态变化是影响最终结果的主要因素。动态信息组有维护一组消息队列,推送商品下sku的价态量的变化。对价量态的消息进行消费,每次感知到变化就对商品做一次重新计算,可以大幅提高结果的新鲜度。
由于商品的数量巨大(百万级),各个商品下又有多种sku,每分钟推送过来的变更消息量很大(千万级)。如何整合海量的消息,实现提升离线计算的商品价格新鲜度,是本次要解决的问题。

分析

商品消息格式(简化)

属性 含义
spuId 标识一类商品
skuId 标识具体的商品
effectDate 价态量变化的具体日期
updateTime 消息发生的时间

  • 22
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值