👉 點擊關注不迷路
👉 點擊關注不迷路
👉 點擊關注不迷路

---

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 比內存訪問要慢得多。這可能導致查詢響應時間變長、吞吐量下降，甚至可能引發節點不穩定或崩潰。

---