【实战 ES】实战 Elasticsearch：快速上手与深度实践-1.3.1单节点安装（Docker与手动部署）

👉 点击关注不迷路
👉 点击关注不迷路
👉 点击关注不迷路

---

10分钟快速部署Elasticsearch单节点环境

---

1. 系统环境要求

1.1 硬件配置推荐

组件	开发环境	生产环境
CPU	2核	8核+
内存	4GB	32GB+
磁盘	50GB HDD	1TB SSD RAID
网络	1Gbps	10Gbps

1.2 软件依赖

• 可在Windows电脑安装虚拟机，完成环境搭建尝试。

软件	版本要求	备注
OS	Linux内核3.0+	CentOS/Ubuntu等
Java	JDK 17	必须LTS版本
Docker	20.10+	仅容器部署需要
文件系统	ext4/xfs	推荐使用xfs

• Java 版本
  • LTS（Long - Term Support，长期支持）版本是由 Oracle 或其他供应商提供长期维护和更新的 Java 版本。这些版本为企业和开发者提供了稳定性和安全性保障，适合需要长期稳定运行的应用程序。
  • 目前的 Java LTS 版本有 Java 8、Java 11 和 Java 17 等。
    

---

2. Docker部署方案

2.1 部署流程

# 创建数据目录
mkdir -p /data/es/{data,logs}# 拉取官方镜像
docker pull docker.elastic.co/elasticsearch/elasticsearch:8.9.0# 启动容器
docker run -d \--name elasticsearch \-p 9200:9200 \-p 9300:9300 \-e "discovery.type=single-node" \-e "ES_JAVA_OPTS=-Xms2g -Xmx2g" \-v /data/es/data:/usr/share/elasticsearch/data \-v /data/es/logs:/usr/share/elasticsearch/logs \--ulimit nofile=65535:65535 \docker.elastic.co/elasticsearch/elasticsearch:8.9.0

2.2 参数说明

参数	作用说明
discovery.type	指定单节点模式
ES_JAVA_OPTS	JVM堆内存设置（建议1:1）
ulimit nofile	文件描述符限制
9200端口	REST API端口
9300端口	节点通信端口

• es.discovery.type
  • 在 Elasticsearch 中，es.discovery.type 是一个用于配置节点发现机制的重要参数。节点发现机制决定了 Elasticsearch 集群中的节点如何相互找到并组成一个集群。
  • 通过设置不同的 es.discovery.type 值，可以实现不同的发现方式，以适应不同的部署环境和需求。
    

2.3 性能优化建议

# 修改docker-compose.yml配置
services:elasticsearch:deploy:resources:limits:memory: 4genvironment:- bootstrap.memory_lock=true- thread_pool.write.queue_size=1000

---

3. 手动部署方案

3.1 安装步骤

# 下载安装包
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.9.0-linux-x86_64.tar.gz# 解压文件
tar -zxvf elasticsearch-8.9.0-linux-x86_64.tar.gz
cd elasticsearch-8.9.0/# 创建专用用户
useradd elastic -s /bin/bash
chown -R elastic:elastic .# 修改系统配置
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p# 修改配置文件
vi config/elasticsearch.yml

3.2 核心配置项

# 定义 Elasticsearch 集群的名称。
# 同一集群内的所有节点必须使用相同的集群名称，以便它们能够识别并加入到同一个集群中。
# 这里将集群名称设置为 my-es-cluster。
cluster.name: my-es-cluster# 指定当前 Elasticsearch 节点的名称。
# 节点名称在集群中应该是唯一的，方便在管理和监控集群时识别不同的节点。
# 此节点的名称被设置为 node-1。
node.name: node-1# 设置 Elasticsearch 存储数据文件的路径。
# 所有的索引数据、分片数据等都会存储在这个目录下。
# 这里指定为 /var/lib/elasticsearch。
path.data: /var/lib/elasticsearch# 设置 Elasticsearch 存储日志文件的路径。
# 包含了节点的运行日志、错误日志等信息，方便后续的问题排查和监控。
# 这里指定为 /var/log/elasticsearch。
path.logs: /var/log/elasticsearch# 配置 Elasticsearch 节点绑定的网络地址。
# 0.0.0.0 表示节点将监听所有可用的网络接口，允许来自任何网络的连接。
# 可以根据实际需求修改为特定的 IP 地址。
network.host: 0.0.0.0# 设置 Elasticsearch 提供 HTTP 服务的端口号。
# 客户端通过这个端口与 Elasticsearch 进行 HTTP 通信，例如执行索引、查询等操作。
# 这里将端口设置为 9200。
http.port: 9200# 配置节点的发现类型。
# single-node 表示该节点将作为单节点集群运行，不会尝试发现其他节点。
# 适用于开发和测试环境。
discovery.type: single-node# 启用 Elasticsearch 的 X-Pack 安全功能。
# 开启后，会提供身份验证、授权、加密等安全特性，增强集群的安全性。
# 设置为 true 表示启用该功能。
xpack.security.enabled: true

3.3 启动服务

su elastic
bin/elasticsearch -d# 生成密码（首次启动后）
bin/elasticsearch-reset-password -u elastic

---

4. 部署方式对比

对比维度	Docker部署	手动部署
部署速度	<2分钟	5-10分钟
环境隔离	完全隔离	依赖系统环境
升级维护	镜像替换即可	需手动更新文件
资源占用	增加约200MB容器开销	直接使用系统资源
安全性	依赖容器安全策略	可深度定制安全配置
适用场景	快速验证/开发测试	生产环境/深度定制

---

5. 验证安装结果

5.1 基础健康检查

curl -XGET "http://localhost:9200/_cluster/health?pretty"# 预期输出
{"cluster_name" : "my-es-cluster","status" : "green","number_of_nodes" : 1
}

5.2 性能测试

# 使用压测工具
ab -n 1000 -c 10 http://localhost:9200/# 典型性能指标
| QPS       | 平均响应时间 | 错误率 |
|-----------|--------------|--------|
| 850 req/s | 11ms         | 0%     |

• ab 是 Apache HTTP 服务器自带的一个性能测试工具，全称为 ApacheBench。它可以用于对 HTTP 服务器进行压力测试，帮助开发者和运维人员评估服务器在不同负载下的性能表现，比如处理请求的能力、响应时间等。
  • -n 1000：指定要执行的请求总数为 1000 次。也就是说，ab 工具会向目标服务器发送 1000 个 HTTP 请求。
  • -c 10：设置并发请求数为 10。意味着在同一时间内，ab 会同时向服务器发送 10 个请求，以此模拟多个用户同时访问服务器的场景。
• 运行该命令后，ab 会输出一系列测试结果，其中一些重要的指标包括：
  • 吞吐率（Requests per second）：表示服务器每秒能够处理的请求数量，数值越高说明服务器处理请求的能力越强。
  • 平均响应时间（Time per request）：包含了每个请求的平均处理时间，能反映出服务器的响应速度。
  • 传输速率（Transfer rate）：指服务器每秒传输的数据量。
  • 示例输出片段及解释

    Concurrency Level:      10
    Time taken for tests:   1.234 seconds
    Complete requests:      1000
    Failed requests:        0
    Total transferred:      123456 bytes
    HTML transferred:       111111 bytes
    Requests per second:    810.36 [#/sec] (mean)
    Time per request:       12.340 [ms] (mean)
    Time per request:       1.234 [ms] (mean, across all concurrent requests)
    Transfer rate:          98.76 [Kbytes/sec] received
    

    • Concurrency Level：并发请求数，这里是 10。
    • Time taken for tests：完成所有请求测试所花费的总时间，为 1.234 秒。
    • Complete requests：成功完成的请求数量，这里 1000 个请求都成功完成。
    • Failed requests：失败的请求数量，这里为 0。
    • Requests per second：服务器每秒处理的请求数，平均为 810.36 个。
    • Time per request：平均每个请求的处理时间，分别展示了单个请求视角和所有并发请求视角下的时间。

---

6. 常见问题排查

6.1 启动失败问题

错误现象	解决方案
无法绑定端口	检查防火墙/SELinux状态
内存不足	调整JVM堆大小
文件权限错误	递归修改目录属主
虚拟内存不足	修改vm.max_map_count

6.2 性能优化检查表

• 1. JVM堆内存设置为物理内存的50%
• 2. 禁用swap分区
• 3. 数据目录使用SSD存储
• 4. 配置合理的日志滚动策略
• 5. 启用bootstrap.memory_lock
  • bootstrap.memory_lock 是 Elasticsearch 中的一个重要配置项，用于控制 Elasticsearch 节点是否锁定其堆内存，防止堆内存被交换到磁盘的交换空间（swap）中。
    • 在 Elasticsearch 中，堆内存的使用非常关键，尤其是在处理大量数据和复杂查询时。
    • 如果堆内存被交换到磁盘上（即发生了内存交换，swap），会严重影响 Elasticsearch 的性能，因为磁盘 I/O 比内存访问要慢得多。这可能导致查询响应时间变长、吞吐量下降，甚至可能引发节点不稳定或崩溃。

---