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

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

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

    队列   rabbitmq   Spring   过滤器   2019-10-18 浏览(217) 阅读原文>>
  • 从零开发参数同步框架(五)—— Spring集成

    前面几章详细介绍了这个参数同步框架代码中的工具类、服务端、客户端等代码以及相关解释。不过由于个人的语言组织能力比较弱,可能写的比较乱,部分名词容易混淆,还请各位看官连看带猜吧。截止到上一章为止,参数同步框架以及可以投入生产使用了。只是不管是客户端还是服务端的项目,都需要在web项目启动之后,手动调用一遍zk连接初始化的代码。我们回顾一下服务端初始化:java Object zkHostString props.get("ggframework.zookeeper"); //直接指定zookeeper地址 if(zkHostString ! null && String.valueOf(zkHostString).length() 0) { GgFrameworkUtil.initCuratorFramework(String.valueOf(zkHostString)); } else { //从默认配置文件加载 GgFrameworkUtil.initCuratorFramework(); }客户端初始化:java //初始化zk连接 GgFrameworkUtil.initCuratorFramework(); //创建连接池 ExecutorService pool Executors.newCachedThreadPool(); //创建需要监听的信息,这里是按约定的库和表 GgTable table new GgTable(); table.setDb("searchmanager"); table.setTable("tbmgrparameters"); try { //添加监听节点信息 GgFrameworkClient.listener(table, new IChangedService() { @Override public void excute(GgTable table) { cacheService.loadPortraitParameters(); } }, pool); } catch (Exception e) { e.printStackTrace(); }从上面的代码中不难看出,服务端和客户端都有相同的代码,那就是初始化zk连接:GgFrameworkUtil.initCuratorFr

    参数同步   Spring   2018-10-30 浏览(2101) 阅读原文>>
  • 1 
    blogTest
    分享文章
     
    使用APP的"扫一扫"功能,扫描左边的二维码,即可将网页分享给别人。
    你也可以扫描右边本博客的小程序二维码,实时关注最新文章。