linux集群主从数据一致性需按数据类型选机制：数据库用mysql半同步或postgresql wal流复制并配patroni；小文件用rsync+inotify秒级单向同步；共享资源用nfs/glusterfs伪同步；分布式存储如hdfs则内建多副本强一致保障。
Linux 集群中实现主从架构的数据一致性，核心不是靠单一工具“自动搞定”，而是根据数据类型、实时性要求和一致性强度，选择匹配的机制并辅以必要保障措施。没有通用银弹，但有清晰路径。
数据库类结构化数据：依赖原生复制协议
MySQL、PostgreSQL 等关系型数据库必须使用其内置复制机制，文件同步（如 rsync）完全不适用——它无法处理事务、锁、并发写入冲突等语义。
- MySQL 主从复制：主库写 binlog → 从库 I/O 线程拉取 → SQL 线程回放。建议启用半同步（semisync），避免主库提交后宕机导致从库缺失数据
- PostgreSQL 流复制：WAL 日志实时传输 + replay，延迟可控制在毫秒级；搭配 Patroni 可实现自动故障转移与一致性仲裁
- 关键动作：监控复制延迟（Seconds_Behind_Master / pg_stat_replication）、定期校验主从数据（pt-table-checksum）、禁止从库写入
配置与静态文件：rsync + inotify 实现秒级单向同步
适用于 Web 配置、脚本、图片资源等非事务性小文件，强调“源唯一、推送可控”。
- inotifywait 监控源目录变更事件（IN_CREATE、IN_MOVED_TO），触发 rsync -avz --delete 推送，确保目标端与源端严格一致
- 必须设定唯一主源节点，所有从节点只接收、不反向推送，防止循环覆盖或状态错乱
- 若节点数 ≥5，建议改用 rsync daemon 模式：主节点运行 rsync --daemon，各从节点按需拉取（rsync://user@master/module/），降低 SSH 连接开销
多节点共享读写场景：用 NFS 或 GlusterFS 提供统一视图
当多个应用节点需同时读写同一份内容（如 CMS 图片库、日志归档目录），共享存储提供“伪同步”访问能力，修改即时可见。
- NFS：配置简单，适合中小规模；但文件锁较弱，高并发写入易出现覆盖或丢失，不适用于数据库文件
- GlusterFS：支持 replica 2/3 分布式副本，具备一定容错能力；需额外维护集群健康状态（gluster peer status），运维成本略高
- 注意：二者均不保证强一致性（如 POSIX 语义完整），仅推荐用于最终一致性可接受的静态资源
分布式存储系统：HDFS 等通过多层机制保障副本一致
像 HDFS 这类专为大规模设计的系统，一致性是内建能力，而非外部叠加：
- 写入时采用 pipeline 管道机制：客户端将数据块依次写入多个 DataNode，全部成功才返回确认
- NameNode 统一管理元数据，通过 JournalNode + ZooKeeper 实现高可用与操作原子性
- 每个数据块默认三副本，跨机架分布；DataNode 定期上报心跳，失效节点上的副本由 NameNode 自动调度重建
- 读取时支持一致性校验（checksum 校验和比对），并可在 Hadoop 3+ 中从 Standby NameNode 获取近实时元数据
