👉 点击关注不迷路 👉 点击关注不迷路 👉 点击关注不迷路
文章大纲 10分钟快速部署`Elasticsearch`单节点环境 1. 系统环境要求 2. `Docker`部署方案 2.1 部署流程 2.2 参数说明 2.3 性能优化建议 3. 手动部署方案 3.1 安装步骤 3.2 核心配置项 3.3 启动服务 4. 部署方式对比 5. 验证安装结果 6. 常见问题排查
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 性能优化建议
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 核心配置项
cluster.name : my- es- cluster
node.name : node- 1
path.data : /var/lib/elasticsearch
path.logs : /var/log/elasticsearch
network.host : 0.0.0.0
http.port : 9200
discovery.type : single- node
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 [
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 性能优化检查表
JVM
堆内存设置为物理内存的50%
禁用swap
分区 数据目录使用SSD
存储 配置合理的日志滚动策略 启用bootstrap.memory_lock
bootstrap.memory_lock
是 Elasticsearch
中的一个重要配置项,用于控制 Elasticsearch 节点是否锁定其堆内存,防止堆内存被交换到磁盘的交换空间(swap
)中。 在 Elasticsearch 中,堆内存的使用非常关键,尤其是在处理大量数据和复杂查询时。 如果堆内存被交换到磁盘上(即发生了内存交换,swap
),会严重影响 Elasticsearch 的性能,因为磁盘 I/O 比内存访问要慢得多
。这可能导致查询响应时间变长、吞吐量下降,甚至可能引发节点不稳定或崩溃
。