明锐有光 - 运维
type: channel
link: https://www.xiaohetao.xyz/category/default/
description: 运维相关
items: OpenResty
items: 一套脚本标准化所有新服务器
items: kafka常用命令
items: Kafka——Kafka安装（kafka_2.13-4.1.1）
items: zookeeper安装
items: Kafka——Kafka概述
items: kubectl常用命令
items: journalctl——systemd日志查询工具详解
items: curl与wget详解
items: 服务器资源需求评估惯用方法

OpenResty
type: item
date: 2025-12-06T11:53:00+08:00
description: OpenResty系统信息OpenResty在表ngx.conf里提供了六个功能接口，可以获取自身的一些信息：debug：是否算Debug版本prefix：工作目录，即启动时“-p”参数指定的目录nginx_version：大版本号，即内部NGINX的版本号nginx_configure:编译的使用的配置参数subsystem：当前所在的子系统，取值为“http”或“stream”ngx_lua_version：当前所在子系统的版本号注意： prefix和nginx_configure这两个接口是函数的形式。接口的示例代码如下：ngx.say(nginx.config.debug) ngx.say(nginx.config.prefix()) ngx.say(nginx.config.nginx_version) ngx.say(nginx.config.nginx_configure()) ngx.say(nginx.config.subsystem()) ngx.say(nginx.config.ngx_lua_version())OpenResty运行日志函数ngx.log(log_level)记录罗OpenResty的运行日志，用法类似Lua的标准库函数print，可以接受任意多个参数，记录任意信息。print()=ngx.NOTICEngx.log的第一个参数是日志级别。ngx.STDERR：日志直接打印到标准输出，最高级别的日志ngx.EMERG：发生了紧急情况（emergency），需要立即处理ngx.ALERT：发生了严重错误，可能需要报警给运维系统ngx.CRIT：发生了严重错误（critical）ngx.ERR：普通的错误，业务中发生了意外ngx.WARN：警告信息，业务正常，但可能需要检查警告的来源ngx.NOTICE：提醒信息，仅仅算告知，通常可以忽略ngx.INFO：一般的信息ngx.DEBUG：调试可用的信息，只有debug版本才会启用业务逻辑关键点INFO或者WARN，捕获error级别的错误信息OpenResty时间日期对于Web服务来说，能够随时获取正确的时间与日期是非常重要的。OpenResty为此提供罗很多时间日期相关的函数，可以满足绝大多数场景的应用。这些时间日期函数不会引发昂贵的系统调用（ngx.updatetime除外），几乎没有成本。所以在应用程序中应对尽量使用它们操作时间而不是使用Lua标准库里的os。当前时间ngx.say(ngx.today()) #本地时间，格式是“yyyy-mm-dd” ngx.say(ngx.localtime()) #本地时间，格式是“yyyy-mm-dd hh:mm:ss” ngx.say(ngx.utctime()) #utc时间，格式是“yyyy-mm-dd hh:mm:ss”时间戳ngx.time ngx.now时间戳

一套脚本标准化所有新服务器
type: item
date: 2025-12-04T23:03:00+08:00
description: 当拿到一台新服务器时，第一件事永远是根据实际业务来对服务器进行标准化设置。脚本特点智能系统识别 自动识别RHEL系(CentOS, RHEL, openEuler等)和Debian系(Ubuntu, Debian等)系统根据不同系统使用对应的包管理器(yum/dnf/apt)全面标准化配置高速软件源配置(阿里云镜像)基础运维工具安装Vim高级配置(语法高亮、Tab设置等)Shell别名与环境变量优化精确时间同步(chrony)内核参数优化(文件描述符、网络参数等)企业级审计系统(history增强+auditd)个性化登录欢迎界面SSH安全加固健壮性与错误处理Root权限检查配置文件备份机制兼容性处理详细的进度提示与状态反馈企业级安全特性操作审计追踪(谁、何时、从哪、做了什么)sudo特权操作监控SSH安全加固系统关键文件监控使用方法将脚本保存为server_init.sh赋予执行权限: chmod +x server_init.sh以root身份运行: sudo ./server_init.sh 警告: 脚本会修改系统关键配置，建议先在测试环境验证。特别是SSH安全加固部分会禁用密码登录，务必先配置好SSH密钥认证。这个脚本已经全面优化，可以适用于企业环境中大部分Linux服务器的标准化初始化需求，让运维工作更加高效、安全、规范。下载地址：{abtn icon="fa-download" color="#ff6800" href="https://www.xiaohetao.xyz/usr/uploads/2025/12/467932042.shh" radius="" content="点击下载"/}1.配置高速软件源使用的https://linuxmirrors.cn/提供的脚本bash <(curl -sSL https://linuxmirrors.cn/main.sh) \ --source mirrors.aliyun.com \ --protocol https \ --use-intranet-source false \ --install-epel true \ --backup true \ --upgrade-software false \ --clean-cache false \ --ignore-backup-tips2.安装运维工具包安装必需工具#centos系统基础工具包 dnf insta1l -y vim-enhanced #增强版Vim(带彩色高亮) dnf instal1 -y wget cur1 #下载工具(必须) dnfinsta11 -y net-tools #网络工具(ifconfig、netstat) dnfinsta11 -y rzsz #文件上传下载(比scp简单) dnf install -y tree # 树状显示目录 dnf install -y bash-completion #命令自动补全(新手神器) dnf install -y git # 代码管理 dnf insta11-y htop iotop iftop #增强版任务/i0/网络管理器Ubuntu系统把dnf换成apt即可。让工具更好用的配置# 1. Vim配置：从“勉强能用”到“得心应手” echo "正在配置Vim：告别默认vi的‘地狱模式’..." cat > /etc/vimrc <<'EOF' " 基础必改项 set number " 显示行号 - 没有行号的编辑器是在猜谜吗？ syntax enable " 语法高亮 - 一眼看出字符串、注释、关键字 set tabstop=2 " Tab宽度2空格（根据团队规范调整） set expandtab " Tab转空格 - 保证代码在所有人机器上显示一致 " 搜索增强 set incsearch " 边输入边高亮 set hlsearch " 保持高亮直到下次搜索 " 防止粘贴乱码 if has("mouse") set mouse=a " 启用鼠标（可以拖动、滚轮） endif set paste " 自动识别粘贴模式 EOF # 2. Shell别名：把复杂命令变成“肌肉记忆” echo "正在植入‘命令快捷键’..." cat >> /etc/bashrc <<'EOF' # ==== 安全防护 ==== alias rm='rm -i' # 删除文件时确认 alias cp='cp -i' # 覆盖文件时确认 alias mv='mv -i' # 覆盖文件时确认 # ==== 效率革命 ==== # 经典ls进化史：l → la → ll → llt alias l='ls -CF' alias la='ls -A' alias ll…

kafka常用命令
type: item
date: 2025-12-02T19:59:00+08:00
description: topic 相关说明：红色的是必需要指定的参数使用bin/kafka-topics.sh 可查看所有的参数信息参数描述--bootstrap-server <String: server connect to> 连接kafka broker主机名称和端口号--topic <String: topic> 操作的topic名称--create创建主题--delete删除主题--alter修改主题--list查看所有主题--describe查看主题详细描述--partitions <Integer: # of partitions>设置分区数--replication-factor <Integer: replication factor>设置分区副本--config <String: name=value>更新系统默认的配置root@kf1:/opt/kafka# bin/kafka-topics.sh --bootstrap-server kf1:9092 --describe --topic first Topic: first TopicId: o4AxZZfwQhG-QR38nHUGxQ PartitionCount: 3 ReplicationFactor: 3 Configs: min.insync.replicas=1,segment.bytes=1073741824 Topic: first Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 Elr: LastKnownElr: Topic: first Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1 Elr: LastKnownElr: Topic: first Partition: 2 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2 Elr: LastKnownElr: Topic: 主题名称TopicId: 主题IDPartitionCount: 分区数量ReplicationFactor: 副本数量Configs: min.insync.replicas=1,segment.bytes=1073741824Topic:Partition: 分区IDLeader: 副本的leaderReplicas: 副本存储位置Isr: 连接的副本LastKnownElr

Kafka——Kafka安装（kafka_2.13-4.1.1）
type: item
date: 2025-11-27T11:51:00+08:00
description: kafka2.8.0版本引入了基于Raft共识协议的新特性，它允许kafka集群在没有ZooKeeper的情况下运行。为了剥离和去除ZooKeeper，Kafka引入了自己的KRaft（Kafka Raft Metadata Mode）。KRaft是一个新的元数据管理架构，基于Raft一致性算法实现的一种内置元数据管理方式，旨在替代ZooKeeper的元数据管理功能。KRaft的优势有以下几点：简化部署：Kafka 集群不再依赖外部的 ZooKeeper 集群，简化了部署和运维的复杂性。KRaft 将所有协调服务嵌入 Kafka 自身，不再依赖外部系统，这样大大简化了部署和管理，因为管理员只需关注 Kafka 集群。高效的一致性协议：Raft 是一种简洁且易于理解的一致性算法，易于调试和实现。KRaft 利用 Raft 协议实现了强一致性的元数据管理，优化了复制机制。提高性能：由于元数据管理不再依赖 ZooKeeper，Kafka 集群的性能得到了提升，尤其是在元数据读写方面。增强可扩展性：KRaft 模式支持更大的集群规模，可以有效地扩展到数百万个分区。提高元数据操作的扩展性：新的架构允许更多的并发操作，并减少了因为扩展性问题导致的瓶颈，特别是在高负载场景中。更快的控制器故障转移：控制器（Controller）的选举和故障转移速度更快，提高了集群的稳定性。消除 ZooKeeper 作为中间层之后，Kafka 的延迟性能有望得到改善，特别是在涉及选主和元数据更新的场景中。KRaft模式下，kafka集群中的一些节点被指定为控制器（Controller），它们负责集群的元数据管理和共识服务，所有的元数据都存储在kafka内部的主题中，而不是ZooKeeper，控制器通过KRaft协议来确保元数据在集群中的准确复制，这种模式使用了基于时间的存储模型，通过定期快照来保证元数据日志不会无限增长。完全自主：因为是自家产品，所以产品的架构设计，代码开发都可以自己说了算，未来架构走向完全控制在自己手上。控制器（Controller）节点的去中心化：KRaft 模式中，控制器节点由一组 Kafka 服务进程代替，而不是一个独立的 ZooKeeper 集群。这些节点共同负责管理集群的元数据，通过 Raft 实现数据的一致性。日志复制和恢复机制：利用 Raft 的日志复制和状态机应用机制，KRaft 实现了对元数据变更的强一致性支持，这意味着所有控制器节点都能够就集群状态达成共识。动态集群管理：KRaft允许动态地向集群中添加或移除节点，而无需手动去ZooKeeper中更新配置，这使得集群管理更为便捷。下载在 kakfa官网 下载最新的安装包，推荐下载已经编译好的二进制包。wget https://dlcdn.apache.org/kafka/4.1.1/kafka_2.13-4.1.1.tgz tar -xzf kafka_2.13-4.1.1.tgz mv kafka_2.13-4.1.1 /opt/kafka修改配置文件修改位于config目录下的server.properties############################# Server Basics ############################# #定义节点角色。broker，处理消息存储、生产者/消费者请求；controller，管理集群元数据（分区状态、副本分配）。 process.roles=broker,controller # 节点id，要求集群内唯一，每个节点的id都要不同（如 1、2、3）。 node.id=1 #Controller节点启动时发现的初始服务器列表（用于加入集群）。 controller.quorum.bootstrap.servers=kf1:9093,kf2:9093,kf3:9093 #controller集群成员列表，集群内部选举和同步元数据，所有 Controller 节点必须在此列表中，且数量需满足多数派（如 3 节点集群需至少 2 个在线）。 controller.quorum.voters=1@kf1:9093,2@kf2:9093,3@kf3:9093 ############################# Socket Server Settings ##################### #节点绑定的网络接口和端口。PLAINTEXT:Broker服务端口（接收客户端请求），CONTROLLER:Controller间通信端口。 listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093 #Broker 之间通信使用的监听器名称 inter.…

zookeeper安装
type: item
date: 2025-11-25T22:39:00+08:00
description: ZooKeeper 是一个分布式协调服务，常用于管理配置、命名和同步服务。长期以来，Kafka 使用 ZooKeeper 负责管理集群元数据、控制器选举和消费者组协调等任务理，包括主题、分区信息、ACL（访问控制列表）等。ZooKeeper 为 Kafka 提供了选主（leader election）、集群成员管理等核心功能，为 Kafka提供了一个可靠的分布式协调服务，使得 Kafka能够在多个节点之间进行有效的通信和管理。然而，随着 Kafka的发展，其对 ZooKeeper的依赖逐渐显露出一些问题，这些问题也是下面 Kafka去除 Zookeeper的原因。kafka 2.8+ 为什么要移除zookeeper组件呢?kafka 4.0+版本彻底移除了zookeeper组件1.复杂性增加ZooKeeper 是独立于 Kafka 的外部组件，需要单独部署和维护，因此，使用 ZooKeeper 使得 Kafka的运维复杂度大幅提升。运维团队必须同时管理两个分布式系统（Kafka和 ZooKeeper），这不仅增加了管理成本，也要求运维人员具备更高的技术能力。2. 性能瓶颈作为一个协调服务，ZooKeeper 并非专门为高负载场景设计， 因此，随着集群规模扩大，ZooKeeper在处理元数据时的性能问题日益突出。例如，当分区数量增加时，ZooKeeper需要存储更多的信息，这导致了监听延迟增加，从而影响Kafka的整体性能。在高负载情况下，ZooKeeper可能成为系统的瓶颈，限制了Kafka的扩展能力。3. 一致性问题Kafka 内部的分布式一致性模型与 ZooKeeper 的一致性模型有所不同。由于 ZooKeeper和 Kafka控制器之间的数据同步机制不够高效，可能导致状态不一致，特别是在处理集群扩展或不可用情景时，这种不一致性会影响消息传递的可靠性和系统稳定性。4.发展自己的生态Kafka 抛弃 ZooKeeper，最核心的原因：Kafka生态强大了，需要自立门户，这样就不会被别人卡脖子。纵观国内外，有很多这样鲜活的例子，当自己弱小时，会先选择使用别家的产品，当自己羽翼丰满时，再选择自建完善自己的生态圈。但是一些旧版的kafka仍需配置ZooKeeper服务，因为Kafka依赖ZooKeeper进行集群协调、Broker注册、Topic管理等操作。安装ZooKeeperJava环境ZooKeeper是基于Java开发的，因此在部署时需要确保机器上有Java运行环境（JRE/JDK）。检查当前 Java 环境首先确认系统是否已安装 Java，以及版本是否符合要求java -version openjdk version "25.0.1" 2025-10-21 OpenJDK Runtime Environment (build 25.0.1+8-Ubuntu-124.04) OpenJDK 64-Bit Server VM (build 25.0.1+8-Ubuntu-124.04, mixed mode, sharing)若提示 command not found，说明未安装 Java，需继续安装java -version 找不到命令 “java”，但可以通过以下软件包安装它： apt install openjdk-17-jre-headless # version 17.0.17+10-1~24.04, or apt install openjdk-21-jre-headless # version 21.0.9+10-1~24.04 apt install default-jre # version 2:1.17-75 apt install openjdk-19-jre-headless # version 19.0.2+7-4 apt install openjdk-20-jre-headless # version 20.0.2+9-1 apt install openjdk-22-jre-headless # version 22~22ea-1 apt install openjdk-11-jre-headless # version 11.0.29+7-1ubuntu1~24.04 apt install openjdk-25-jre-headless # version 25.0.1+8-1~24.04 apt install openjdk-8-jre-headless # version 8u472-ga-1~24.04 root@zookeeper1:~/zookeeper# apt install openjdk-11-jre-headless 正在读取软件包列表... 完成 正在分析软件包的…

Kafka——Kafka概述
type: item
date: 2025-11-23T20:41:00+08:00
description: Kafka定义kafka传统定义：Kafka是一个分布式的基于发布/订阅模式的消息列队（Message Queue），主要应用于大数据实时处理领域。发布/订阅：消息的发布者不会将消息直接发送给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息。Kafka最新定义：Kafka是一个开源的 分布式事件流平台 （Event Streaming Platform），用于高性能 数据管道、流分析、数据集成和关键任务应用 。消息队列目前企业中比较常见的消息列队产品有Kafka、ActiveMQ、RabbitMQ、RocketMQ等。在大数据场景主要采用Kafka作为消息列队。在JavaEE开发中主要采用ActiveMQ、RabbitMQ、RocketMQ。传统消息列队的应用场景主要应用场景包括：缓冲/消峰、解耦和异步通信。缓冲/消峰有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。解耦允许独立的扩展或修改两边的处理过程，只需要确保它们遵守同样的接口约束。异步通信允许用户把一个消息放入队列，但并不立即处理它，然后在需要的时候再去处理它们。消息列队的两种模式1.点对点模式：消费者主动拉取数据，消息收到后清除消息2.发布/订阅模式：可以有多个topic主题（浏览、点赞、收藏、评论等）消费者消费数据之后，不删除数据每个消费者相互独立，都可以消费到数据Kafka特点数据吞吐量巨大：需要能够快速收集各个渠道的海量日志集群容错性高：允许集群内少量节点崩溃功能不需要太复杂：kafka的设计目标算高吞吐量、低延迟和可扩展性，主要关注消息传递而不是消息处理，所以kafka没有支持死信列队、顺序消息等高级功能允许少量数据丢失：在海量的应用日志中，少量的日志丢失算不会影响结果的。所以kafka的设计初衷算允许少量数据丢失的。当然，kafka本身也在不断优化数据安全问题。Kafka基础架构为方便扩展，提高吞吐量，一个topic分为多个partition配合分区的设计，提出消费者组的概念，组内每个消费者并行消费为提高可用性，为每个partition增加若干副本，类似NameNode HAZK中记录谁是leader，Kafka.8.0以后可以配置不采用ZKProducer：消息生产者，向Kafka broker发消息的客户端Consumer：消息消费者，向Kafka broker拉取消息的客户端Topic：主题，存储各种各样的数据注：一个分区的数据只能由一个消费者来消费。

kubectl常用命令
type: item
date: 2025-09-20T13:52:00+08:00
description: 集群信息显示 Kubernetes 版本：kubectl version显示集群信息：kubectl cluster-info列出集群中的所有节点：kubectl get node查看一个具体的节点详情：kubectl describe node <node-name>5.列出所有命名空间：kubectl get namespaces列出所有命名空间中的所有 pod：kubectl get pods --all-namespacesPod信息列出特定命名空间中的 pod：kubectl get pods -n <namespace>查看一个 Pod 详情：kubectl describe pod <pod-name> -n <namespace>查看 Pod 日志：kubectl logs <pod-name> -n <namespace>尾部 Pod 日志：kubectl logs -f <pod-name> -n <namespace>在 pod 中执行命令：kubectl exec -it <pod-name> -n <namespace> -- <command>Pod 亲和性和反亲和性列出 pod 的 pod 亲和性规则：kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.spec.affinity}'列出 pod 的 pod 反亲和性规则：kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.spec.affinity.podAntiAffinity}'节点污点 列出节点污点：kubectl describe node <node-name> | grep TaintsPod 优先级和抢占 列出优先级：kubectl get priorityclassesPod 开销 列出 pod 中的开销：kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.spec.overhead}'Pod 健康检查检查 Pod 准备情况：kubectl get pods <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'检查 Pod 事件：kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name>服务信息Service信息列出命名空间中的所有服务：kubectl get svc -n <namespace>查看一个服务详情：kubectl describe svc <service-name> -n <namespace>更改和验证 Webhook 配置列出变异 webhook 配置：kubectl get mutatingwebhookconfigurations列出验证 Webhook 配置：kubectl get validatingwebhookconfigurationsPod 网络策略 列出命名空间中的 pod 网络策略：kubectl get networkpolicies -n <namespace>部署相关Deployment信息列出命名空间中的所有Deployment：kubectl get deployments -n <namespace>查看一个Deployment详情：kubectl describe deployment <deployment-name> -n <namespace>查看滚动发布状态：kubectl rollout status deployment/<deployment-name> -n <namespace>查看滚动发布历史记录：kubectl rollout history deployment/<deployment-name> -n <namespace>作业和 CronJob列出命名空间中的所有作业：kubectl get jobs -n <namespace>查看一份工作详情：kubectl describe job <job-name> -n <namespace>列出命名空间中的所有 cron 作业：kubectl get cronjobs -n <namespace>查看一个 cron 作业详情：kubectl describe cronjob <cronjob-name> -n <namespace>StatefulSet信息列出命名空间中的所有 StatefulS…

journalctl——systemd日志查询工具详解
type: item
date: 2025-09-14T14:23:00+08:00
description: journalctl是systemd日志系统的查询工具。当你某个服务启动失败或出现错误时，系统会提示你使用这个工具来排查。使用grep、awk这类工具对日志进行处理时，可能遇到下面的情况导致排查困难。日志文件太大，grep半天没反应想看某个时间段的日志，结果要写一堆复杂的正则表达式系统重启后，之前的日志找不到了想看某个服务的完整日志链路，结果要翻好几个不同的文件基础用法直接使用journalctl命令，会看到系统从启动开始的所有日志。不过这样看起来会很乱，而且信息量巨大。加个-f参数，就像tail -f一样，可以实时显示最新的日志。当怀疑某个服务有问题的时候，开着这个命令，然后去操作一下，立马就能看到相关的日志输出。按时间查看日志#查看今天的日志 journalctl --since today #或者看昨天的： journalctl --since yesterday #看某个时间段的 journalctl --since "2024-01-15 14:00:00" --until "2024-01-15 15:00:00"按服务查看日志#只看nginx服务的日志 journalctl -u nginx #实时监控某个服务： journalctl -u nginx -f #有时候一个服务重启了好几次，你想看它的历史记录： journalctl -u nginx --since "1 hour ago"进阶技巧按优先级过滤#只显示错误级别的日志 journalctl -p err查看内核日志journalctl -k该命令等同于dmesg，但是journalctl的输出格式更友好，而且可以结合其他参数使用。按进程ID查看 有时候你知道某个进程有问题，可以直接按PID查看：journalctl _PID=1234查看启动信息 想看系统启动过程中发生了什么：journalctl -b如果系统重启过多次，你想看上一次启动的日志：journalctl -b -1这个功能在排查系统启动异常时特别有用。高级功能JSON格式输出 有时候你需要程序化处理日志，可以用JSON格式：journalctl -u nginx -o json这样输出的每一行都是一个JSON对象，方便后续处理。查看磁盘使用情况 journal日志会占用磁盘空间，你可以查看当前使用情况：journalctl --disk-usage如果空间不够，可以清理旧日志：journalctl --vacuum-time=7d只保留最近7天的日志。导出日志 有时候需要把日志发给其他人分析：journalctl -u myapp --since today > app_logs.txt反向查看日志 从最新的日志开始看：journalctl -r这个在查看最近发生的问题时很有用。配置优化持久化存储 默认情况下，有些系统的journal日志是存储在内存中的，重启后就丢失了。要启用持久化存储：sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald限制日志大小 编辑/etc/systemd/journald.conf：SystemMaxUse=1G SystemMaxFileSize=100M这样可以避免日志占用太多磁盘空间。常见问题和解决方案日志查看权限问题 有时候普通用户看不到某些日志，需要加入systemd-journal组：sudo usermod -a -G systemd-journal username日志时间显示问题 如果时间显示不对，可能是时区设置问题：journalctl --utc使用UTC时间显示。性能问题 如果journalctl查询很慢，可能是因为日志文件太大。可以考虑：清理旧日志调整日志级别使用更精确的过滤条件一些小技巧# 查看最近的错误日志，按时间倒序 journalctl -p err -r --since "1 hour ago" # 查看某个用户的所有日志 journalctl _UID=1000 # 查看系统启动耗时 systemd-analyze blame

curl与wget详解
type: item
date: 2025-09-13T16:29:00+08:00
description: curl简介全称是"Client URL"，顾名思义就是一个URL客户端工具。它最大的特点就是支持的协议特别多，HTTP、HTTPS、FTP、FTPS、SCP、SFTP、LDAP等等，基本上你能想到的网络协议它都支持。curl测试API接口非常方便。比如说要测试一个REST API，用curl简直不要太方便：[root@webtest ~]# curl -X GET https://v2.jinrishici.com/token {"status":"success","data":"5w1dZp7lNh+NpR0Ws6OG6TGCqp/2UgMf"}这样就能快速看到接口返回的数据，比打开浏览器或者用Postman要快多了。curl还有个很牛的地方就是它的参数特别丰富，几乎可以模拟任何HTTP请求。想要发送POST请求？没问题：curl -X POST -H "Content-Type: application/json" -d '{"name":"张三","age":25}' https://api.example.com/users需要带认证信息？也很简单：curl -u username:password https://api.example.com/protected 或者用Bearer token： curl -H "Authorization: Bearer your_token_here" https://api.example.com/datawgetwget简介wgetwget的全称是"Web Get"，它主要是用来从网络上获取文件的。相比curl，wget更专注于下载这一件事，在下载方面它做得确实很出色。wget有个递归下载功能。有一次需要备份一个静态网站，用wget一条命令就搞定了：wget -r -np -k -L -p https://example.com/这条命令会把整个网站都下载下来，包括CSS、JS、图片等所有资源，而且还会自动调整链接，下载完直接就能在本地打开。wget还有个很实用的功能就是断点续传。下载大文件的时候网络断了不用担心，加个-c参数就能接着下载：wget -c https://example.com/bigfile.zip 这个功能在网络不稳定的时候简直是救命稻草。两者的主要区别在哪里？最大的区别就是设计理念不同。curl更像是一个瑞士军刀，什么都能干，但是每样都不是最专业的；wget就像是一个专业的下载工具，在下载这件事上做得特别精细。从使用场景来说，一般是这样选择的：需要测试API、发送复杂HTTP请求的时候用curl单纯下载文件，特别是大文件或者需要递归下载的时候用wget需要在脚本里处理HTTP响应数据的时候用curl需要镜像整个网站或者批量下载的时候用wgetcurl的高级用法说到curl的高级用法，那可真是太多了。我经常用到的几个技巧分享给大家：保存响应头信息有时候需要查看服务器返回的头信息，可以用-I参数：curl -I https://www.baidu.com或者既要响应体又要响应头：curl -i https://api.example.com/data 跟随重定向默认情况下curl不会跟随重定向，需要加-L参数：curl -L https://short.url/abc123 设置超时时间网络不好的时候设置个超时时间很有必要：curl --connect-timeout 10 --max-time 30 https://slow.server.com使用代理需要通过代理访问的时候：curl --proxy http://proxy.server:8080 https://example.com 上传文件curl还能上传文件，这个功能很多人不知道：curl -X POST -F "file=@/path/to/file.txt" https://upload.example.com保存和使用Cookie处理需要登录的网站时，Cookie管理很重要：#保存cookie curl -c cookies.txt -d "username=admin&password=123456" https://example.com/login # 使用cookie curl -b cookies.txt https://example.com/protectedwget的实用技巧wget虽然看起来简单，但是用好了也很强大。限制下载速度在服务器上下载大文件的时候，为了不影响其他服务，可以限制下载速度：wget --limit-rate=200k https://example.com/bigfile.zip后台下载下载大文件时可以放到后台运行：wget -b https:/…

服务器资源需求评估惯用方法
type: item
date: 2025-09-13T16:15:00+08:00
description: 资源估算很关键，既关系到成本控制，也影响业务稳定性。CPU资源估算公式和方法CPU的估算相对来说比较复杂，因为不同类型的应用对CPU的需求差别很大。我总结了一套比较实用的计算方法。基础CPU需求计算公式CPU核心数 = (并发用户数 × 单用户CPU消耗 × 安全系数) / CPU利用率目标关键参数说明并发用户数：同时在线并产生请求的用户数单用户CPU消耗：每个用户请求平均消耗的CPU时间安全系数：通常取1.5-2.0CPU利用率目标：建议控制在70%以下不同应用类型的CPU需求参考表应用类型单用户CPU消耗(ms)推荐配置(1000并发)备注静态网站5-102-4核主要是文件读取简单Web应用20-504-8核基础CRUD操作复杂业务系统100-2008-16核复杂查询和计算实时计算200-50016-32核大量数据处理图像/视频处理500-100032核以上CPU密集型任务实际计算示例假设我们有一个电商网站：预期并发用户：2000人应用类型：复杂业务系统单用户CPU消耗：150ms安全系数：1.8CPU利用率目标：70%计算过程：CPU核心数 = (2000 × 0.15 × 1.8) / 0.7 = 771 / 0.7 ≈ 11核 建议配置：12-16核CPU内存需求精确计算内存的估算相对简单一些，但也有一套科学的计算方法。内存需求计算公式总内存需求 = 系统基础内存 + 应用内存 + 连接内存 + 缓存内存 + 预留内存各组件内存需求详细表格组件类型基础占用计算公式说明操作系统1-2GB固定值Linux系统基础占用Java应用512MB-2GB堆内存 + 非堆内存JVM参数配置Node.js应用100-500MB根据代码复杂度相对轻量Python应用50-200MB根据框架和库Django/Flask差异较大Go应用10-100MB编译型语言内存占用很小MySQL128MB起InnoDB缓冲池大小建议总内存的70%Redis根据数据量数据大小 × 1.2包含持久化开销Nginx2-10MB连接数 × 2KB反向代理占用连接内存计算公式连接内存 = 最大连接数 × 单连接内存占用不同服务的单连接内存占用：HTTP连接：2-8KB数据库连接：1-4MBWebSocket连接：4-16KB实际内存计算案例以电商网站为例：并发用户：2000人技术栈：Java + MySQL + Redis数据量：用户数据50万条，商品数据10万条组件计算过程内存需求操作系统固定2GBJava应用堆内存4GB + 非堆1GB5GBHTTP连接2000 × 8KB16MBMySQL数据量约2GB，缓冲池设置8GBRedis热点数据500MB × 1.2600MB预留空间总量的20%3GB总计 约19GB建议配置：24GB或32GB内存存储空间规划计算存储的估算看起来简单，实际上坑也不少。我整理了一套比较完整的计算方法。存储需求计算公式总存储需求 = 业务数据 + 日志文件 + 备份空间 + 系统文件 + 增长预留不同数据类型的存储需求表数据类型单条记录大小增长系数备注用户基础信息1-2KB1.5包含索引开销订单记录2-5KB2.0关联数据较多商品信息5-20KB1.8包含图片路径等日志记录200-500B1.2压缩后存储图片文件100KB-2MB1.0原始大小视频文件10MB-1GB1.0原始大小日志文件存储计算日志存储需求 = 日请求量 × 单条日志大小 × 保留天数日志类型单条大小保留期压缩比访问日志300-500B30天0.3应用日志200-800B7天0.4错误日志500-2KB90天0.5数据库日志100-300B7天0.3存储计算实例电商网站存储需求计算：数据类型数量单条大小小计增长系数最终需求用户数据50万1.5KB750MB1.51.1GB商品数据10万15KB1.5GB1.82.7GB订单数据100万3KB3GB2.06GB访问日志100万/天400B400MB/天30天12GB应用日志50万/天600B300MB/天7天2.1GB图片文件20万张500KB100GB1.0100GB备份空间业务数据×3 33GB系统文件固定 20GB 20GB总计 约177GB建议配置：250GB SSD + 500GB HDD的组合网络带宽需求计算网络带宽经常被忽视，但其实很重要。带宽需求计算公式所需带宽(Mbps) = 并发用户数 × 平均页面大小(MB) × 8 × 安全系数 / 页面加载时间(秒)不同业务场景的带宽需求表业务类型平均页面大小目标加载时间安全系数单用户带宽需求企业官网2-5MB3秒1.520-42Kbps电商平台3-8MB2秒2.048-128Kbps视频网站10-50MB5秒1.829-144Kbps直播平台持续流量实时…