小菜鸟

Elasticsearch 6.x 写入性能优化：从配置到实践

Elasticsearch 6.x 的写入性能直接影响数据采集和处理效率，尤其在日志、监控等高频写入场景中至关重要。通过优化 Translog 策略、批量写入、分段刷新等核心配置，可显著提升写入吞吐量。本文结合 6.x 版本特性，详解写入优化的关键手段。

Translog 配置优化：平衡安全性与性能

Translog（事务日志）是 Elasticsearch 保障数据安全的核心组件，但默认配置为了安全性牺牲了部分性能。通过调整 Translog 策略，可在可接受的数据风险范围内提升写入速度。

核心配置解析

默认 Translog 配置（安全性优先）：

"index": {
  "translog": {
    "durability": "REQUEST",  // 每次请求后立即刷写Translog到磁盘
    "sync_interval": "5s",    // 即使未触发REQUEST，也每5s刷写一次
    "flush_threshold_size": "512mb"  // Translog达512MB时触发Flush
  }
}

• durability: "REQUEST"：每个写入请求都会同步刷写 Translog 到磁盘，确保数据不丢失，但频繁 IO 会降低性能。
• sync_interval：定期刷写未同步的 Translog（默认 5s），作为 REQUEST 策略的补充。

优化配置（性能优先）

对于实时性要求不高、可接受少量数据丢失风险的场景（如日志采集），可调整为异步刷写：

PUT _index_template/optimized_template
{
  "index_patterns": ["logs-*", "metrics-*"],  // 对指定索引生效
  "settings": {
    "index.translog.durability": "async",    // 异步刷写Translog
    "index.translog.sync_interval": "60s",   // 每60s批量刷写一次
    "index.translog.flush_threshold_size": "1gb"  // 扩大触发Flush的阈值
  }
}

VMware 网络模式：桥接、Host-only 与 NAT 的区别与应用

VMware 虚拟机提供了多种网络模式，用于控制虚拟机与宿主机、其他虚拟机及外部网络的通信方式。理解不同模式的原理和适用场景，能帮助高效配置虚拟机网络环境。

桥接模式（Bridged）

核心原理

桥接模式相当于为虚拟机分配一个独立的网络身份，与宿主机 “平起平坐”，共享宿主机的物理网卡接入网络。虚拟机就像局域网中一台独立的物理机，拥有与宿主机同网段的 IP 地址。

网络特征

• IP 配置：需手动设置与宿主机同网段的 IP（或通过 DHCP 获取局域网内的独立 IP）。
• 通信范围：
  • 虚拟机 ←→ 宿主机：可直接通信。
  • 虚拟机 ←→ 局域网内其他设备（物理机 / 虚拟机）：可直接通信。
  • 虚拟机 ←→ 外网：可直接访问（与宿主机上网方式一致）。
• 网卡使用：直接使用宿主机的物理网卡（如 WiFi、有线网卡）。

Dockerfile 详解：镜像构建的 “说明书”

Dockerfile 是一个文本文件，包含一系列构建镜像的指令，通过 docker build 命令可自动执行这些指令生成自定义镜像。它就像镜像的 “施工蓝图”，明确了从基础镜像到最终镜像的每一步操作，实现了镜像构建的自动化和可复用性。

Dockerfile 基本结构

Dockerfile 由指令（Instruction） 和注释组成，指令格式为：
INSTRUCTION arguments（指令大写，参数小写，惯例）。

核心指令包括：FROM、RUN、CMD、COPY、ADD 等，下文将详细解析。

核心指令详解

1. FROM：指定基础镜像

• 作用：声明构建镜像的基础镜像（所有镜像都需基于某个基础镜像构建）。

• 位置：必须是 Dockerfile 的第一条指令。

• 示例：

  # 使用官方centos镜像的latest版本作为基础
  FROM centos:latest
  
  # 使用多阶段构建时，可多次使用FROM（如构建阶段和运行阶段）
  FROM maven:3.8 AS builder  # 构建阶段
  FROM openjdk:8-jre         # 运行阶段

2. MAINTAINER：指定镜像作者（已过时，推荐用 LABEL）

• 作用：标注镜像的作者信息（姓名、邮箱等）。

• 示例：

jenkins自动构建配置：代码提交后自动触发构建的两种方案

不想每次提交代码都去点”立即构建”？这篇教你两种自动触发方式

之前我们聊了怎么安装 Jenkins、怎么配置工具链，但有一个很现实的问题：每次提交完代码都要手动去点一下构建，真的很烦。

尤其是一天提交几十次的时候，点都点烦了。这篇专门讲一下怎么让 Jenkins 自动检测代码变动并触发构建。我自己的经历是：先用了轮询，后来嫌慢改成了 WebHook。

方案一：定时轮询

这个方法很”笨”，但配置起来确实省事——就是让 Jenkins 每隔几分钟去 Git 仓库看一眼：有新的提交就拉下来构建，没有就拉倒。

配置步骤

1. 进入你的 Jenkins 项目配置页面（点击项目名称 → 左侧「Configure」）。

2. 滚动到「Build Triggers」（构建触发器）部分，勾选「Poll SCM」。

3. 在输入框中填写

   定时表达式，定义轮询频率。例如：

   H/5 * * * *

   这个表达式的意思是”每 5 分钟检查一次”。那个 H 是 Jenkins 自己加的一个随机偏移量，防止所有项目都在同一秒去轮询，把服务器搞崩。

定时表达式规则

ZooKeeper 集群结构与 Zab 协议：分布式一致性的基石

ZooKeeper 作为分布式协调服务，其高可用性和强一致性依赖于精巧的集群架构和 Zab 协议。集群通过 Leader-Follower 角色分工实现负载均衡与容错，而 Zab 协议则保证了数据在分布式节点间的一致性同步。以下深入解析集群结构、Zab 协议的工作原理及核心流程。

集群节点角色与架构

ZooKeeper 集群采用主从架构，节点分为三种角色，各司其职以保证集群稳定运行：

集群核心特性

• 过半存活原则：集群只要有超过半数的节点存活（如 3 节点集群至少 2 个存活），即可正常提供服务，保证分区容错性。
• 数据一致性：所有节点在内存中维护相同的数据集，Leader 通过 Zab 协议将写操作同步到 Follower/Observer，确保全局数据一致。

Zab 协议：分布式一致性的核心协议

Zab（ZooKeeper Atomic Broadcast）协议是 ZooKeeper 实现分布式一致性的底层协议，其核心目标是：在分布式环境下，保证事务操作的原子性和顺序性，最终使所有节点的数据达成一致。