Stream Processing (1-1) - Transmitting Event Streams

Transmitting Event Streams

最後一个章节是 串流处理 (stream processing),Day 23 ~ Day 27 讲的 批次处理 (batch processing) 之输入都是有限的,而串流处理要做的就是处理无限的输入,放弃固定以时间片段执行,选择当事件发生时执行。

但其实我们可以把时间切成极细的片段(每 1 奈秒),这样批次处理就会等於串流处理了 XDD。

Messaging Systems

一般来说,串流 (stream) 是指会随着时间逐渐增加且可用的数据,此概念有被运用在很多地方,如 Unix 系统的 stdinstdout ,程序语言的 lazy list 等等。

事件 (event) 可以是字串、JSON、或二进位数据,端看系统使用的编码方式为何,而事件代表的意义很广泛,以串流处理的角度来看,事件是按日历钟时间逐渐发生的数据;以 Java 的 FileInputStream 来看,事件就是每一行的 byte;以 Day 23 的 log 分析例子来看,事件就是每一笔 log,它们都是相同的概念:一个小的、自我包含的、不可变的对象。

在串流处理的术语中,一个事件被 生产者 (producer) 产生,然後会有多个 消费者 (consumer) 处理事件,相关的事件通常被组合到同一个 topic 中。

直接讯息传递

一般常见方法是使用 讯息系统 (messaging system) 来通知消费者有新事件发生,然而有一些讯息系统不会透过中间层节点,生产者透过网路直接将讯息通知消费者,像无代理讯息系统 ZeroMQnanomsg 透过 TCP 或 IP multicast 实作 发布/订阅 (publish/subscribe) 模型。

讯息代理

另一个被广泛使用的寄送讯息之选择就是 讯息代理 (message broker) 啦,生产者和消费者都透过 broker 作业。

当多个消费者想从同一个 topic 读取讯息时,这里有 2 种讯息传递模式可选择,如下图 11-1:

  • Load balancing

    每一条讯息只会传递给其中之一个消费者,所以消费者可以并行分散的处理讯息,适合用在讯息处理是昂贵的场景上。

  • Fan-out

    每一条讯息都会传递给所有消费者,这个就像同时从同一个输入资料中执行多个批次处理作业一样,消费者之间不会彼此干扰。

但实务上会组合这 2 个模式,像 Kafka 就能多个消费者群组注册同一个 topic,每条讯息都会传递给这些消费者群组,消费者群组中是并行的接收讯息来处理。


未完喔!


<<:  DAY 16 将含LINE emoji团购讯息与关键字存到资料库

>>:  DAY13:Fragment片段之实作

[Day6] Vite 出小蜜蜂~ Scene 场景!

Day6 Scenes 在 Web 的领域里,一个网站会有页面,像是 Main Page, Logi...

IBM Cloud CLI

注册完成後,今天来安装并验证 IBM Cloud CLI 1. 下载并安装 IBM Cloud CL...

Day20 - 物理模拟篇 - 弹力、引力与磁力IV - 成为Canvas Ninja ~ 理解2D渲染的精髓

磁力/引力模拟 弹力、磁力和引力其实本质上很接近。 之所以说相近,是因为他们都是一种长距离作用力。 ...

镜面效果

大家好,我是西瓜,你现在看到的是 2021 iThome 铁人赛『如何在网页中绘制 3D 场景?从 ...

错误处理

Rust将错误分成两大类 不可复原的(unrecoverable) 可复原的(recoverable...