Linux服务自动拉起需配置systemd的Restart=on-failure、RestartSec=5、StartLimitIntervalSec=60、StartLimitBurst=3和RestartPreventExitStatus=SIGTERM。
服务挂了怎么自动拉起来
Linux 服务意外退出后不自启，是高可用最基础的失守点。systemd 是当前主流方案，但很多人只写 ExecStart，漏掉关键恢复逻辑。
常见错误现象：systemctl status myapp 显示 inactive (dead)，日志里只有“Process exited, code=exited status=1”，没重试、没告警、没人知道。
- 必须加
Restart=on-failure（不是always，否则崩溃循环会压垮机器） -
RestartSec=5控制重启间隔，避免密集失败打满日志 - 搭配
StartLimitIntervalSec=60和StartLimitBurst=3防止 1 分钟内连续崩 3 次就永久停服 - 用
RestartPreventExitStatus=SIGTERM排除主动 stop 的误判
示例片段：
[Service] ExecStart=/usr/local/bin/myapp --config /etc/myapp/conf.yaml Restart=on-failure RestartSec=5 StartLimitIntervalSec=60 StartLimitBurst=3 RestartPreventExitStatus=SIGTERM
两个节点怎么避免脑裂
双机热备时，主节点网络抖动断连，备节点升主，结果主节点又活了——两边都写数据，数据就乱了。这不是配置问题，是共识缺失。
核心矛盾：Linux 本身不提供分布式锁或法定数机制，得靠外部协调。
- 不要手写心跳脚本比端口通不通，
ping或nc -z无法区分“网络分区”和“服务卡死” - 优先用
corosync + pacemaker，它内置quorum投票和fencing（STONITH）机制，能物理断电隔离异常节点 - 如果不用集群套件，至少用
etcd或consul做租约（lease），靠 TTL 续约判断存活性，比 ping 可靠得多 - 务必配置 fencing：比如用 IPMI 控制电源，或云上用 API 强制关机，否则脑裂时没兜底
磁盘坏了数据还能找回来吗
单机 RAID 或 LVM 不等于容灾。RAID5 坏两块盘就丢数据，LVM 快照不跨机器，备份没验证过等于没备。
真实容灾看三点：时间点（RPO）、恢复时长（RTO）、故障域隔离。
-
rsync增量同步到另一台机器？得配--delete-after和校验，否则删错文件会秒传过去 - 数据库别只 dump SQL，
pg_basebackup或mysqldump --single-transaction才保一致性；MySQL 还要开binlog做增量追平 - 对象存储（如 S3 兼容接口）比 NFS 更适合作为备份终点，天然防误删、带版本控制
- 每月至少一次
restore test：从备份拉出新实例，跑通读写链路，否则备份文件损坏你根本不知道
云上 LB 后面加几台才够
加机器不等于高可用。LB 转发策略、健康检查路径、服务启动顺序，三者错一个，流量就进黑洞。
典型翻车现场：curl http://localhost:8080/health 返回 200，但 LB 健康检查用的是 /status，结果永远 404，整组被摘除。
- 健康检查路径必须真实反映服务就绪状态，不能只返回 HTTP 200，要查 DB 连接、缓存连通性等依赖项
- LB 的超时时间（
timeout connect/timeout server）必须大于服务冷启动耗时，否则新实例刚起就被判死 - 滚动发布时，旧进程得等新实例通过健康检查后再退出，用
systemd的ExecStopPost或 SIGUSR2 + graceful shutdown - 云厂商 LB 默认权重都是 1，但实际 CPU/内存负载不均，得结合
target group权重或自定义指标动态调权
事情说清了就结束。真正难的不是配几个参数，而是把“服务活着”这件事，拆解成可观测、可中断、可证伪的具体信号——否则所有高可用设计，都只是心理安慰。
