扒房源线索消息推送设计

导语

扒房源数据进入线索模块,客户端(浏览器)接收数据,使用了异步消息推送设计。数据来源是搜索团队,他们通过爬虫,将数据抓取后,将数据粗略去重后扔到 Kafka 里,司南通过接入 Kafka,监听消息队列。数据抵达后,数据首先进行二次清洗,数据保存后,扔到 Redis 队列。各个服务器监听 Redis 队列,订阅消息。单机监听到消息后,将数据推送给客户端。

扒房源架构图

下图是扒房源的后端架构设计图,步骤如下:

  1. 将抓取到的数据保存到 mongoDB。抓取房365、58同城、赶集网的房源数据。使用 mongoDB 存储,是利用其特定自动判定房源是否更新,因为有的房源会不定时更新,而抓取程序是定时全量抓取,无法群分,利用 mongoDB 的更新则变更时间戳特性判定是否更新。
  2. 将 mongoDB 数据发布到 Kafka,增量更新。
  3. Kafka 集群将服务注册到 zookeeper 上。
  4. 司南服务器集群查阅 zookeeper 上的服务,找到指定 topic 下的 kafka 服务器 broker 列表。
  5. 司南服务器消费 Kafka 消息,不同服务器不会重复消费。
  6. 司南将获取到的消息进行去重处理,规则详见 jira,将符合条件的消息转为线索,持久化到 Mysql。
  7. 司南将持久化后的线索 publish 到 Redis 队列。

司南的服务器集群,监听 Redis 队列消息。每台服务器收到的消息都一模一样。

消息推送

继上面单台司南服务器接收到线索消息后,进行消息推送,其处理序列图如下。

时间窗口设计

采用长连接的方式实现消息推送,涉及到几个时间点。

  1. request 超时设计。公司 nginx 代理服务,是 30 秒超时,因此一次长连接超时时间需小于 30 秒,项目中设置为 20 秒。
  2. Kafka 消息定时获取。需要配置 poller,目前设计是 10 毫秒推送一次,一次数据最多为 5 条,即最大处理能力为 500 MPS(messages per second)
  3. 消息推送最小时间间隔。司南 workerThread 监听到 redis 消息后,并不会遍历持有的 request Map 并返回。如果监听到消息立即返回,会造成在服务端抓取数据量很大时,客户端频繁调用服务端的问题。为解决这个问题,我给 workerThread 持有的每一个 request 分配一个计数器。计数器的功能是必须满足如下任一条件,request 才返回客户端:
    1. 计数器已经计数超过指定时间 minimalSyncTime,目前设置值为 10 秒。
    2. 计数器 count 值已经达到阈值 messageSize,目前设置为 250。

    这样换算一下,如果后端有数据频繁进入,以最大进入量(参考2)除以最大计数值,500 / 250 = 2,也就是在最最极端的情况下(Kafka 消息频繁进入且只有一个坐席),坐席的线索列表会每秒刷新 2 次。而在绝大部分情况下,坐席的刷新间隔应该在 10 秒一次。

  4. Redis 消息监听目前未设置时间点,数据都是即时送达的。
时间: 02-26

扒房源线索消息推送设计的相关文章

互联网产品消息推送设计策略(转)

在移动互联时代,消息推送越来越受到各个APP的重视,本文就以互金产品为例阐述消息推送的几个类别以及应用的场景方式.运营策略,希望对你有益. 在之前一文中,笔者概括性的介绍了通知功能是互金理财平台的一个基础但重要的功能.消息推送能将个人账户相关.平台相关内容送达终端用户,是为互联网产品一个重要的功能.在移动互联网时代,移动客户端出现寡头效应,消息推送愈发重要,而在互金产品中尤甚. 因此本文将开始重点阐述互金产品消息推送的类别.场景.方式和前后端推送设计策略以及运营策略. 1 定义 本文所指的"互金

设计一个百万级的消息推送系统

原文链接:https://crossoverjie.top/2018/09/25/netty/million-sms-push/ 前言 首先迟到的祝大家中秋快乐. 最近一周多没有更新了.其实我一直想憋一个大招,分享一些大家感兴趣的干货. 鉴于最近我个人的工作内容,于是利用这三天小长假憋了一个出来(其实是玩了两天??). 先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互. 最主要的工作就是要有一个系统来支持设备的接入.向设备推送消息:同时还得满足大量设备接入

一篇文章教你如何设计一个百万级的消息推送系统

前言 先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互. 最主要的工作就是要有一个系统来支持设备的接入.向设备推送消息:同时还得满足大量设备接入的需求. 所以本次分享的内容不但可以满足物联网领域同时还支持以下场景: 基于 WEB 的聊天系统(点对点.群聊). WEB 应用中需求服务端推送的场景. 基于 SDK 的消息推送平台. 技术选型 要满足大量的连接数.同时支持双全工通信,并且性能也得有保障. 在 Java 技术栈中进行选型首先自然是排除掉了传统 IO

物联网核心协议—消息推送技术演进

消息触达能力是物联网(internet ofthings, IOT)的重要支撑,而物联网很多技术都源于移动互联网.本文阐述移动互联网消息推送技术在物联网中的应用和演进. 一.物联网架构和关键技术 从开发的角度,无线接入是物联网设备端的核心技术,身份设备管理和消息推送技术是物联网云端的核心技术.而从场景体验的角度,除了前者,还要包括手机的前端开发技术. 在上一篇<一张图读懂基于微信硬件平台的物联网架构>博文中,笔者曾用一张大图详细描述了基于微信硬件平台的物联网架构的组成要素.关键场景.和通信协议

atitit.极光消息推送服务器端开发实现推送&#160;&#160;jpush&#160;v3.&#160;总结o7p

atitit.极光消息推送服务器端开发实现推送  jpush v3. 总结o7p 1. 推送所设计到底功能1 1.1. 内容压缩1 1.2. 多引擎1 2. reg  ,设置appkey and pwdkey1 3. 下载server  sdk   v31 4. push推送样例1 5. Code3 1. 推送所设计到底功能 1.1. 内容压缩 1.2. 多引擎 2. reg  ,设置appkey and pwdkey 3. 下载server  sdk   v3 https://github.c

MPush开源消息推送系统:简洁、安全、支持集群

引言 由于之前自己团队需要一个消息推送系统来替换JPUSH,一直找了很久基本没有真正可用的开源系统 所有就直接造了个轮子,造轮子的时候就奔着开源做打算的,只是后来创业项目失败一直没时间整理 这一套代码,最近比较闲就拿出来给开源做点贡献. 作为Java版的开源推送系统,MPUSH还是有很多不错的设计的,特别是对想自己搭建一套推送系统的团队 是有很大的借鉴意义的.当然开源出来也是不想曾经做过的工作白白浪费掉,特别希望对这方面有兴趣的同学 来一起把这套东西做的更好,服务更多的用户! 项目主页 http

Android消息推送机制

1.推送方式基础知识: 当我们开发需要和服务器交互的应用程序时,基本上都需要获取服务器端的数据,比如<地震应急通>就需要及时获取服务器上最新的地震信息.要获取服务器 上不定时更新的信息一般来说有两种方法,第一种是客户端使用Pull(拉)的方式,隔一段时间就去服务器上获取信息,看是否有更新的信息出现.第二种就是 服务器使用Push(推送)的方式,当服务器端有新信息了,则把最新的信息Push到客户端上.? 虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能,但是明显来说Push is

开源实时消息推送系统 MPush

系统介绍 mpush,是一款开源的实时消息推送系统,采用java语言开发,服务端采用模块化设计,具有协议简洁,传输安全,接口流畅,实时高效,扩展性强,可配置化,部署方便,监控完善等特点.同时也是少有的可商用的开源push推送系统. 特性和优势 源码全部开放,包括server.android.ios .websocket等 代码质量高,全部模块化设计,真正的商用级产品,考虑到推送中遇到的大部分场景 安全性高,基于RSA精简的加密握手协议,简单,高效,安全 支持断线重连,及弱网下的快速重连,无网络下

基于ajax与msmq技术的消息推送功能实现

周末在家捣鼓了一下消息推送的简单例子,其实也没什么技术含量,欢迎大伙拍砖.我设计的这个推送demo是基于ajax长轮询+msmq消息队列来实现的,具体交互过程如下图: 先说说这个ajax长轮询,多长时间才算长呢?这个还真不好界定.这里是相对普通ajax请求来说的,通常处理一个请求也就是毫秒级别的时间.但是这里的长轮询方式在ajax发送请求给服务器之后,服务器给调用端返回数据的时间多长那可还真不好说.嘿嘿,这关键要看我们啥时候往msmq队列中推送数据了,先看看推送的效果图吧..... 抱歉,没弄张