【RPC：分布式跨节点透明通信协议】【Raft：简单易实现的分布式共识算法】

若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力！有问题请私信或联系邮箱：funian.gm@gmail.com

RPC（远程过程调用）和 Raft（一种共识算法）是分布式系统中的两个核心技术，前者解决跨节点通信问题，后者解决分布式一致性问题，两者常结合使用（例如 Raft 节点间的交互依赖 RPC）。

RPC（远程过程调用）的核心是隐藏网络通信细节，让跨节点调用像本地函数一样简单，主打微服务内部高吞吐、低延迟的同步通信，是分布式系统中服务间交互的核心工具。

维度	具体内容
核心目标	跨节点透明调用，简化分布式服务间通信
核心组件	客户端 Stub、服务端 Skeleton、网络传输层、序列化/反序列化模块、服务发现（可选）
传输协议	主流基于 TCP（可靠传输），部分支持 UDP（轻量场景）
序列化方式	Protobuf（高性能）、JSON（通用）、Hessian（Java 生态）、Thrift（跨语言）
典型框架	gRPC、Dubbo、Thrift、Spring Cloud OpenFeign
适用场景	微服务内部同步调用（如订单服务调用库存服务）、高吞吐低延迟的跨节点交互
优点	调用简洁、性能优异、跨语言支持（部分框架）、适配复杂业务逻辑调用
缺点	强依赖网络稳定性、服务耦合度高于消息队列、不适合异步解耦场景

通信协议/方式	核心特点	通信方式	性能	耦合度	电商场景适配性
RPC（gRPC/Dubbo）	透明函数调用，二进制传输，支持流式通信	同步为主	高（低延迟、高吞吐）	中高	核心服务同步交互（下单→库存→支付）
REST API	基于 HTTP/HTTPS，资源导向，文本/JSON 传输	同步为主	中（开销略高）	低	对外接口（APP/小程序调用）、跨系统轻量交互
WebSocket	基于 HTTP 握手，全双工通信，支持实时推送	异步实时	高（长连接无重复握手）	中	实时场景（订单状态推送、直播商品互动）
消息队列（Kafka/RabbitMQ）	异步解耦，基于队列/主题分发消息，支持重试、削峰	异步为主	中（依赖队列存储）	低	非核心异步场景（日志收集、消息推送、订单异步通知）

Raft 的核心是通过"领导者选举+日志复制"机制，让分布式集群中多个节点对数据达成一致，兼顾容错性（允许半数以下节点故障）和易实现性，是分布式一致性领域的主流选择。

维度	具体内容
核心目标	解决分布式节点数据一致性问题，保证集群故障时数据不丢失、行为一致
核心机制	领导者选举、日志复制、任期机制、多数派确认（超过半数节点同意才生效）
角色划分	领导者（Leader）、追随者（Follower）、候选人（Candidate）
容错能力	支持半数以下节点故障（如 3 节点集群可容忍 1 节点故障，5 节点可容忍 2 节点）
典型应用	etcd、Consul、TiDB PD、Redis Cluster（变种）
适用场景	分布式配置中心、分布式锁、数据库主从同步、库存一致性存储
优点	逻辑简单易实现、安全性高（日志完整性保障）、容错性强、收敛速度快
缺点	依赖网络连通性（网络分区可能导致集群不可用）、不适合超大规模节点集群

共识算法	核心特点	复杂度	选举机制	容错性	典型应用	电商场景适配性
Raft	领导者选举+日志复制，任期机制，多数派确认	低	超时触发选举，多数投票胜出	容忍半数以下节点故障	etcd、Consul	配置中心（如商品配置同步）、分布式锁（库存扣减）
Paxos	基于提案-批准机制，无明确领导者（原始版本）	高	提案需获得多数节点批准	容忍半数以下节点故障	Chubby、Google Spanner	复杂分布式存储（如电商核心数据库分片）
ZAB（ZooKeeper Atomic Broadcast）	基于 Raft 改进，领导者固定任期，支持崩溃恢复	中	领导者选举+数据广播	容忍半数以下节点故障	ZooKeeper	服务注册中心、分布式协调（如订单状态同步）
Gossip	去中心化，节点随机同步数据，最终一致性	低	无领导者，数据扩散式同步	容忍任意节点故障（最终一致）	Redis Cluster、Cassandra	非核心数据同步（如商品浏览记录、统计数据）