当前位置： 首页 > news >正文

从 ZooKeeper 到 ELK：分布式中间件与日志分析系统全解析

news 2025/9/25 13:31:34

前言

在分布式系统架构中，协调服务与日志分析是保障系统稳定运行的两大核心。ZooKeeper 作为分布式协调利器，解决了节点一致性与集群管理难题；Kafka 则凭借高吞吐特性成为消息队列的优选；而 ELK Stack（Elasticsearch、Logstash、Kibana）则构建了完整的日志收集、存储与可视化体系。本文将结合实战部署，带您全面掌握这些工具的核心原理与应用方法。

一、ZooKeeper：分布式系统的 “协调者”

ZooKeeper 是专为分布式应用设计的协调服务，通过文件系统与通知机制的结合，实现数据一致性、节点管理等关键功能，是 Kafka 等组件的重要依赖。

1.1 核心原理与数据结构

ZooKeeper 的设计遵循观察者模式，核心可概括为 “文件系统 + 通知机制”：

  • 数据结构：采用类似 Linux 的树状结构，每个节点称为 ZNode，默认存储 1MB 数据，通过路径唯一标识（如/servers/server1）。
  • ZNode 类型：
    • 持久节点：手动删除前一直存在，适合存储配置信息。
    • 临时节点：客户端会话断开后自动删除，常用于实现分布式锁。
    • 顺序节点：创建时自动添加递增编号，适用于分布式队列。

1.2 关键应用场景

ZooKeeper 的核心价值在于解决分布式环境下的协同问题，主要场景包括：

  • 统一配置管理：将集群配置写入 ZNode，客户端监听节点变化，实现配置实时同步（如 Kafka 集群配置）。
  • 服务器动态上下线：服务器启动时注册临时节点，客户端监听节点列表，实时感知服务状态。
  • 软负载均衡：记录各服务器访问量，将新请求分配给访问量最少的节点。
  • 统一集群管理：监控节点状态变化，根据节点健康度调整集群负载。

1.3 选举机制：保障集群高可用

ZooKeeper 通过 Leader 选举确保集群一致性，分为首次启动与非首次启动两种场景：

  • 首次启动选举（以 5 台服务器为例）：
    1. 服务器 1、2 启动后，因票数未达半数（3 票），保持 LOOKING 状态。
    2. 服务器 3 启动，获 3 票（超过半数），当选 Leader，1、2 转为 FOLLOWING。
    3. 后续服务器 4、5 启动后，直接同步 Leader 信息，无需重新选举。
  • 非首次启动选举：当 Leader 故障时，按以下优先级选举新 Leader：
    1. Epoch（任期代号）大的优先。
    2. Epoch 相同时，事务 ID（ZXID）大的优先。
    3. ZXID 相同时，服务器 ID（myid）大的优先。

1.4 集群部署实战（3 节点）

环境准备
节点名称IP 地址部署组件
zk01192.168.10.18Zookeeper 3.5.7、JDK 1.8
zk02192.168.10.21Zookeeper 3.5.7、JDK 1.8
zk03192.168.10.22Zookeeper 3.5.7、JDK 1.8
部署步骤
  1. 关闭防火墙与安装 JDK
    systemctl stop firewalld && systemctl disable firewalld
setenforce 0
yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel
  2. 下载并解压 ZooKeeper
    wget https://archive.apache.org/dist/zookeeper/zookeeper-3.5.7/apache-zookeeper-3.5.7-bin.tar.gz
tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz -C /usr/local/
mv /usr/local/apache-zookeeper-3.5.7-bin /usr/local/zookeeper-3.5.7
  3. 修改配置文件zoo.cfg
    cd /usr/local/zookeeper-3.5.7/conf/
cp zoo_sample.cfg zoo.cfg
vim zoo.cfg
# 核心配置
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/zookeeper-3.5.7/data
dataLogDir=/usr/local/zookeeper-3.5.7/logs
clientPort=2181
# 集群节点配置（server.A=B:C:D，A为myid，B为IP，C为同步端口，D为选举端口）
server.1=192.168.10.18:3188:3288
server.2=192.168.10.21:3188:3288
server.3=192.168.10.22:3188:3288
  4. 配置 myid 与启动脚本
    • 在每个节点的dataDir目录下创建 myid 文件，分别写入 1、2、3。
    • 编写启动脚本/etc/init.d/zookeeper，设置开机自启：
      chmod +x /etc/init.d/zookeeper
chkconfig --add zookeeper
service zookeeper start
# 查看状态
service zookeeper status

二、Kafka：高吞吐的分布式消息队列

Kafka 是基于发布 / 订阅模式的分布式消息队列，依托 ZooKeeper 实现集群协调，适用于大数据实时处理场景，如日志收集、流式计算等。

2.1 为什么需要消息队列（MQ）

在高并发场景下，消息队列通过异步处理解决系统瓶颈，核心价值包括：

  • 解耦：独立扩展生产端与消费端，只需遵守接口协议。
  • 流量削峰：应对突发请求，避免数据库等组件因过载崩溃。
  • 异步通信：无需等待处理结果，提升用户体验（如订单提交后异步发送通知）。
  • 可恢复性：消息持久化存储，服务故障后可重新消费。

2.2 核心架构与组件

Kafka 集群由以下关键组件构成，各组件协同实现高吞吐与高可用：

组件功能描述
Broker单台 Kafka 服务器，存储 Topic 数据，一个集群包含多个 Broker。
Topic消息分类标识，类似数据库表，生产者向 Topic 写入消息，消费者从 Topic 读取。
PartitionTopic 的物理分区，每个 Partition 是有序队列，支持并行读写，提升吞吐量。
ReplicaPartition 的副本，包含 1 个 Leader 和多个 Follower，Leader 负责读写，Follower 同步数据。
Producer消息生产者，将消息推送到 Topic，可指定 Partition 或通过 Key 哈希分配。
Consumer消息消费者，从 Topic 拉取消息，支持多消费者协同消费。
Consumer Group消费者组，组内消费者分工消费不同 Partition，避免重复消费；组间互不影响。
Offset消息偏移量，记录消费者消费位置，支持重复消费与断点续传，默认保留 7 天。

2.3 数据可靠性与一致性保障

Kafka 通过多重机制确保数据不丢失、不重复：

  • ACK 应答机制：生产者可通过request.required.acks设置可靠性级别：
    • 0：无需等待确认，效率最高，可能丢失数据。
    • 1（默认）：Leader 确认接收即可，Follower 同步前 Leader 故障会丢失数据。
    • -1（all）：所有 Follower 确认接收，可靠性最高，可能因网络延迟导致重复。
  • ISR 机制：Leader 维护同步中的 Follower 列表（ISR），仅当 ISR 中的 Follower 确认后才返回 ACK，确保数据一致性。
  • 幂等性：0.11 版本后支持生产者幂等性，避免重复发送消息。

2.4 集群部署与命令行操作

部署步骤（基于 ZooKeeper 集群）
  1. 下载并解压 Kafka
    wget https://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.7.1/kafka_2.13-2.7.1.tgz
tar -zxvf kafka_2.13-2.7.1.tgz -C /usr/local/
mv /usr/local/kafka_2.13-2.7.1 /usr/local/kafka
  2. 修改配置文件server.properties
    cd /usr/local/kafka/config/
vim server.properties
# 核心配置（每个节点的broker.id需唯一）
broker.id=0
listeners=PLAINTEXT://192.168.10.18:9092
log.dirs=/usr/local/kafka/logs
zookeeper.connect=192.168.10.18:2181,192.168.10.21:2181,192.168.10.22:2181
  3. 启动 Kafka 与验证
    # 编写启动脚本并设置开机自启（类似ZooKeeper）
service kafka start
# 创建Topic（3分区，2副本）
kafka-topics.sh --create --zookeeper 192.168.10.18:2181 --replication-factor 2 --partitions 3 --topic test
# 查看Topic列表
kafka-topics.sh --list --zookeeper 192.168.10.18:2181
# 发送消息
kafka-console-producer.sh --broker-list 192.168.10.18:9092 --topic test
# 消费消息
kafka-console-consumer.sh --bootstrap-server 192.168.10.18:9092 --topic test --from-beginning

三、ELK Stack：企业级日志分析解决方案

ELK Stack 由 Elasticsearch（存储与搜索）、Logstash（数据收集与处理）、Kibana（可视化）组成，构建了从日志采集到分析的完整链路，广泛应用于系统监控、故障排查等场景。

3.1 组件分工与工作原理

ELK 各组件各司其职，协同完成日志处理：

  • Elasticsearch：基于 Lucene 的分布式搜索引擎，负责存储日志数据，支持实时检索与聚合分析，通过分片与副本实现高可用。
  • Logstash：数据处理管道，支持从文件、Kafka 等多种来源收集日志，通过过滤器（如正则解析、字段转换）清洗数据，最终输出到 Elasticsearch。
  • Kibana：可视化工具，提供仪表盘、图表等功能，支持通过 Web 界面查询、分析 Elasticsearch 中的日志数据。

3.2 核心组件详解

Elasticsearch：日志存储与检索核心
  • 核心概念：
    • 集群（Cluster）：多个节点组成，共享数据与负载。
    • 索引（Index）：类似数据库表，存储同类日志（如apache_access-2024.05.20）。
    • 文档（Document）：日志的最小单元，以 JSON 格式存储。
    • 分片（Shard）：索引的分区，支持并行处理，提升性能。
    • 副本（Replica）：分片的备份，防止数据丢失。
  • 特点：高性能（秒级检索）、易扩展、支持 RESTful API。
Logstash：日志收集与处理引擎

Logstash 通过 “输入 - 过滤 - 输出”（Input-Filter-Output）流程处理数据：

  • Input：支持文件、Kafka、Beats 等来源（如收集 Apache 访问日志/var/log/httpd/access.log）。
  • Filter：常用插件包括grok（正则解析日志）、date（时间格式转换）、mutate（字段修改）。
  • Output：默认输出到 Elasticsearch，也可输出到文件、Kafka 等。
Kibana：日志可视化与监控

Kibana 的核心功能包括：

  • Discover：实时搜索与过滤日志，支持按字段筛选（如按 IP 查询访问记录）。
  • Visualizations：生成折线图、饼图、柱状图等，展示日志趋势（如每小时访问量）。
  • Dashboards：聚合多个可视化图表，构建监控面板（如系统健康度仪表盘）。
  • Alerts：设置阈值报警（如错误日志数超过 100 时触发通知）。

3.3 部署实战：Filebeat+Kafka+ELK 架构

为应对高并发场景，引入 Filebeat（轻量级日志采集器）与 Kafka，构建更稳定的日志链路：

环境准备
节点名称IP 地址部署组件
Node1192.168.10.13Elasticsearch、Kibana
Node2192.168.10.14Elasticsearch
Apache 节点192.168.10.15Logstash、Apache
Filebeat 节点192.168.10.16Filebeat
Kafka 集群192.168.10.18/21/22Kafka、ZooKeeper
关键部署步骤
  1. Filebeat 配置（采集 Apache 日志）
    # /usr/local/filebeat/filebeat.yml
filebeat.prospectors:
- type: logenabled: truepaths:- /var/log/httpd/access_logtags: ["access"]
- type: logenabled: truepaths:- /var/log/httpd/error_logtags: ["error"]
output.kafka:enabled: truehosts: ["192.168.10.18:9092","192.168.10.21:9092","192.168.10.22:9092"]topic: "httpd"
  2. Logstash 配置（从 Kafka 读取并输出到 ES）
    # /etc/logstash/conf.d/kafka.conf
input {kafka {bootstrap_servers => "192.168.10.18:9092,192.168.10.21:9092,192.168.10.22:9092"topics => "httpd"codec => "json"}
}
output {if "access" in [tags] {elasticsearch {hosts => ["192.168.10.13:9200"]index => "httpd_access-%{+YYYY.MM.dd}"}}if "error" in [tags] {elasticsearch {hosts => ["192.168.10.13:9200"]index => "httpd_error-%{+YYYY.MM.dd}"}}
}
  3. Kibana 可视化配置
    • 访问http://192.168.10.13:5601，创建索引模式（如httpd_access-*）。
    • 在 “Discover” 中查看日志详情，在 “Visualizations” 中创建访问量趋势图，最终聚合为仪表盘。

四、总结与实践建议

ZooKeeper、Kafka 与 ELK Stack 共同构成了分布式系统的 “基础设施层”：ZooKeeper 保障协调一致性，Kafka 实现高吞吐消息传递，ELK 则解决日志分析难题。在实际应用中，需注意以下几点：

  1. 集群规模：ZooKeeper 建议 3-5 节点，Kafka 与 Elasticsearch 根据数据量扩展 Broker / 节点数量。
  2. 性能优化：Kafka 调整分区数与副本数平衡吞吐量与可靠性；Elasticsearch 合理设置分片数（建议每分片 20-40GB）。
  3. 数据安全：配置 ELK 访问控制（如 Kibana 角色权限），定期清理过期日志（Kafka 日志保留期、ES 索引生命周期管理）。

通过本文的理论解析与实战部署，您已掌握分布式协调与日志分析的核心能力。后续可结合具体业务场景，进一步探索流式计算（如 Flink+Kafka）、监控告警等高级应用，构建更强大的分布式系统。

ZooKeeper+Kafka+ELK 部署故障排查手册

本手册基于zookeeper+kafka.pdf与ELK企业级日志分析系统-教案.pdf中的部署流程，梳理三大组件部署阶段的高频故障、根因及解决方案，聚焦手册提及的版本（ZooKeeper 3.5.7、Kafka 2.7.1、ELK 6.6.1）与部署步骤，不涉及其他版本或无关场景。

一、ZooKeeper 集群部署故障

1.1 故障 1：启动后状态为 “LOOKING”，无法选举 Leader

现象

执行service zookeeper status，所有节点均显示 “LOOKING”（选举中），无节点成为 “LEADING”，集群无法提供服务。

根因（基于手册部署步骤）
  1. zoo.cfg中server.A=B:C:D配置错误：IP（B）写错、同步端口（C）或选举端口（D）被占用。
  2. 各节点dataDir目录下的myid文件缺失或内容与server.A的 “A” 不匹配（如节点 1 的myid应为 1，却写为 2）。
  3. 防火墙未关闭，导致节点间端口（2181、3188、3288）无法通信（手册要求systemctl stop firewalld）。
解决方案
  1. 检查zoo.cfg集群配置：
    # 查看配置，确保IP、端口与节点对应
cat /usr/local/zookeeper-3.5.7/conf/zoo.cfg | grep "server"
# 示例正确配置（3节点）
server.1=192.168.10.18:3188:3288
server.2=192.168.10.21:3188:3288
server.3=192.168.10.22:3188:3288
  2. 验证myid文件：
    # 节点1执行（其他节点对应修改为2、3）
cat /usr/local/zookeeper-3.5.7/data/myid
# 若错误，重新写入：echo 1 > /usr/local/zookeeper-3.5.7/data/myid
  3. 确认端口通信：
    # 节点1测试与节点2的3188端口连通性
telnet 192.168.10.21 3188
# 若不通，关闭防火墙并重启ZooKeeper
systemctl stop firewalld && systemctl disable firewalld
service zookeeper restart

1.2 故障 2：启动脚本执行报错 “zkServer.sh: command not found”

现象

执行service zookeeper start时，提示脚本中zkServer.sh路径错误，无法启动服务。

根因

手册中/etc/init.d/zookeeper脚本的ZK_HOME路径与实际 ZooKeeper 安装路径不匹配（如手册写/usr/local/zookeeper-3.5.7，实际解压到/opt/zookeeper）。

解决方案
  1. 修正启动脚本路径：
    vim /etc/init.d/zookeeper
# 将ZK_HOME改为实际路径，示例：
ZK_HOME='/usr/local/zookeeper-3.5.7'  # 与手册一致，确保路径存在
  2. 赋予脚本权限并重启：
    chmod +x /etc/init.d/zookeeper
service zookeeper start

二、Kafka 集群部署故障

2.1 故障 1：启动后无法连接 ZooKeeper，日志报 “Connection refused”

现象

查看 Kafka 日志（/usr/local/kafka/logs/server.log），频繁出现 “Could not connect to ZooKeeper server”，Kafka 服务启动失败。

根因
  1. ZooKeeper 集群未启动或状态异常（部分节点未正常运行）。
  2. server.properties中zookeeper.connect配置的 IP / 端口错误，或与 ZooKeeper 的zoo.cfg不一致。
  3. Kafka 节点与 ZooKeeper 节点间网络不通（2181 端口被拦截）。
解决方案
  1. 先验证 ZooKeeper 集群状态：
    # 任意ZooKeeper节点执行，确保有Leader节点
service zookeeper status
# 或通过客户端连接测试
/usr/local/zookeeper-3.5.7/bin/zkCli.sh -server 192.168.10.18:2181
  2. 检查 Kafka 的 ZooKeeper 配置：
    vim /usr/local/kafka/config/server.properties
# 确保与ZooKeeper集群IP一致
zookeeper.connect=192.168.10.18:2181,192.168.10.21:2181,192.168.10.22:2181
  3. 测试网络连通性：
    # Kafka节点测试ZooKeeper 2181端口
ping 192.168.10.18 && telnet 192.168.10.18 2181

2.2 故障 2：创建 Topic 时报 “Replication factor larger than available brokers”

现象

执行kafka-topics.sh --create时，报错 “Replication factor 2 larger than available brokers 1”，无法创建 Topic。

根因
  1. Kafka 集群未完全启动，仅启动 1 个 Broker，而创建 Topic 时指定的--replication-factor（副本数）大于可用 Broker 数量（手册示例用 2 副本，需至少 2 个 Broker）。
  2. server.properties中broker.id重复（多节点用相同broker.id，导致集群识别为 1 个 Broker）。
解决方案
  1. 确认所有 Kafka 节点已启动：
    # 各Kafka节点执行，确保进程存在
ps -ef | grep kafka
# 若未启动，启动服务
service kafka start
  2. 检查broker.id唯一性：
    # 节点1：broker.id=0，节点2：broker.id=1，节点3：broker.id=2
vim /usr/local/kafka/config/server.properties | grep "broker.id"
  3. 重新创建 Topic（副本数≤Broker 数量）：
    kafka-topics.sh --create --zookeeper 192.168.10.18:2181 --replication-factor 2 --partitions 3 --topic test

三、ELK 部署故障

3.1 故障 1：Elasticsearch 启动失败，日志报 “memory lock failed”

现象

执行systemctl start elasticsearch后，服务立即停止，查看日志（/var/log/elasticsearch/my-elk-cluster.log），提示 “memory lock failed: cannot allocate memory”。

根因

手册中elasticsearch.yml配置bootstrap.memory_lock: false（关闭内存锁定），但部分环境未生效，或系统内存不足（手册建议节点 2C/4G，内存不足导致启动失败）。

解决方案
  1. 确认系统内存满足要求（至少 4G）：
    free -h  # 确保available内存≥4G
  2. 修正elasticsearch.yml内存配置：
    vim /etc/elasticsearch/elasticsearch.yml
# 确保关闭内存锁定（手册推荐配置）
bootstrap.memory_lock: false
  3. 调整 JVM 内存（若内存不足，适当降低）：
    vim /etc/elasticsearch/jvm.options
# 手册默认配置（根据内存调整，不超过物理内存50%）
-Xms2g
-Xmx2g
  4. 重启 Elasticsearch：
    systemctl restart elasticsearch
netstat -antp | grep 9200  # 验证9200端口已监听

3.2 故障 2：Logstash 无法读取日志，报 “Permission denied”

现象

Logstash 启动后，日志（/var/log/logstash/logstash-plain.log）提示 “Permission denied when trying to read file /var/log/messages”，无法采集日志。

根因

手册中未给 Logstash 赋予日志文件读取权限，/var/log/messages等系统日志默认仅 root 用户可读，Logstash 以logstash用户运行，无访问权限。

解决方案
  1. 赋予日志文件读取权限：
    # 针对系统日志（手册示例采集/var/log/messages）
chmod +r /var/log/messages
# 针对Apache日志（采集/var/log/httpd/access.log时）
chmod +r /var/log/httpd/access.log
  2. 验证权限并重启 Logstash：
    ls -l /var/log/messages  # 确保其他用户有r权限（显示-rw-r--r--）
systemctl restart logstash

3.3 故障 3：Kibana 无法连接 Elasticsearch，报 “Kibana server is not ready yet”

现象

访问http://192.168.10.13:5601时，页面显示 “Kibana server is not ready yet”，查看 Kibana 日志（/var/log/kibana/kibana.log），提示 “Unable to connect to Elasticsearch”。

根因
  1. Elasticsearch 未启动或 9200 端口未监听（Kibana 无法访问 Elasticsearch）。
  2. kibana.yml中elasticsearch.hosts配置错误（IP / 端口与 Elasticsearch 不一致）。
  3. Elasticsearch 开启跨域限制（手册中 Elasticsearch-head 需配置跨域，Kibana 若未配置则无法连接）。
解决方案
  1. 先验证 Elasticsearch 可访问：
    # 在Kibana节点（Node1）执行，确保返回JSON数据
curl http://192.168.10.13:9200
  2. 检查 Kibana 配置：
    vim /etc/kibana/kibana.yml
# 确保与Elasticsearch地址一致（手册示例）
elasticsearch.hosts: ["http://192.168.10.13:9200"]
  3. 配置 Elasticsearch 跨域（若未配置）：
    vim /etc/elasticsearch/elasticsearch.yml
# 末尾添加（手册中Elasticsearch-head需此配置，Kibana同理）
http.cors.enabled: true
http.cors.allow-origin: "*"
systemctl restart elasticsearch
  4. 重启 Kibana：
    systemctl restart kibana
netstat -antp | grep 5601  # 验证5601端口监听

3.4 故障 4：Filebeat 无法发送日志到 Kafka，报 “Failed to connect to broker”

现象

Filebeat 启动后，日志（/var/log/filebeat/filebeat）提示 “Failed to connect to broker 192.168.10.18:9092”，无法将日志发送到 Kafka。

根因
  1. Kafka 集群未启动，或 9092 端口未对外开放。
  2. Filebeat 的filebeat.yml中output.kafka.hosts配置错误（IP / 端口与 Kafka 不一致）。
  3. Kafka Topic 未创建（Filebeat 发送的topic: "httpd"不存在，Kafka 未开启自动创建 Topic）。
解决方案
  1. 验证 Kafka 集群与端口：
    # 在Filebeat节点测试Kafka 9092端口
telnet 192.168.10.18 9092
# 确认Kafka Topic存在（手册示例Topic为httpd）
kafka-topics.sh --list --zookeeper 192.168.10.18:2181 | grep httpd
  2. 修正 Filebeat 配置：
    vim /usr/local/filebeat/filebeat.yml
# 确保Kafka地址与Topic正确
output.kafka:enabled: truehosts: ["192.168.10.18:9092","192.168.10.21:9092","192.168.10.22:9092"]topic: "httpd"
  3. 若 Topic 不存在，创建 Topic 并重启 Filebeat：
    kafka-topics.sh --create --zookeeper 192.168.10.18:2181 --replication-factor 2 --partitions 3 --topic httpd
./filebeat -e -c filebeat.yml  # 重启Filebeat（二进制部署方式）

四、通用排查工具与步骤

基于两份手册的部署流程，推荐以下通用排查方法，覆盖三大组件的共性问题：

  1. 查看日志文件（核心手段）：
    • ZooKeeper：/usr/local/zookeeper-3.5.7/logs/zookeeper-root-server-*.log
    • Kafka：/usr/local/kafka/logs/server.log
    • Elasticsearch：/var/log/elasticsearch/my-elk-cluster.log
    • Logstash：/var/log/logstash/logstash-plain.log
    • Kibana：/var/log/kibana/kibana.log
    • Filebeat：/var/log/filebeat/filebeat（RPM 部署）或终端输出（二进制部署）
  2. 验证端口监听：
    # 关键端口列表（基于手册）
netstat -antp | grep -E "2181|9092|9200|5044|5601|9100"
# 2181(ZooKeeper)、9092(Kafka)、9200(Elasticsearch)、5044(Logstash Beats端口)、5601(Kibana)、9100(Elasticsearch-head)
  3. 检查配置文件一致性：
    • 多节点部署时，确保 ZooKeeper 的zoo.cfg、Kafka 的server.properties、Elasticsearch 的elasticsearch.yml在各节点配置一致（除myid、broker.id、node.name等唯一标识外）。
  4. 验证用户权限：
    • 所有组件的数据目录（如 ZooKeeper 的dataDir、Kafka 的log.dirs、Elasticsearch 的path.data）需归组件运行用户所有（如 Elasticsearch 归elasticsearch用户，ZooKeeper 归root或自定义用户）。
http://www.dtcms.com/a/402981.html

相关文章：

  • 专业视频修复软件，简单操作效果好
  • 微信小程序开发小白入门指南
  • 商标设计网站是哪个烟台网站公司
  • 卖狗做网站什么关键词最好成都做网站
  • 自然语言处理——情感分析 ＜上＞
  • 网站开发 一眼网站开发人员名片
  • uniapp手机端调试基座版本号为4.76, 版本号相同，跳过基座更新
  • vue核心原理实现
  • 在docker中容器使用iptables限制IP访问端口
  • iOS 26 耗电检测实战攻略，如何测电量掉速、定位高耗能模块与优化策略（适用于 uni-app 原生 App）
  • uniapp+＜script setup lang=“ts“＞解析后端返回的图片流并将二维码展示在页面中
  • 1- 十大排序算法（选择排序、冒泡排序、插入排序）
  • uniapp x 鸿蒙开发之调试证书签名配置
  • RabbitMQ-消息堆积
  • uniapp x鸿蒙开发之运行到鸿蒙模拟器
  • wordpress建站 外贸适合做装饰公司的名字
  • Web3实操：2025年DePIN 挂机项目要点分享
  • 公司做网站费用wordpress alchem
  • 内存对齐与变量/结构体分析
  • 常见开发语言在 Windows 上的默认编码格式
  • 卫朋：AI硬件产品怎么做？——雷达模块选型实操
  • 从另一个视角看Transformer：注意力机制就是可微分的k-NN算法
  • [优选算法专题三.二分查找——NO.21山脉数组的峰顶索引]
  • 湖南营销型网站建设推广如何更改网站标题
  • 云原生网络基础设施的核心组件Envoy
  • KubeSphere 社区版即将发布：开启云原生新篇章
  • K8s学习笔记(五) Velero结合minnio业务数据备份与恢复
  • 23种设计模式——组合模式（Composite Pattern）
  • 培训机构网站开发汉中杨海明
  • 2- 十大排序算法（希尔排序、计数排序、桶排序）