小菜鸟

java菜鸟号正在起航

0%

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 5.3k 阅读时长 ≈ 5 分钟

Spark Streaming转换操作详解：无状态与有状态处理

Spark Streaming 的转换操作是流数据处理的核心，分为无状态转换和有状态转换两大类。无状态转换仅依赖当前批次数据，而有状态转换需结合历史批次数据或滑动窗口内的数据。本文将深入解析两类转换的原理、用法及实战案例，帮助你掌握流数据的复杂处理逻辑。

转换操作概述

无状态 vs 有状态转换

  • 无状态转换：每个批次的数据处理独立于其他批次，仅基于当前输入（如 map、filter）；
  • 有状态转换：处理依赖历史数据或跨批次的上下文信息，需维护中间状态（如累计计数、滑动窗口统计）。

核心区别与适用场景

特性 无状态转换 有状态转换
数据依赖 仅当前批次数据 历史批次数据或窗口内数据
状态维护 无需维护状态 需维护中间状态（依赖 Checkpoint）
延迟影响 低（批次内处理） 较高（需合并多批次数据）
适用场景 实时过滤、格式转换 累计统计、窗口分析、趋势预测

无状态转换（Stateless Transformations）

无状态转换与 RDD 转换操作类似，每个批次的数据独立处理，不依赖历史结果。常用操作包括 map、flatMap、filter、reduceByKey 等。

常用无状态转换操作

操作 功能描述 示例
map 对每条数据应用函数，返回新数据 lines.map(_.toUpperCase)
flatMap 对每条数据生成多个结果，扁平化输出 lines.flatMap(_.split(" "))
filter 保留满足条件的数据 words.filter(_.length > 3)
reduceByKey 按 Key 聚合当前批次数据 pairs.reduceByKey(_ + _)
repartition 重分区以调整并行度 stream.repartition(10)

实战案例：实时单词计数（无状态）

对每个批次的输入文本进行单词计数，不累计历史结果：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 5.4k 阅读时长 ≈ 5 分钟

Spark Streaming自定义数据源：扩展流处理的灵活性

Spark Streaming 内置了 Kafka、Flume、TCP 等常用数据源，但在实际业务中，常需对接自定义系统（如专有消息队列、硬件设备数据流）。此时，通过自定义 Receiver 扩展数据源成为关键能力。本文将详细解析自定义数据源的实现原理、开发步骤及实战案例，帮助你灵活扩展 Spark Streaming 的数据输入能力。

自定义数据源的核心原理

为什么需要自定义数据源？

  • 业务特殊性：需对接企业内部私有系统（如自研消息中间件、IoT 设备流）；
  • 数据格式适配：处理非标准格式数据（如二进制协议、加密数据流）；
  • 特殊采集逻辑：需在数据采集阶段添加过滤、转换等预处理逻辑。

Receiver 机制的作用

Spark Streaming 通过 Receiver 组件从外部数据源接收数据，其核心职责是：

  • 数据采集：连接外部数据源，持续接收数据；
  • 数据持久化：将数据存储到 Spark 内存（或磁盘），供后续处理；
  • 容错保障：配合 Checkpoint 机制实现数据不丢失。
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.8k 阅读时长 ≈ 3 分钟

消息一致性保障：从发送到消费的全链路解决方案

消息一致性是分布式系统中消息队列使用的核心挑战，指业务操作与消息传递的状态保持一致：业务成功时消息必须正确发送并被处理，业务失败时消息不应被发送或需被撤回。本文从消息发送一致性和消息消费一致性两方面，解析问题根源与解决方案。

消息发送一致性：确保业务与消息的原子性

消息发送一致性的核心目标是：业务操作成功 ↔ 消息必须发送成功，避免 “业务成功但消息丢失” 或 “业务失败但消息发送” 的矛盾场景。

消息发送可能出现的问题

（1）业务成功但消息未发送
  • 场景 1：业务逻辑执行完成后，应用在发送消息前宕机（如 JVM 崩溃），导致消息未发送。
  • 场景 2：业务成功后，消息发送时消息中间件宕机（如 Broker 崩溃），消息未被持久化。
（2）业务失败但消息已发送
  • 场景：消息先发送成功，但后续业务逻辑执行失败（如数据库事务回滚），导致无效消息被消费。

解决方案：基于 “消息预存 + 状态确认” 的两阶段方案

用户提到的方案本质是 “预发送消息→执行业务→确认消息可用” 的两阶段模式，确保业务与消息状态同步。具体流程如下：

步骤拆解：
  1. 预存消息：业务应用先向消息中间件发送 “待确认” 消息（状态标记为未处理），消息中间件仅存储消息但不投递。
    • 目的：先确保消息能被中间件持久化，避免后续业务成功后消息发送失败。
  2. 消息中间件反馈存储结果：中间件返回 “消息存储成功 / 失败”。
    • 若失败：业务直接终止（避免业务成功但消息无法存储）。
  3. 执行业务逻辑：仅当消息存储成功后，才执行核心业务（如订单创建、库存扣减）。
  4. 确认消息状态：业务执行完成后，向中间件发送 “业务结果”：
    • 业务成功：中间件将消息状态改为可投递，并向消费者投递。
    • 业务失败：中间件删除预存消息（或标记为废弃），避免无效消息。
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.2k 阅读时长 ≈ 2 分钟

HBase复杂查询解决方案：二级索引与集成搜索引擎

HBase 作为分布式列存储数据库，擅长基于 RowKey 的快速单点查询和范围扫描，但对多条件组合查询、聚合计算（如 GROUP BY、ORDER BY）的支持较弱。本文将详细解析 HBase 复杂查询的痛点，以及通过二级索引和集成搜索引擎实现复杂查询的解决方案。

HBase 复杂查询的痛点

HBase 的查询能力受限于其分布式存储设计，主要痛点包括：

  1. 查询维度单一：仅支持基于 RowKey 的精确查询或前缀范围查询，无法直接通过多列条件过滤（如 WHERE age > 30 AND city = 'Beijing'）。
  2. 缺乏聚合能力：不支持 GROUP BY、COUNT、SUM 等聚合操作，需通过 MapReduce 或 Spark 离线计算，延迟较高。
  3. 无事务支持：多表写入时无法保证原子性，易导致数据不一致（如二级索引表与主表数据不匹配）。

解决方案一：二级索引表

二级索引是 HBase 实现多条件查询的传统方案，核心思路是将查询条件映射为索引表的 RowKey，通过索引表快速定位主表数据。

二级索引表设计原理

  • 主表：存储原始数据，RowKey 为主键（如用户 ID）。
  • 索引表：以 “查询条件组合” 为 RowKey，值存储主表的 RowKey，实现 “条件 → 主表 RowKey” 的映射。

示例：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 1.2k 阅读时长 ≈ 1 分钟

文件上传攻击与防御详解

文件上传功能是许多网站常见的交互设计，但也潜藏着被恶意利用的风险。下面将从攻击原理、常见手段到防御策略进行详细说明，帮助更好地理解和防范这类攻击。

文件上传攻击的原理与危害

文件上传攻击的核心在于绕过服务器的文件校验机制，上传恶意文件（如可执行脚本、木马程序等），并通过该文件获取服务器权限或危害用户。

  • 常见攻击场景：
    • 上传.php、.asp等可执行脚本，通过访问该脚本直接操控服务器（如读取敏感文件、执行系统命令）。
    • 上传伪装成图片的病毒文件（如将.exe改为.jpg），诱导其他用户下载运行，窃取信息或破坏设备。
    • 利用上传功能存储大量无关文件，占用服务器存储空间，导致服务瘫痪。
  • 典型案例：
    某网站仅通过文件后缀判断类型，攻击者将恶意脚本命名为image.jpg.php，若服务器优先识别.php后缀，访问该文件时就会执行脚本，获取数据库权限。

文件上传攻击的防御策略

防御的核心是严格校验上传文件的合法性，并通过多重机制阻断恶意文件的执行和访问。

1. 采用白名单校验文件类型

  • 核心原则：只允许指定的安全文件类型（如.jpg、.png、.pdf）上传，而非禁止黑名单中的类型（黑名单易被绕过，如新型后缀或特殊格式）。
  • 实现方式：
    在服务器端预设允许的 MIME 类型（如image/jpeg、application/pdf）和文件后缀，上传时同时校验这两项，缺一不可。
阅读全文 »