背景

随着公司的疾速倒退，每天推送的音讯量一直减少。之前的旧音讯零碎曾经日益不能满足现阶段推送场景的性能要求，咱们就开始从 0 到 1 构建一个残缺的音讯零碎。

音讯平台的过来

原始架构中存在各种各样的痛点与挑战：

• 接入慢，发送慢

业务接入比较慢，发送不同类型的音讯须要接入不同的 api. 音讯生产解决都很慢，影响流动经营体验。

• 流量剖析没有，各个业务间接调用相互影响

业务调用量统计不分明，无奈针对不同业务进行敞开 / 限流。

• 不足非凡音讯优先推送

不足优先级音讯，在营销类音讯大批量推送时，失常的订单相干的音讯就会沉积，阻塞会被延时。

通过下列 4 个方面进行优化：

• 接入接口对立，业务身份辨认
• 发送放慢，繁多生产转多条同时生产
• 反对音讯优先级解决

• 切换数据源存储，抉择写比 es 绝对高一点和读绝对 es 少一点的 mongodb
  

  音讯平台的当初

  音讯平台目前整体架构 *
  

  在上述过程中优先级队列如何实现？

  目前音讯平台的优先级采纳 2 种发送实现的，首先应用传统的音讯队列 kafka 进行一次优先级发送和生产，前面采纳优先线程池工作进行优先音讯发送。

  队列优先级

  kafka 自身并不反对优先级，咱们通过下列 2 个计划进行解决，人为的对 kafka 不同队列发送不同优先级音讯。

采纳创立不同的 topic, 不同优先级音讯发送到不同的 topic 中，同时在音讯生产的时候，依照不同的比例获取不同 topic 的数据进行生产。

目前的程序是优先级最高的是第二高的 2 倍，顺次进行上来。最初残余的拉取音讯值退出到优先级最高的外面 比方一次拉取 50 条，3 个 topic 那么咱们就是依照 (25 +5/ 13 / 7) 进行拉取。

高优先级音讯没有了如何让低优先级的音讯满负载拉取，即依照上述优先级最低的音讯一次性拉取 50 条音讯呢？

引入音讯拉取状态机，优先级音讯比拟低的时候，加大低优先级的生产。目前音讯服务状态机，有初始化、低负载、高负载等几个状态，通过判断上一次解决的音讯条数来确定音讯消费者以后的状态并进行拉取参数的批改，目前采纳反射的形式批改 kafka 的拉取数量。

为了加快速度发送咱们也采纳了本地线程池，本地线程工作，咱们采纳工作优先级队列。上面是提交一个线程工作的流程。

在上图中，咱们通过给一个线程工作一个自增的序列号以及之前定义的优先级值进行比拟，惟一确定一条工作的执行优先级。

在整体流程图中的延时队列咱们是如何实现的呢？

首先咱们定义延时 / 定时策略有一下几个策略：

• 大于 30 分钟音讯推送
• 小于 30 分钟音讯推送
• 低于 15s 的音讯推送

咱们将延时定时的音讯辨别上述 3 种类型之后，别离有不同的实现形式。在低于 15s 的时候咱们间接采纳了 java 自带的 delayTask 进行音讯判断 & 推送。而高于 15s 低于 30 分的，咱们本人创立了一个秒根本级别的单工夫轮，进行音讯推送，下述是工夫轮的执行。

然而咱们在这个根底上进行了局部优化，参考了 kafka 的延时队列，当工夫轮中没有须要执行的工作之后，咱们间接对执行的线程进行 wait 期待，直到下个工作提交 notify 唤醒。对于高于 30 分钟的延时工作，咱们个别先进行音讯工作的存储，在工作快要执行的 30 分钟之前，咱们将工作数据退出到秒级别的工夫轮中，参考第二种进行音讯发送。（为啥不必天 / 小时级别工夫轮，纯正是不想节约内存）

咱们在音讯推送过程中，用户的防疲劳是必要的，目前音讯核心的防疲劳场景次要有以下几种类型：

• 用户 N 天不能收到 M 条音讯
• 某个具体的场景 N 天内不能收到 M 条音讯
• 某个具体的业务 1 天内只能收到 1 条音讯

咱们在上述几种场景，次要采纳的是 mongo 进行数据的存储和聚合查问，因为如果应用 redis 场景在多用户的时候，会频繁的操作 redis, 并不是很好。且大部分防疲劳的数据咱们也仅仅最多保留 1 周，mongo 的汇合，很容易把咱们这些性能满足。当然在某个具体的业务 1 天内只能收到 1 条音讯这个场景中，咱们采纳了 redis 的 helperLogLog 进行防疲劳，缩小查问和内存耗费。尽管有一点的误差，然而咱们的应用场景上影响不是很高。

最初咱们从本人的实战总结下来构建一个音讯平台须要思考的点：

• 简略易接入
• 响应快，不影响业务
• 紧急音讯第一工夫送达用户，音讯可分级
• 音讯可回溯，可撤回
• 成果可视化
• 内容平安

关注得物技术，携手走向技术的云端