小菜鸟

java菜鸟号正在起航

0%

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

Elasticsearch 字段类型详解：从基础到高级应用

Elasticsearch 提供了丰富的字段类型，每种类型对应特定的数据结构和使用场景，直接影响索引效率、查询性能和功能支持。以下是 6.8.x 版本中常用字段类型的详细解析，包括适用场景、特性及配置示例。

字符串类型：text 与 keyword

字符串是最常用的字段类型，Elasticsearch 将其细分为 text（全文本） 和 keyword（关键字），以满足不同的检索需求。

text（全文本类型）

  • 特性：

    • 会被分词器处理（拆分为词项），支持全文检索（如 “苹果手机” 可拆分为 “苹果”“手机”，匹配包含任一词项的文档）。
    • 不适合排序、聚合（分词后的值分散，无法高效分组）。

  • 适用场景：需要全文搜索的长文本，如商品描述、文章正文、评论内容等。

  • 配置示例：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    {
      "mappings": {
        "default": {
          "properties": {
            "product_description": { "type": "text" }  // 全文搜索商品描述
          }
        }
      }
    }

keyword（关键字类型）

  • 特性：

    • 不分词，将整个字符串作为一个词项（如 “苹果手机” 会被视为单个词项，仅精确匹配时命中）。
    • 适合过滤（term 查询）、排序（sort）、聚合（terms 分组）。

  • 适用场景：结构化字符串，如标签、状态、ID、分类等。

  • 配置示例：

阅读全文 »

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

Docker for Mac 桌面无法打开的解决方案

当 Docker for Mac 桌面应用无法启动，同时出现Cannot connect to the Docker daemon错误时，通常与 Docker 进程异常占用或状态错乱有关。以下是针对该问题的详细解决步骤：

问题现象总结

  • 点击 Docker 桌面图标无反应，无法启动图形界面；
  • 终端执行docker -v显示版本正常，但docker images等命令提示：
    Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?；
  • 检查/var/run目录，未找到docker.sock文件（Docker 守护进程通信的套接字文件）。

核心原因分析

问题根源通常是Docker 相关进程异常残留，导致新的 Docker 守护进程无法启动：

  • 电脑非正常重启（如强制关机、断电）可能导致 Docker 进程未正常退出；
  • 残留进程占用了 Docker 所需的端口或资源，阻止新进程启动。

解决步骤

1. 检查 Docker 相关进程

终端执行以下命令，查看是否有残留的 Docker 进程：

阅读全文 »

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

Integer 拆装箱与缓存机制：为什么 2 == 2 而 200 != 200？

在 Java 中，Integer 作为 int 的包装类，其拆装箱（Autoboxing/Unboxing）机制和缓存策略常常导致看似矛盾的结果，比如两个值相等的 Integer 对象用 == 比较时，有时为 true，有时为 false。本文将深入解析这一现象背后的原理。

自动拆装箱的基本概念

自动装箱（Autoboxing）：将基本数据类型（如 int）自动转换为对应的包装类（如 Integer）。
自动拆箱（Unboxing）：将包装类（如 Integer）自动转换为对应的基本数据类型（如 int）。

示例：

1
2
3
4
5
// 自动装箱：int → Integer
Integer a = 2; // 等价于 Integer a = Integer.valueOf(2);

// 自动拆箱：Integer → int
int b = a; // 等价于 int b = a.intValue();

正是自动装箱机制，使得 Integer a = 2 这种语法成立，而其内部依赖 Integer.valueOf(int) 方法实现。

Integer 缓存机制（IntegerCache）

Integer 的缓存机制是导致 2 == 2 而 200 != 200 的核心原因。Java 为了优化性能，对 -128 到 127 之间的整数 进行了缓存，避免频繁创建相同值的 Integer 对象。

1. Integer.valueOf(int) 方法的实现

Integer.valueOf(int) 是自动装箱的核心方法，其源码逻辑如下：

阅读全文 »

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

Elasticsearch 索引健康状态为 Red 的排查与解决方案

当 Elasticsearch 索引健康状态显示为 red 时，表示至少有一个主分片未分配（无法使用），这会导致部分或全部数据不可访问。本文以实际案例讲解如何定位 red 状态的根源（如磁盘空间不足、分片分配失败等），并提供针对性解决方案。

Red 状态的核心原因

Elasticsearch 集群健康状态分为三级：

  • green：所有主分片和副本分片均正常分配。
  • yellow：所有主分片正常分配，但至少有一个副本分片未分配。
  • red：至少有一个主分片未分配（数据不可用）。

red 状态的常见触发因素：

  • 主分片所在节点宕机且无副本可用。
  • 分片分配失败（如磁盘空间不足、权限问题、配置冲突）。
  • 索引损坏或数据文件丢失。
  • 节点资源不足（内存、CPU 超限）。

排查步骤：从整体到细节

查看集群与索引健康状态

首先通过 _cluster/health 确认问题范围（是单个索引还是整个集群）：

1
2
# 查看集群健康，包含索引级别的状态
GET _cluster/health?level=indices

响应示例（某索引为 red）：

索引层级健康状态

关键：锁定状态为 red 的索引（如 problem_index）。

检查分片状态与未分配原因

通过 _cat/shards 查看具体分片的状态及未分配原因：

1
2
# 筛选关键信息：索引名、分片号、主/副本、状态、未分配原因
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason&v

输出示例：

分片情况

  • prirep=p 表示主分片，r 表示副本分片。
  • unassigned.reason=ALLOCATION_FAILED 说明主分片分配失败，导致副本也无法分配。

深入分析分配失败原因

使用 _cluster/allocation/explain 查看分片分配失败的详细日志：

1
GET _cluster/allocation/explain

响应示例（磁盘空间不足）：

分配失败原因

关键原因：节点磁盘使用率达 90%，超过 Elasticsearch 默认的高水位阈值（85%），导致分片无法分配。

验证资源状态

针对上述磁盘空间问题，通过 _cat/allocation 确认节点磁盘使用情况：

1
GET _cat/allocation?v

输出示例：

1
2
3
shards disk.used disk.avail disk.total disk.percent host      ip        node
     5      18gb      200mb      20gb          99 192.168.1.1 node-1
     3      10gb       10gb      20gb          50 192.168.1.2 node-2

可见 node-1 磁盘仅剩 200MB，使用率达 99%，触发分配限制。

解决方案：针对性修复

1. 磁盘空间不足（最常见）

解决步骤：

  • 清理空间：删除节点上的非必要文件（如日志、旧快照），释放至少 10% 以上的磁盘空间。

  • 临时调整阈值（紧急情况）：

    1
    2
    3
    4
    5
    6
    7
    8
    # 临时降低高水位阈值（重启后失效）
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.disk.watermark.high": "95%",  # 高水位设为95%
        "cluster.routing.allocation.disk.watermark.flood_stage": "97%"  # 洪水阶段设为97%
      }
    }

  • 长期优化：扩容磁盘，或配置索引生命周期管理（ILM）自动删除过期数据。

验证：空间释放后，Elasticsearch 会自动重试分配分片，可通过 GET _cat/shards 确认状态变为 STARTED。

2. 其他常见问题的解决

（1）分片分配被人为禁用

若通过 cluster.routing.allocation.enable 禁用了分配，需重新开启：

1
2
3
4
5
6
PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "all"  # 允许所有分片分配
  }
}
（2）节点资源不足（内存 / CPU 超限）
  • 检查节点资源：GET _nodes/stats（查看 jvm.mem、process.cpu）。
  • 解决：重启节点释放资源，或扩容节点配置。
（3）索引数据损坏

  • 尝试恢复快照：若有快照，通过 _snapshot API 恢复索引。

  • 重建索引：若数据可重新同步，删除损坏索引后重新写入数据：

    1
    DELETE problem_index  # 谨慎操作！确保数据可恢复
（4）节点间版本不兼容
  • 确认所有节点版本一致（主分片无法分配到版本更低的节点）。
  • 解决：升级节点至统一版本。

预防措施：避免 Red 状态再次发生

  1. 监控磁盘空间：通过 Elasticsearch Monitor 或第三方工具（如 Prometheus + Grafana）监控磁盘使用率，设置阈值告警（如超过 80% 告警）。

  2. 合理配置副本：为每个主分片配置至少 1 个副本（number_of_replicas: 1），避免单点故障导致主分片丢失。

  3. 禁用自动创建索引：防止误写入导致大量小索引占用资源：

    1
    2
    3
    4
    5
    6
    PUT _cluster/settings
    {
      "persistent": {
        "action.auto_create_index": ".monitoring*,*"  # 仅允许特定索引自动创建
      }
    }

  4. 定期备份：通过快照机制定期备份索引，确保数据可恢复。

  5. 配置分片分配重试：自动重试临时分配失败的分片：

    1
    2
    3
    4
    5
    6
    7
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.node_concurrent_recoveries": 5,  # 并发恢复数
        "indices.recovery.max_bytes_per_sec": "100mb"  # 恢复速度
      }
    }

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

Elasticsearch 6.8.x 基本操作全解析

Elasticsearch 提供了丰富的 RESTful API 用于数据的增删改查及集群管理。以下基于 6.8.x 版本（支持 Type），详细介绍核心操作的语法、示例及注意事项。

统计操作：集群文档数量

通过 _count API 统计集群中匹配查询条件的文档总数（默认统计所有文档）。

语法

1
2
3
4
GET _count?pretty
{
  "query": { "match_all": {} }  // match_all 表示匹配所有文档
}

响应示例

1
2
3
4
5
6
7
8
9
{
  "count": 5091327,  // 匹配的文档总数
  "_shards": {
    "total": 10,     // 参与统计的分片总数
    "successful": 10, // 成功统计的分片数
    "skipped": 0,
    "failed": 0
  }
}

添加数据

通过 PUT 请求向指定索引、类型添加文档，支持自动创建索引（根据字段推断映射）。

基本添加（自动创建索引）

阅读全文 »