Talk is Cheap, Show me the Code! <<网站首页文章列表

  • 实现一个关于队列的伪需求是一种怎样的体验

    最近花了一天的时间,在实现一个关于队列扩展的伪需求。就是当队列消息有积累的时候,如果对队列中的消息进行去重,或者说在一定范围内去重。 场景比如,有一个用于通知搜索引擎进行职位索引更新的消息队列,消息内容就是职位主键positionId,当职位数据更新频繁的时候,在队列中积累了100个消息,其中有30个消息都是关于同一个职位A的。那么,我的需求就是如何在这些消息被消费前,将其根据职位主键进行去重,也就是说,职位A的索引更新,我只想执行一次,而不是30次。我之所以把这个需求称为伪需求,因为队列本身就是为了有序进行任务的一个数据结构,即先进先出。而经过去重,本质上就是对于同一个主键,都只执行一次,因此顺序是不能严格保证的,不过在主键上还是保留了大方向上的有序性。即使是伪需求,对于我们目前的情况来说,还是很有必要的。 需求针对的数据范围从目前的索引更新日志分析看来,任务高峰时期,在几十毫秒内会有十来个相同的消息(每个消息都是一批职位主键)连续从队列中被消费。我自己定义的数据范围的概念就是:当队列中消息积累的某个时刻,针对这些积累的数据进行去重,这些积累的数据就是数据范围,这是一个动态的数据范围。每当进来一个消息,就会针对当前的数据范围进行去重,保证当前数据范围不会存在重复数据。发生这种重复的现实原因就是,索引更新队列的通知服务是开放的,公司内部很多其他服务都会通知搜索引擎进行数据更新。比如职位服务在发布、更新职位时,算法服务在进行职位匹配后,数据统计服务在统计职位数据后等等。而且很多时候,由于功能的先后接入以及缺乏相关良好的规划,甚至会出现一些重复通知的情况,在一个调用链中,上下游可能会重复通知索引更新队列

    队列   rabbitmq   Spring   过滤器   2019-10-18 浏览(280) 阅读原文>>
  • SpringBoot2从零开始(三)—— rabbit MQ

    RabbitMQ是流行的开源消息队列系统,用erlang语言开发。RabbitMQ是AMQP(高级消息队列协议)的标准实现。如果不熟悉AMQP,直接看RabbitMQ的文档会比较困难。不过它也只有几个关键概念,这里简单介绍。几个概念说明: + Broker:简单来说就是消息队列服务器实体。 + Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。 + Queue:消息队列载体,每个消息都会被投入到一个或多个队列。 + Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来。 + Routing Key:路由关键字,exchange根据这个关键字进行消息投递。 + vhost:虚拟主机,一个broker里可以开设多个vhost,用作不同用户的权限分离。 + producer:消息生产者,就是投递消息的程序。 + consumer:消息消费者,就是接受消息的程序。 + channel:消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务。消息队列的使用过程大概如下: 1. 客户端连接到消息队列服务器,打开一个channel。 2. 客户端声明一个exchange,并设置相关属性。 3. 客户端声明一个queue,并设置相关属性。 4. 客户端使用routing key,在exchange和queue之间建立好绑定关系。 5. 客户端投递消息到exchange。 exchange接收到消息后,就根据消息的key和已经设置的binding,进行消息路由,将消息投递到一个或多个队列里。 exchange也有几个类型,完全根据key进行投递的叫做Direct交换机,例如,绑定时设置了routing key为abc,那么客户端提交的消息,只有设置了key为abc的才会投递到队列。对key进行模式匹配后进行投递的叫做Topic交换机,符号匹配一个或多个词,符号匹配正好一个词。例如abc.匹配abc.def.ghi,abc.只匹配abc.d

    rabbitmq   SpringBoot   2019-04-26 浏览(1409) 阅读原文>>
  • 1 
    blogTest
    分享文章
     
    使用APP的"扫一扫"功能,扫描左边的二维码,即可将网页分享给别人。
    你也可以扫描右边本博客的小程序二维码,实时关注最新文章。