小菜鸟

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

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

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

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

核心配置解析

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

1
2
3
4
5
6
7

"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 策略的补充。

优化配置（性能优先）

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

1
2
3
4
5
6
7
8
9

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 的第一条指令。

• 示例：

  1 2 3 4 5 6

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

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

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

• 示例：

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

在实际开发中，手动点击 “立即构建” 显然不够高效。理想的流程是：当代码推送到 Git 仓库（如 Gitee、GitHub）后，Jenkins 能自动检测变动并触发构建。本文将介绍两种常用的自动构建方案，帮你实现代码提交即自动化构建的闭环。

方案一：定时轮询

这是最简单的自动触发方式，通过定时检查 Git 仓库是否有代码变动，如果检测到新提交则自动执行构建。适合对实时性要求不高、或仓库访问受限的场景。

配置步骤

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

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

3. 在输入框中填写

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

   1	H/5 * * * *

   表示 “每 5 分钟检查一次仓库变动”（H 是随机偏移量，避免所有项目同时触发导致服务器压力集中）。这里的配置是指五分钟轮询检测一下git仓库是否有变动，如果这段时间有提交的话，会自动进行构建，如果该时间段内没有新的提交，则不会进行构建

   

定时表达式规则

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

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

集群节点角色与架构

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

集群核心特性

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

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

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