• 忆水寒
    2019-11-11
    这个问题其实问的是幂等性问题,在目前流行的几种MQ中都可能存在。比如Kafka,在kafka实际上有个offset的概念,就是每个消息写进去,都有一个offset,代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的offset来继续消费吧。但是凡事总有意外,比如我们之前生产经常遇到的,就是你有时候重启系统,看你怎么重启了,有时候直接kill进程再重启。这会导致consumer有些消息处理了,但是没来得及提交offset,尴尬了。重启之后,少数消息会再次消费一次。其实重复消费不可怕,可怕的是你没考虑到重复消费之后,怎么保证幂等性。
     1
     11
  • 随心而至
    2019-11-11
    分布式数据存储,好像都是利用某种hash算法将数据存在不同的机器上。Kafka: hash(消息的键)来确定分区;Redis:hash(key)来确定slot;ES:hash(docId)来确定shard。
    
     5
  • 信xin_n
    2019-11-12
    好像有点明白了,发布订阅模式是 push 模式,消息队列是 pull 模式。
    
     4
  • 观弈道人
    2019-11-22
    感觉这个有点问题吧,不管是订阅还是队列模式,都是broker“送货上门”给消费端的,希望聂老师能再解释下,谢谢!
    
     2
  • 阿卡牛
    2019-11-11
    我理解的消息队列模型,同一份消息只能被消费一次吧?
     2
     2
  • 青莲
    2019-11-23
    每个消费者都有维护一个自己消费消息的偏移量,可以存储在本地,或类似zookeepr的协同服务上,每次重启都去协同服务上拉取上一次消费的偏移量,从上一次记录开始消息;当然这种情况,由于各种异常原因还是有可能消息至少被消费一次,如常见的消息重放等,所以需要在业务方消费时进行业务上的幂等处理
    
     1
  • 小明
    2019-12-12
    听下来感觉一个是push一个是pull,可是我用消息队列也是push啊,学完有点晕了
    
    
  • 一毛钱
    2019-11-30
    kafka的offset就是解决多消费者的问题的
    
    
  • 易儿易
    2019-11-29
    思考题:不是可以使用线程安全的队列吗?数据结构里是支持的,产品型的消息队列中间件不支持吗?
    
    
  • kylexy_0817
    2019-11-28
    在消费端作幂等处理,如在缓存上记录消息是否有被消费过,或在数据库的层面加上唯一索引约束数据只能被插入一次
    
    
  • 行下一首歌
    2019-11-11
    可以在也许层面做防止重复消费的逻辑
    
    
  • tracy
    2019-11-11
    1.消息端实现幂等性,比如支付消息,以订单号为唯一标识,消息时候可以根据状态判断是否处理过,数据库加上唯一索引
    2.消费时候可以再内存中加set去重
    3.应该需要根据不同的业务分析处理
    
    
  • Jackey
    2019-11-11
    这里想到可以考虑从consumer端控制,consumer消费消息时,broker可以返回一个偏移量,由consumer记录这个偏移量。下次消费时直接从偏移位置处开始消费。
    或者由broker来记录消费者和对应偏移量,消费者要重复消费时直接不返回数据。但broker之间的数据同步应该会使系统更加复杂
    
    
  • 啦啦啦
    2019-11-11
    打卡
    
    
我们在线,来聊聊吧