区块链中文技术社区

Solana钱包监控器：实时追踪钱包活动

作者：Surou | 时间：January 17, 2026 | 分类：Solana-开源推荐 | 评论：0 评论

Solana Insider Monitor

一款用于监控 Solana 钱包活动、检测余额变化并接收实时警报的工具。

特征

  • 同时监控多个 Solana 钱包
  • 追踪代币余额变化
  • 重大变化实时警报
  • 集成 Discord 以发送通知
  • 钱包数据的持久存储
  • 优雅地处理网络中断

https://accursedgalaxy.github.io/Insider-Monitor/
https://github.com/AccursedGalaxy/Insider-Monitor

Solana RPC 网关

作者：Surou | 时间：January 16, 2026 | 分类：Solana-开源推荐 | 评论：0 评论

https://github.com/jxad/solana-rpc-gateway

一款高性能、可用​​于生产环境的 Solana RPC 基础架构网关。它提供跨多个 RPC 端点的智能负载均衡、自动故障转移和健康感知路由，支持 HTTP JSON-RPC 和 gRPC (Yellowstone) 协议。

特征

  • 智能负载均衡——在运行正常的端点之间进行轮询分配，并具有自动故障转移功能。
  • 双协议支持— HTTP JSON-RPC 代理 + Yellowstone gRPC 流式网关
  • 健康感知路由——持续的健康监控，包括正常运行时间检查和时隙同步验证
  • Redis 缓存— 可配置的缓存getTransaction，，，getProgramAccountsgetAccountInfogetMultipleAccounts
  • 速率限制——支持基于 IP 地址的速率限制，并支持 HTTP 和 gRPC 的白名单机制
  • 热重载——无需中断服务即可更改配置
  • 可观测性——结构化日志记录，集成 Seq、调试端点和指标跟踪

Solana 程序的 Go 索引器

作者：Surou | 时间：January 16, 2026 | 分类：Solana-开源推荐 | 评论：0 评论

https://github.com/lugondev/go-indexer-solana-starter

这是一个高性能的 Solana 区块链事件索引器，专为Starter Program和Counter Program而设计。该索引器监控并存储程序发出的所有事件到 MongoDB 或 PostgreSQL 数据库中，以便于查询和分析。

功能

多程序支持：同时索引启动程序（锚定事件）和计数器程序（基于日志的事件）
事件驱动架构：索引来自入门程序的 20 多种事件类型 + 来自计数器程序的 6 种事件类型
实时处理：轮询 Solana RPC 以获取新事务并立即处理事件。
支持多种数据库：MongoDB 和 PostgreSQL（支持数据库迁移）
双重解码策略：基于锚点判别器的解码 + 对数解析
并发处理：可配置批处理大小和并发数，以实现最佳性能
类型安全模型：具有正确序列化的强类型事件模型
生产就绪：优雅关机、错误处理和全面的日志记录

Nginx性能调优20条黄金法则：支撑10万并发的配置模板

作者：Surou | 时间：January 12, 2026 | 分类：Other-新手教程 | 评论：0 评论

一、概述

1.1 背景介绍

说实话，Nginx调优这事儿我踩过无数坑。记得2019年双11，我们电商平台流量暴涨，Nginx直接扛不住了，QPS从平时的2万飙升到8万，响应时间从50ms飙到了2秒，最后还是靠临时加机器扛过去的。那次事故之后，我花了大半年时间专门研究Nginx的性能极限，总结出了这20条黄金法则。

Nginx作为目前最流行的Web服务器和反向代理，官方数据显示单机可以轻松处理10万+的并发连接。但实际生产环境中，很多同学拿到默认配置就直接上了，结果发现连1万并发都扛不住。问题不在Nginx本身，而在于配置。

1.2 技术特点

Nginx采用事件驱动的异步非阻塞架构，这跟传统的Apache每个连接一个进程/线程的模式完全不同。打个比方：Apache像是银行柜台，每个客户都需要一个柜员全程服务；Nginx则像是叫号系统，一个柜员可以同时处理多个客户的不同阶段任务。

核心优势：

  • 内存占用低：处理10000个非活跃HTTP keep-alive连接仅需2.5MB内存
  • 事件驱动：基于epoll/kqueue，不会因为连接数增加而线性增长CPU消耗
  • 模块化设计：只加载需要的模块，减少资源浪费
  • 热部署：配置修改无需重启，平滑reload

1.3 适用场景

  • 高并发静态资源服务（图片、CSS、JS、视频）
  • 反向代理和负载均衡
  • API网关
  • SSL/TLS终结点
  • 缓存服务器
  • WebSocket代理

1.4 环境要求

组件 版本 说明
操作系统 Rocky Linux 9.4 / Ubuntu 24.04 LTS 内核版本建议5.15+
Nginx 1.26.2 / 1.27.0 mainline版本功能更新，stable版本更稳定
CPU 8核+ Nginx worker数量与CPU核心数相关
内存 16GB+ 主要用于连接缓冲和缓存
网络 万兆网卡 千兆网卡在高并发下会成为瓶颈
磁盘 NVMe SSD 日志写入和缓存需要高IOPS

二、详细步骤

2.1 准备工作

2.1.1 系统内核参数调优

在动Nginx配置之前，得先把操作系统底子打好。很多人忽略了这一步，结果Nginx配得再好也白搭。

# /etc/sysctl.conf 追加以下内容

# 文件描述符限制
fs.file-max = 2097152
fs.nr_open = 2097152

# TCP连接相关
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# TIME_WAIT优化（这个参数救过我无数次）
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 262144

# TCP keepalive
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 网络缓冲区
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 本地端口范围
net.ipv4.ip_local_port_range = 1024 65535

应用配置：

sysctl -p

2.1.2 文件描述符限制

这是个老生常谈的问题了，但每次接手新项目还是会遇到。Nginx报"Too many open files"错误，十有八九就是这个没配好。

# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
nginx soft nofile 1048576
nginx hard nofile 1048576

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=1048576

2.2 核心配置

法则1：worker进程数量配置

# 自动检测CPU核心数，省心省力
worker_processes auto;

# 或者手动指定，建议等于CPU核心数
# worker_processes 8;

# CPU亲和性绑定，减少CPU缓存失效
worker_cpu_affinity auto;

踩坑记录：早期我喜欢把worker_processes设成CPU核心数的2倍，觉得这样能处理更多请求。结果发现这是典型的过度优化，多出来的worker进程反而增加了上下文切换开销，QPS不升反降。

法则2：worker连接数配置

events {
    # 每个worker的最大连接数
    # 理论最大并发 = worker_processes * worker_connections
    worker_connections 65535;

    # 使用epoll事件模型（Linux 2.6+必选）
    use epoll;

    # 允许一个worker进程同时接受多个新连接
    multi_accept on;

    # 互斥锁，高并发场景建议关闭
    accept_mutex off;
}

法则3：文件描述符缓存

# main context
worker_rlimit_nofile 1048576;

法则4：sendfile零拷贝

http {
    # 开启sendfile，避免用户态和内核态之间的数据拷贝
    sendfile on;

    # 配合sendfile使用，减少网络报文段数量
    tcp_nopush on;

    # 禁用Nagle算法，减少延迟
    tcp_nodelay on;
}

原理解释：传统文件发送需要经历"磁盘->内核缓冲区->用户缓冲区->socket缓冲区"四次拷贝。sendfile直接在内核态完成"磁盘->socket缓冲区"的数据传输，理论上可以提升30%-40%的吞吐量。

法则5：超时配置

http {
    # 客户端请求头超时
    client_header_timeout 15s;

    # 客户端请求体超时
    client_body_timeout 15s;

    # 响应超时
    send_timeout 15s;

    # keepalive超时
    keepalive_timeout 65s;

    # keepalive请求数量限制
    keepalive_requests 10000;
}

踩坑记录：曾经有个项目，上传大文件总是失败。排查半天发现是client_body_timeout设成了10秒，但大文件上传需要更长时间。生产环境这个值建议根据实际业务调整，不要一刀切。

法则6：缓冲区配置

http {
    # 客户端请求体缓冲区
    client_body_buffer_size 128k;
    client_max_body_size 100m;

    # 请求头缓冲区
    client_header_buffer_size 4k;
    large_client_header_buffers 4 32k;

    # 代理缓冲区
    proxy_buffer_size 64k;
    proxy_buffers 8 128k;
    proxy_busy_buffers_size 256k;
}

法则7：Gzip压缩

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;

    # 压缩级别1-9，建议4-6，太高CPU消耗大
    gzip_comp_level 5;

    # 最小压缩长度，太小的文件压缩反而浪费CPU
    gzip_min_length 1024;

    # 压缩类型
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        application/xml+rss
        image/svg+xml;

    # 预压缩文件支持
    gzip_static on;
}

性能对比：

压缩级别 压缩率 CPU消耗 适用场景
1 低 最低 CPU受限环境
4-5 中 中等 通用场景（推荐）
9 高 最高 带宽极其昂贵

法则8：静态文件缓存

http {
    # 打开文件缓存
    open_file_cache max=100000 inactive=60s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}

server {
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
    }
}

法则9：日志优化

http {
    # 使用缓冲写入，减少磁盘IO
    access_log /var/log/nginx/access.log main buffer=64k flush=5s;

    # 或者对于高并发场景，考虑关闭access log
    # access_log off;

    # 错误日志级别
    error_log /var/log/nginx/error.log warn;
}

血泪教训：生产环境日志不要开debug级别！我曾经为了排查问题临时开了debug，结果磁盘一会儿就满了，服务直接挂掉。

法则10：SSL/TLS优化

http {
    # SSL会话缓存
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # SSL协议版本
    ssl_protocols TLSv1.2 TLSv1.3;

    # 优先使用服务器端加密套件
    ssl_prefer_server_ciphers off;

    # TLS 1.3加密套件
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
}

法则11：HTTP/2配置

server {
    listen 443 ssl;
    http2 on;

    # HTTP/2推送（Nginx 1.25.1+）
    # 注意：主流浏览器已逐步废弃Server Push
}

法则12：连接复用优化

upstream backend {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;

    # 与后端保持的连接数
    keepalive 300;

    # 单个连接最大请求数
    keepalive_requests 10000;

    # 连接超时
    keepalive_timeout 60s;
}

server {
    location /api/ {
        proxy_pass http://backend;

        # 必须使用HTTP/1.1才能使用keepalive
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

这条救命配置：很多人配了upstream的keepalive但不生效，99%是因为没加proxy_set_header Connection ""。默认情况下Nginx会把Connection头设成close，导致每次请求都新建连接。

法则13：负载均衡算法选择

upstream backend {
    # 最少连接数算法，推荐
    least_conn;

    # 或者IP哈希（需要会话保持时使用）
    # ip_hash;

    # 或者一致性哈希
    # hash $request_uri consistent;

    server 10.0.0.1:8080 weight=3;
    server 10.0.0.2:8080 weight=2;
    server 10.0.0.3:8080 weight=1 backup;
}

法则14：健康检查

upstream backend {
    server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
}

开源版Nginx的健康检查比较弱，只能被动检测。如果需要主动健康检查，建议：

  • 使用Nginx Plus（商业版）
  • 使用第三方模块nginx_upstream_check_module
  • 使用OpenResty

法则15：请求限流

http {
    # 定义限流区域
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
}

server {
    location /api/ {
        # 请求速率限制
        limit_req zone=api_limit burst=200 nodelay;

        # 并发连接限制
        limit_conn conn_limit 50;

        # 限流返回码
        limit_req_status 429;
        limit_conn_status 429;
    }
}

法则16：proxy优化

location /api/ {
    proxy_pass http://backend;

    # 连接超时
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;

    # 失败重试
    proxy_next_upstream error timeout http_502 http_503;
    proxy_next_upstream_tries 3;
    proxy_next_upstream_timeout 10s;

    # 请求头传递
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

法则17：缓存配置

http {
    # 定义缓存路径
    proxy_cache_path /var/cache/nginx levels=1:2
        keys_zone=api_cache:100m
        max_size=10g
        inactive=60m
        use_temp_path=off;
}

server {
    location /api/public/ {
        proxy_pass http://backend;
        proxy_cache api_cache;
        proxy_cache_valid 200 10m;
        proxy_cache_valid 404 1m;
        proxy_cache_use_stale error timeout updating;
        proxy_cache_lock on;

        add_header X-Cache-Status $upstream_cache_status;
    }
}

法则18：安全加固

http {
    # 隐藏版本号
    server_tokens off;

    # 安全响应头
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

server {
    # 禁止访问隐藏文件
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
}

法则19：状态监控

server {
    listen 127.0.0.1:8080;

    location /nginx_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }
}

法则20：平滑重载

# 检查配置文件语法
nginx -t

# 平滑重载配置
nginx -s reload

# 或者使用systemd
systemctl reload nginx

2.3 启动和验证

# 检查配置
nginx -t

# 启动服务
systemctl start nginx
systemctl enable nginx

# 验证运行状态
systemctl status nginx
curl -I http://localhost

三、示例代码和配置

3.1 完整配置示例

这是一份经过实战检验的完整配置，适用于10万并发场景：

# /etc/nginx/nginx.conf

user nginx;
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 1048576;

error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;

events {
    worker_connections 65535;
    use epoll;
    multi_accept on;
    accept_mutex off;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 日志格式
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" '
                    '$request_time $upstream_response_time';

    log_format json escape=json '{'
        '"time":"$time_iso8601",'
        '"remote_addr":"$remote_addr",'
        '"method":"$request_method",'
        '"uri":"$uri",'
        '"status":$status,'
        '"body_bytes_sent":$body_bytes_sent,'
        '"request_time":$request_time,'
        '"upstream_response_time":"$upstream_response_time"'
    '}';

    access_log /var/log/nginx/access.log main buffer=64k flush=5s;

    # 基础优化
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    server_tokens off;

    # 超时配置
    keepalive_timeout 65;
    keepalive_requests 10000;
    client_header_timeout 15;
    client_body_timeout 15;
    send_timeout 15;

    # 缓冲区
    client_body_buffer_size 128k;
    client_max_body_size 100m;
    client_header_buffer_size 4k;
    large_client_header_buffers 4 32k;

    # Gzip压缩
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 5;
    gzip_min_length 1024;
    gzip_types text/plain text/css text/javascript
               application/javascript application/json
               application/xml image/svg+xml;

    # 文件缓存
    open_file_cache max=100000 inactive=60s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # SSL优化
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

    # 限流配置
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    # 代理缓存
    proxy_cache_path /var/cache/nginx levels=1:2
        keys_zone=api_cache:100m
        max_size=10g
        inactive=60m
        use_temp_path=off;

    # 上游服务器
    upstream backend {
        least_conn;
        keepalive 300;
        keepalive_requests 10000;
        keepalive_timeout 60s;

        server 10.0.0.1:8080 weight=3 max_fails=3 fail_timeout=30s;
        server 10.0.0.2:8080 weight=3 max_fails=3 fail_timeout=30s;
        server 10.0.0.3:8080 weight=2 max_fails=3 fail_timeout=30s;
    }

    # 虚拟主机配置
    include /etc/nginx/conf.d/*.conf;
}

3.2 实际应用案例

案例1：电商平台静态资源服务器

背景：日均UV 500万，静态资源请求峰值QPS 5万

server {
    listen 80;
    listen 443 ssl;
    http2 on;
    server_name static.example.com;

    ssl_certificate /etc/nginx/ssl/static.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/static.example.com.key;

    root /data/static;

    # 图片资源
    location ~* \.(jpg|jpeg|png|gif|webp|ico)$ {
        expires 365d;
        add_header Cache-Control "public, immutable";
        add_header Vary Accept;
        access_log off;

        # WebP自动转换
        set $webp "";
        if ($http_accept ~* "webp") {
            set $webp ".webp";
        }
        try_files $uri$webp $uri =404;
    }

    # CSS/JS资源
    location ~* \.(css|js)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    # 字体资源
    location ~* \.(woff|woff2|ttf|eot)$ {
        expires 365d;
        add_header Cache-Control "public, immutable";
        add_header Access-Control-Allow-Origin *;
        access_log off;
    }
}

效果：优化后平均响应时间从15ms降到3ms，带宽使用减少40%（Gzip功劳）。

案例2：API网关配置

背景：微服务架构，需要统一入口，QPS峰值3万

upstream user_service {
    least_conn;
    keepalive 100;
    server 10.0.1.1:8080 max_fails=2 fail_timeout=10s;
    server 10.0.1.2:8080 max_fails=2 fail_timeout=10s;
}

upstream order_service {
    least_conn;
    keepalive 100;
    server 10.0.2.1:8080 max_fails=2 fail_timeout=10s;
    server 10.0.2.2:8080 max_fails=2 fail_timeout=10s;
}

server {
    listen 443 ssl;
    http2 on;
    server_name api.example.com;

    ssl_certificate /etc/nginx/ssl/api.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/api.example.com.key;

    # 公共配置
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Connection "";

    # 用户服务
    location /api/v1/users {
        limit_req zone=api_limit burst=50 nodelay;
        proxy_pass http://user_service;
        proxy_connect_timeout 3s;
        proxy_read_timeout 30s;
    }

    # 订单服务
    location /api/v1/orders {
        limit_req zone=api_limit burst=100 nodelay;
        proxy_pass http://order_service;
        proxy_connect_timeout 3s;
        proxy_read_timeout 60s;
    }

    # 健康检查
    location /health {
        access_log off;
        return 200 'OK';
        add_header Content-Type text/plain;
    }
}

四、最佳实践和注意事项

4.1 最佳实践

  1. 配置分离管理
    • 主配置只放全局参数
    • 每个虚拟主机独立配置文件
    • 使用include指令加载
  2. 灰度发布配置
split_clients $remote_addr $variant {
    10% backend_new;
    *   backend_old;
}

location /api/ {
    proxy_pass http://$variant;
}
  1. 配置版本控制
    • 所有配置纳入Git管理
    • 变更前必须review
    • 保留回滚版本
  2. 监控告警
    • 集成Prometheus + Grafana
    • 设置QPS、响应时间、错误率告警
    • 定期review性能数据

4.2 注意事项

常见错误 原因分析 解决方案
worker_connections不生效 系统文件描述符限制 检查ulimit -n和worker_rlimit_nofile
keepalive不生效 未设置proxy_http_version和Connection头 添加proxy_http_version 1.1和proxy_set_header Connection ""
Gzip不生效 Content-Type未在gzip_types列表中 添加对应的MIME类型
SSL握手慢 未启用session缓存 配置ssl_session_cache
499错误多 客户端提前断开 检查后端响应时间，调整超时设置
502/504错误 后端超时或不可用 检查upstream健康状态，调整超时参数

五、故障排查和监控

5.1 故障排查

5.1.1 常用排查命令

# 检查Nginx进程状态
ps aux | grep nginx

# 查看监听端口
ss -tlnp | grep nginx

# 实时查看访问日志
tail -f /var/log/nginx/access.log

# 实时查看错误日志
tail -f /var/log/nginx/error.log

# 查看连接状态统计
ss -s

# 查看TIME_WAIT连接数
ss -ant | grep TIME-WAIT | wc -l

# 测试配置文件
nginx -t

# 查看编译参数
nginx -V

5.1.2 性能分析

# 使用wrk进行压力测试
wrk -t12 -c400 -d30s http://localhost/api/test

# 使用ab进行压力测试
ab -n 10000 -c 100 http://localhost/api/test

# 查看nginx_status
curl http://127.0.0.1:8080/nginx_status

# 输出示例：
# Active connections: 2341
# server accepts handled requests
#  12847123 12847123 45123847
# Reading: 12 Writing: 89 Waiting: 2240

5.2 性能监控

5.2.1 Prometheus集成

# 需要安装nginx-prometheus-exporter
# 配置stub_status后，使用exporter采集数据

server {
    listen 127.0.0.1:8080;
    location /nginx_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }
}

Prometheus配置：

scrape_configs:
  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']

5.2.2 关键指标监控

指标 告警阈值 说明
nginx_http_requests_total - 请求总数，用于计算QPS
nginx_connections_active > 80% worker_connections 活跃连接数
nginx_connections_waiting - 等待连接数
5xx错误率 > 1% 服务端错误
平均响应时间 > 500ms 响应时间
upstream响应时间 > 1s 后端响应时间

5.3 备份与恢复

# 配置备份脚本
#!/bin/bash
BACKUP_DIR="/data/backup/nginx"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p ${BACKUP_DIR}
tar -czf ${BACKUP_DIR}/nginx_${DATE}.tar.gz /etc/nginx/

# 保留最近30天备份
find ${BACKUP_DIR} -name "*.tar.gz" -mtime +30 -delete

# 恢复命令
tar -xzf ${BACKUP_DIR}/nginx_20250107_120000.tar.gz -C /
nginx -t && systemctl reload nginx

六、总结

6.1 技术要点回顾

这20条黄金法则覆盖了Nginx性能调优的方方面面：

  • 系统层面：内核参数、文件描述符、CPU亲和性
  • Nginx核心：worker进程、连接数、事件模型
  • 传输优化：sendfile、TCP优化、keepalive
  • 内容优化：Gzip压缩、静态缓存、代理缓存
  • 安全防护：限流、超时、安全头
  • 监控运维：状态监控、日志分析、平滑重载

实施这些优化后，我见证过的性能提升：

  • QPS从1万提升到10万+（10倍）
  • 平均响应时间从200ms降到20ms（10倍）
  • 服务器资源利用率从80%降到30%（释放了更多资源）

6.2 进阶学习方向

  1. OpenResty：整合Lua脚本，实现复杂业务逻辑
  2. Nginx Plus：商业版特性，如主动健康检查、动态配置
  3. Kubernetes Ingress：云原生场景下的Nginx应用
  4. 性能极限突破：DPDK、io_uring等新技术

6.3 参考资料

附录

A. 命令速查表

命令 说明
nginx -t 测试配置文件语法
nginx -s reload 平滑重载配置
nginx -s stop 快速停止
nginx -s quit 优雅停止
nginx -V 查看编译参数
nginx -T 输出完整配置

B. 配置参数详解

参数 默认值 推荐值 说明
worker_processes 1 auto worker进程数
worker_connections 512 65535 单worker最大连接数
keepalive_timeout 75s 65s 客户端keepalive超时
keepalive_requests 100 10000 单连接最大请求数
client_max_body_size 1m 100m 请求体最大值
gzip_comp_level 1 5 Gzip压缩级别

C. 术语表

术语 解释
QPS Queries Per Second，每秒查询数
TPS Transactions Per Second，每秒事务数
Keepalive 持久连接，复用TCP连接
Upstream 上游服务器，即后端服务
Reverse Proxy 反向代理
Load Balancing 负载均衡
epoll Linux高效的I/O事件通知机制
Zero Copy 零拷贝技术，减少数据拷贝次数

转载自：https://mp.weixin.qq.com/s/F8PigJFi_cHSOG5OCJ0_Fg

Solana 检查交易confirmed状态时间过长

作者：Surou | 时间：January 5, 2026 | 分类：Solana-新手教程 | 评论：0 评论

问题

业务中发送交易后，等待状态变为 confirmed 的时间较长，约 3 秒左右。

环境

  • 基于 Solana Agave 部署
  • 单 validator 私链

原因分析

confirmed 并不是交易立即执行的状态，而依赖 slot / vote / block commitment。

单 validator 下 confirmed 延迟原因

  • processed：leader 已执行交易（最快）
  • confirmed：交易所在 block 被投票确认
  • finalized：达到 supermajority

单 validator 情况：

  • 即便只有一个节点，也必须出 vote
  • vote 是单独交易，通常在 下一个或后续 slot 才完成
  • slot 时间偏大或交易量低 → vote 延迟 → confirmed 累积到 1–3 秒

即使 slot = 50ms，在低 TPS 私链下，confirmed 仍可能慢，因为 vote 被节流或跨多个 slot 才出。

解决方案

1. 客户端改用 processed

connection.confirmTransaction(sig, "processed")

或

sendAndConfirmTransaction(
  connection,
  tx,
  signers,
  { commitment: "processed" }
)
  • processed 延迟：几十 ms
  • confirmed 延迟：1–3 秒

单 validator 私链中，processed 基本安全，不会发生共识回滚。

2. 风险说明

  • 唯一风险来自 节点崩溃/重启：block 未落盘 → 交易可能丢失
  • 非共识风险，仅进程级别

3. 优化 confirmed 延迟

  • 低 TPS 私链可通过增加压测交易：
    • 每个 slot 保持交易 → vote 更快产生 → confirmed 延迟缩短
  • 压测交易可使用无害空交易
    • 发送 0 SOL 的转账
    • from/to 同一个账户

4. 综合方案（推荐）

目标：保证业务交易快速反馈，同时降低 confirmed 延迟

  1. 客户端
    • 使用 commitment = processed
    • 立即返回成功，提升用户体验
  2. 后台服务
    • 异步监听交易 signature
    • 等 confirmed / finalized
    • 极端情况（几秒后未 confirmed） → 补偿或重发
  3. 压测优化（可选）
    • 在私链 TPS 较低时，可增加持续模拟交易
    • 每个 slot 都有交易 → vote 更快生成 → confirmed 时间缩短
    • 可使用无害空交易，不影响业务逻辑

该方案兼顾速度、确认可靠性，并可通过压测交易进一步降低 confirmed 延迟

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 234

最新文章
不同区块链 Web3 钱包的密钥管理方式Databasus 支持 MySQL 和 MongoDB 的 PostgreSQL 备份工具Trustivon VPN 一款企业级区块链基础设施安全接入管理方案Docker 一键部署 WireGuard VPN，支持可视化管理与监控Docker部署OpenVPN实战指南 | Web可视化配置 | 完美接入多种组网方案Solana钱包监控器：实时追踪钱包活动Solana RPC 网关Solana 程序的 Go 索引器Nginx性能调优20条黄金法则：支撑10万并发的配置模板Solana 检查交易confirmed状态时间过长

最新回复
fzd: 请问这个解决了吗 StarkWare explained: layer 2 solution provider of dYdX and iMMUTABLE R11; BitKeep News: [...]Layer 2: https://... 一文读懂 StarkWare：dYdX 和 Immutable 背后的 L2 方案 R11; BitKeep 博客: [...]Layer 2:Comparing Laye... http://andere.strikingly.com/: Regards, Great stuff! surou: 需要先执行提案合约申请，等待出块节点地址同意后，才会进... heco: WARN [11-19|11:26:09.459] N... P: 你好，我在heco链上遇到了“tx fee excee... Peng: 楼主安装成功了吗？我正在同步区块链，一天了，差不多才同... joyhu: 你好，请问下安装好之后如何获取到bee.yaml配置文... kaka: 支票最终怎么提币呢？

标签

归档
March 2026February 2026January 2026December 2025November 2025October 2025September 2025August 2025July 2025June 2025May 2025April 2025March 2025February 2025January 2025December 2024November 2024October 2024September 2024August 2024July 2024June 2024May 2024April 2024March 2024January 2024December 2023November 2023October 2023September 2023August 2023July 2023June 2023April 2023March 2023February 2023January 2023December 2022November 2022October 2022August 2022July 2022June 2022May 2022March 2022February 2022January 2022December 2021November 2021October 2021September 2021August 2021July 2021June 2021May 2021April 2021March 2021February 2021January 2021December 2020November 2020October 2020September 2020July 2020June 2020May 2020April 2020March 2020February 2020January 2020December 2019November 2019October 2019September 2019August 2019July 2019June 2019May 2019April 2019March 2019February 2019January 2019December 2018November 2018October 2018September 2018August 2018July 2018June 2018

友情链接

友情链接
NSetup安装包制作 Trustivon 区块链定制方案 添加QQ群

其他
文章 RSS 评论 RSS