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

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

功能

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

一、概述

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 环境要求

二、详细步骤

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;
}

性能对比：

法则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 注意事项

五、故障排查和监控

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 关键指标监控

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 参考资料

• Nginx官方文档：https://nginx.org/en/docs/
• Nginx性能调优指南：https://nginx.org/en/docs/http/ngx_http_core_module.html
• Linux内核参数详解：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

附录

A. 命令速查表

B. 配置参数详解

C. 术语表

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

问题

业务中发送交易后，等待状态变为 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. 修改 .gitmodules

   [submodule "libs/foo"]
    path = libs/foo
    url  = https://github.com/old-org/foo.git

   改成：

   [submodule "libs/foo"]
    path = libs/foo
    url  = https://github.com/new-org/foo.git

2. 同步配置

   git submodule sync

3. 更新子模块

   git submodule update --init --recursive

4. 更新仓库

   git add .gitmodules
   git commit -m "chore: update submodule foo url"
   git push

更换主仓库地址

1. 查看当前远端

   git remote -v

   你会看到类似：

   origin  https://github.com/old-org/project.git (fetch)
   origin  https://github.com/old-org/project.git (push)

2. 修改 origin 地址

   git remote set-url origin https://github.com/new-org/project.git

   验证

   git remote -v

3. 推送到新组织（第一次建议加 -u）

   git push -u origin main
   # 或
   git push -u origin master

github: https://github.com/Blockchain-Powered-eSIM
合约：https://github.com/Blockchain-Powered-eSIM/smart-contract-suite
钱包：https://github.com/Blockchain-Powered-eSIM/eSIM-Wallet
官网：https://www.kokio.app/
demo: https://alpha.kokio.app/
docs: https://docs.kokio.app/