小菜鸟

java菜鸟号正在起航

0%

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

hive实现分组拼接功能：替代 MySQL 的 group_concat

在 MySQL 中，group_concat 用于将分组后的多行数据按指定分隔符拼接，而 Hive 中虽无此函数，但可通过 collect_set/collect_list + concat_ws 的组合实现相同功能。本文详细介绍这一替代方案的原理、用法及注意事项。

核心函数解析

实现分组拼接需用到两个核心函数，二者配合可完成 “分组聚合 → 拼接字符串” 的全流程：

collect_set(col) / collect_list(col)

  • 功能：将分组内某列的所有值聚合为一个数组。

  • 区别：

    • collect_set：去重，返回无重复元素的数组；
    • collect_list：不去重，保留所有元素（包括重复值）。

  • 示例：

    若分组后某列值为[‘a’, ‘b’, ‘a’]，则：

    • collect_set(col) 返回 ['a', 'b']；
    • collect_list(col) 返回 ['a', 'b', 'a']。

concat_ws(separator, array)

  • 功能：将数组中的元素按指定分隔符（separator）拼接为字符串。
  • 参数：
    • separator：分隔符（如 ','、'|'）；
    • array：数组（通常为 collect_set 或 collect_list 的输出）。
  • 示例：
    concat_ws(',', ['a', 'b']) 返回 'a,b'。

完整替代方案：分组拼接实现

基本语法

阅读全文 »

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

SYN Flood 攻击：原理、危害与防御机制

SYN Flood 攻击是一种针对 TCP 协议缺陷的经典 DoS（拒绝服务）攻击，通过耗尽服务器的连接资源，导致正常用户无法建立连接。其核心原理利用了 TCP 三次握手的机制漏洞，尤其是服务器对未完成连接的超时处理机制。以下从攻击原理、危害到防御措施展开详细解析。

SYN 超时重试：攻击的 “突破口”

TCP 三次握手过程中，若服务器发送 SYN-ACK 后未收到客户端的 ACK（第三次握手），会触发SYN 超时重试机制，这一机制成为 SYN Flood 攻击的关键目标。

超时重试流程：

  1. 服务器收到客户端的 SYN 请求，回复 SYN-ACK 后进入SYN_RECV状态，同时将该连接放入SYN 队列（半连接队列）。
  2. 若客户端未回复 ACK（如客户端掉线、恶意不回复），服务器会周期性重发 SYN-ACK：
    • 默认重试5 次，间隔时间呈指数递增（1s → 2s → 4s → 8s → 16s）。
    • 第五次重发后，服务器需等待 32s 确认超时，总耗时 63s后才会从 SYN 队列中移除该连接。

风险点：

  • 服务器的 SYN 队列容量有限（默认通常为几百至几千）。
  • 若大量未完成的连接占用 SYN 队列，新的正常连接请求会因队列满而被拒绝，导致服务器 “拒绝服务”。

SYN Flood 攻击：利用漏洞的恶意行为

SYN Flood 攻击正是利用了上述超时重试机制，通过伪造大量虚假的 SYN 请求，耗尽服务器的 SYN 队列资源，使正常连接无法建立。

攻击过程：

  1. 攻击者向目标服务器发送大量伪造源 IP 的 SYN 请求（源 IP 可能不存在或不可达）。
  2. 服务器收到 SYN 后，回复 SYN-ACK，但由于源 IP 虚假，永远收不到 ACK，连接被放入 SYN 队列并等待超时。
  3. 随着虚假连接不断增加，SYN 队列很快被占满，服务器无法处理新的正常 SYN 请求，导致合法用户无法建立 TCP 连接。
阅读全文 »

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

OpenFeign 中 @FeignClient 名称冲突问题：contextId 的解决方案

在使用 OpenFeign 时，若多个@FeignClient接口的name（或value）属性相同，会导致 Spring 容器中 Bean 名称冲突，启动时报错：A bean with that name has already been defined and overriding is disabled。通过contextId属性可解决这一问题，本文将详细解析其原理和用法。

问题根源：Bean 名称生成规则

OpenFeign 在注册@FeignClient接口的配置 Bean 时，会根据特定规则生成 Bean 名称。核心逻辑在FeignClientsRegistrar类中，具体步骤如下：

  1. 获取客户端标识（clientName）
    调用getClientName(Map<String, Object> client)方法生成唯一标识，优先级为：
    contextId > value > name > serviceId
    即：若配置了contextId则优先使用，否则依次 fallback 到value、name、serviceId。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    // FeignClientsRegistrar.getClientName() 核心逻辑
    private String getClientName(Map<String, Object> client) {
        String value = (String) client.get("contextId"); // 优先取contextId
        if (!StringUtils.hasText(value)) {
            value = (String) client.get("value"); // 其次取value
        }
        if (!StringUtils.hasText(value)) {
            value = (String) client.get("name"); // 再取name
        }
        if (!StringUtils.hasText(value)) {
            value = (String) client.get("serviceId"); // 最后取serviceId（已废弃）
        }
        // ... 校验逻辑
        return value;
    }

  2. 注册配置 Bean
    生成的clientName会作为 Bean 名称的前缀，拼接固定后缀FeignClientSpecification，最终注册到 Spring 容器：

阅读全文 »

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

Elasticsearch 6.x 查询优化：提升检索效率的核心策略

Elasticsearch 的查询性能直接影响业务响应速度，尤其在大规模数据场景下，优化查询链路、减少资源消耗至关重要。本文结合 6.x 版本特性，从缓存利用、慢查询诊断、文档模型设计等维度，详解查询优化的实用方案。

高效利用查询缓存：减少重复计算

Elasticsearch 内置多种缓存机制，可自动缓存高频查询结果，避免重复执行相同计算。合理配置缓存策略，能显著降低 CPU 和 IO 开销。

缓存类型及适用场景

Elasticsearch 6.x 主要依赖两种查询缓存：

缓存类型 作用范围 适用场景 缓存策略
Filter 缓存 过滤条件（filter 子句） 频繁执行的固定过滤条件（如状态、时间范围） LRU（最近最少使用）淘汰
请求缓存 聚合结果、count 等无排序查询 高频聚合查询（如仪表盘统计） 基于查询哈希缓存结果

核心配置与优化

（1）启用 Filter 缓存

Filter 缓存默认开启，可通过以下配置调整缓存大小（占堆内存比例）：

1
2
# elasticsearch.yml 中配置
indices.queries.cache.size: 25%  # 默认为10%，可提升至20%-30%（不超过堆内存的50%）
  • 注意：仅 filter 子句会被缓存（query 子句因需计算得分，不缓存），建议优先用 filter 处理固定条件。
（2）启用请求缓存（Request Cache）

请求缓存默认对所有索引开启，缓存无排序的聚合、count 等查询结果：

阅读全文 »

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

分布式环境下的核心挑战与复杂性

分布式系统通过将任务分散到多个节点协同工作，实现了算力、存储和可用性的扩展，但也因节点间的网络交互引入了单机系统不存在的复杂性。以下从底层问题出发，系统梳理分布式环境面临的核心挑战：

通信异常：分布式系统的 “天然短板”

分布式系统的节点间依赖网络通信，而网络本身的不确定性是所有问题的根源：

  • 高延迟：跨节点请求需经过路由转发、协议解析等过程，延迟通常是单机内存操作的数万倍（毫秒级 vs 纳秒级），直接影响系统响应速度。
  • 不稳定性：网络抖动、带宽波动可能导致数据包丢失或乱序，即使是稳定的局域网，也存在瞬时故障的概率。
  • 成本叠加：复杂业务往往需要多节点协同（如微服务调用链），一次用户请求可能涉及数十次跨节点通信，任何一次通信异常都会放大整体失败风险。

网络分区（脑裂）：节点间的 “信息孤岛”

当网络故障导致系统被分割为多个独立子网（即 “网络分区”），各子网内的节点能正常通信，但子网间完全隔离，此时会引发 “脑裂” 问题：

  • 集群管理混乱：若集群存在主节点（如分布式锁的协调者、数据库主库），各分区可能会独立选举新主节点，导致 “多主并存”，数据写入出现冲突。
  • 数据一致性破坏：分区内的节点可能基于 “局部信息” 做出决策（如扣减库存），当网络恢复后，不同分区的操作结果无法合并，导致全局数据不一致。

示例：分布式存储系统中，若网络分区后两个子集群分别写入同一份数据，恢复连接后会面临 “数据版本冲突”，需复杂的合并策略解决。

三态问题：请求结果的 “薛定谔状态”

单机系统中，操作结果非成功即失败；但分布式环境中，由于网络延迟或故障，请求会出现第三种状态 ——超时，且无法判断超时的真实原因：

阅读全文 »