设计一个实时事件流处理系统：

• 场景：你的公司需要实现实时处理股市事件的系统。你会如何设计 Kafka 架构，包括主题设置、如何设定分区策略以及确保处理的低延迟？
• 我的文章面向所有人开放；非会员读者可以点击这个 链接 阅读全文。

提示：考虑事件的数量，基于股票代码或股票交易代码（即ticker IDs）进行分区，并使用Kafka Streams进行处理。讨论你如何配置主题以实现低延迟（例如，批大小、linger.ms参数），以及你如何处理扩展。

• 系统必须实时接收和处理股市事件，包括：
• 交易订单：各种股票的买进/卖出订单。
• 价格更新：实时的股票价格更新。
• 市场新闻报道：影响市场的新闻报道。

系统需要提供以下内容：

• 低延迟处理能力，以便实时更新分析仪表盘。
• 基于股票代码的分区，以确保同一股票的消息有序处理。

• 可扩展性：系统必须能够扩展以处理高峰负载，例如在高交易量或重大公告期间等类似情况。
• 容错性：确保没有单点故障。Kafka需要通过分区复制来确保高可用性。
• 安全性：对传输中的数据进行加密，并对访问集群的客户端进行身份验证。
• 监控：系统应提供性能监控，例如延迟、代理健康和吞吐量。

场景简介:

• 峰值吞吐量：每秒2,000次交易（TPS），涵盖多种类型的事件。
• 每个事件的平均大小：1 KB。
• 交易数据的保留期限：7天。
• 复制因子：3（用于容错性）。

1. 数据量估计：

    数据传输速率 = 2000 TPS × 1 KB = 2 MB/s

    每日数据量为 2 MB/s × 60 × 60 × 24 = 172.8 GB 每天

    七天内的总数据量为 172.8 GB/天 × 7 天
                等于 1,209.6 GB ≈ 1.21 TB

2. 存储需求 :

当重复因子是3时，

= 1.21 TB × 3 = 3.63 TB

3. 分区数量：

• 假设在高峰期我们有20个消费者数量。
• 先从20个分区开始，并根据增长情况进行相应调整（如果需要更高的吞吐量，可以增加到50到100个分区）。

4. 网络带宽估算：

    摄入带宽：2 MB/s  
    复制带宽：4 MB/s（每个消息复制2个副本）  
    总带宽：2 MB/s + 4 MB/s = 6 MB/s

5. 经纪人数量:

• 如果每个经纪商可以轻松处理1 TB的存储量，那么。

代理数 ≈ 3.63 TB / 每个代理 1 TB ≈ 4

高层次设计定义了系统的结构、重要组件及其数据流。

1. 制片人：

• 生成事件的应用：Trade Service，Price Update Service 和 News Service。
• 生产者使用股票代码作为分区键，并将数据发送到各自的 Kafka 主题中。

2. Kafka 集

• 话题：

为不同的事件类型创建各自的主题，例如帖子或讨论区：

• stock_trades : 用于记录交易事件（例如买入/卖出订单）。
• stock_prices : 用于捕获股票的实时价格变化。
• market_news : 用于捕获市场新闻。
• 分区 : 每个主题按股票代码进行分区，以支持并行处理。
• 复制 : 每个分区的复制因子为3，以确保高可用性。

3. 消费者们 ：

• 分析服务：从主题中消费消息以进行实时数据分析。
• 仪表板服务：消费处理过的数据在用户界面上进行可视化展示。
• 归档服务：归档服务：消费数据，以便在数据湖中归档事件，供历史分析使用。

4. 监控与安全组件

• 监控工具：使用如 Prometheus 和 Grafana 这样的工具来监控 Kafka 指标（消费者滞后、代理状态）。
• 安全：
• 使用 SSL/TLS 来加密传输。
• 使用 SASL/SSL 进行客户端认证和授权。
• 使用 ACL 控制对主题和消费者组的访问权限。

1. 生产者将事件发送到Kafka集群，按照股票代码将消息推送到特定的分区。
2. Kafka代理节点将这些消息分布在各个分区上，并确保每个分区都被复制，从而提供容错性。
3. 不同消费组的消费者读取这些分区中的消息并实时处理这些消息。

低级别设计细节详细描述了配置、具体组件及其优化。

• 确保 Kafka 集群有足够的代理来高效应对峰值负载。
• 启用 机架感知功能，将副本分布在不同的机架或可用区以提高容错性和性能。
• 代理数量（Brokers） ：4
• 复制因子 ：3
• 同步副本最小数 ：2 （以确保数据持久性）
• 日志保留策略 ：由于股市数据需要实时处理并保留较短时间：设置 retention.ms=86400000，这样每个主题可以保留一天的数据。（以优化存储使用。）
• 日志压缩功能 ：为 stock_prices 启用日志压缩，仅保留每个股票的最新更新，启用 日志压缩 以保留每个股票代码的最新数据记录。

• 分区策略：高效分区能帮助分配负载并保证可扩展性，这非常重要。

分区数量：  
1. 根据预期吞吐量和并行处理需求来选择分区数量。  
如果预计会有高流量（例如每秒处理数千笔交易），可以从较高的分区数量着手（例如50-100），以有效地分配负载。  
2. 确保分区数量是预期消费者数量的整数倍，以便在各个消费者间均匀分配负载。

• stock_trades（50个分区）
• stock_prices（50个分区）
• market_news（10个分区，因为流量较小）
• 分区键：使用股票代码作为分区键。这确保了所有与特定股票相关的事件都被发送到同一个分区，从而保持顺序并简化处理逻辑。
• 压缩：使用Snappy压缩来减少消息大小，同时不会增加显著的开销，从而优化网络使用并提升吞吐量。

4.3 生产者设置

• 批大小：将 batch.size 设置为较小的值（例如 16384 字节），通过频繁发送小批量数据来减少延迟。
• Linger.ms：设置为较低的值，如 1 ms，以减少发送批处理前的等待时间。
• Acks：使用 acks=1 确保只有在领导者代理确认写入后才继续，减少延迟。如果持久性是重要因素，请使用 acks=all。
• 重试：将重试次数设置为 5，以管理临时故障和网络问题。
• 压缩：使用 Snappy 压缩算法来减少消息大小而不增加显著的开销，优化网络使用和吞吐量。

• 最大轮询记录 : 设置为 500 每轮获取大量记录，提高效率。
• 最小获取字节 : 保持低位（例如，1 字节），这样可以减少延迟。
• 处理框架 : 使用 Kafka Streams 以低延迟处理事件。配置 Kafka Streams 进行实时聚合、转换和计算，以高效处理。
• 配置消费者组 : 每个服务（如分析、仪表板和归档）运行在单独的消费者组中，以实现隔离和并行处理。

Kafka Streams 很适合这种场景，因为它能帮助你构建几乎无延迟的实时处理应用。下面是如何使用 Kafka Streams。

• 状态操作：用于计算移动平均或跟踪成交量加权平均价格（VWAP），请使用状态存储。这些状态存储跟踪正在进行的聚合过程，使得访问和更新中间结果更容易。
• 窗口功能：应用窗口函数来计算聚合（例如，每分钟每只股票的总成交量）。Kafka Streams支持基于时间的窗口功能，如滚动窗口或滑动窗口，这对于股票分析很有帮助。
• 容错性：使用变更日志主题备份状态存储，确保在发生故障时能够恢复状态。

• 加密：启用SSL/TLS以加密生产者、消费者和代理之间传输的数据内容。
• 认证：使用SASL/SSL对客户端进行认证，确保只有经过授权的生产者和消费者才能访问Kafka集群。
• 授权：应用访问控制列表（ACLs）以限制对特定主题和消费者组的访问权限，确保符合监管要求，如GDPR或SEC法规。
• 生产者对特定主题具有写入权限。
• 消费者根据其组有读取权限。

• Prometheus和Grafana：设置以监控消费者滞后量、代理健康以及不足复制的分区数、领导选举速率和请求延迟时间以检测任何性能瓶颈以及分区状态。
• Kafka Manager：监控消费者组并在需要时重新平衡消费者组。
• 日志聚合：与ELK（Elasticsearch, Logstash, Kibana）栈集成进行日志管理并发出告警。

伸缩性对于实时处理股票市场事件的系统至关重要，特别是在高交易量期间，比如开盘或收盘时段，或重大公告发布时：

• 扩展分区：随着流量增加，增加更多的分区。确保消费者应用程序设计为在添加新分区时能够自动调整平衡。
• 自动扩展消费者：如果在云环境或Kubernetes中运行Kafka消费者，根据CPU使用率、内存使用率或滞后指标配置自动扩展，以根据需求自动调整消费者数量。
• 重新分配协议：确保消费者实现粘性分区分配策略，通过尽量固定分区分配来减少不必要的调整。

该方案包括详细配置和架构策略，旨在设计并实现一个具有低延迟处理能力的实时事件流处理系统，以处理股票市场的事件。设计强调低延迟处理能力，并确保Kafka集群在处理峰值负载时仍能保持高可用性。该系统是可伸缩、安全且容错性强的，旨在处理股票市场的实时事件流。

这种结构化的方法能够满足功能性和非功能性需求，从而确保系统能够满足要求，提供了支持实时分析的稳健架构。

如果你需要对任何部分进行更详细的解释，请让我知道！