【RPC：分布式跨节点透明通信协议】【Raft：简单易实现的分布式共识算法】
文章目录
- 一、RPC：分布式跨节点透明通信协议
- 核心总结
- RPC 核心信息表格
- RPC 与类似通信协议对比表格
- 二、Raft：简单易实现的分布式共识算法
- 核心总结
- Raft 核心信息表格
- Raft 与类似共识算法对比表格
- 三、RPC 与 Raft 核心差异对比表格
若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力！有问题请私信或联系邮箱：funian.gm@gmail.com
RPC（远程过程调用）和 Raft（一种共识算法）是分布式系统中的两个核心技术，前者解决跨节点通信问题，后者解决分布式一致性问题，两者常结合使用（例如 Raft 节点间的交互依赖 RPC）。
一、RPC：分布式跨节点透明通信协议
核心总结
RPC（远程过程调用）的核心是隐藏网络通信细节，让跨节点调用像本地函数一样简单，主打微服务内部高吞吐、低延迟的同步通信，是分布式系统中服务间交互的核心工具。
RPC 核心信息表格
| 维度 | 具体内容 |
|---|---|
| 核心目标 | 跨节点透明调用，简化分布式服务间通信 |
| 核心组件 | 客户端 Stub、服务端 Skeleton、网络传输层、序列化/反序列化模块、服务发现（可选） |
| 传输协议 | 主流基于 TCP（可靠传输），部分支持 UDP（轻量场景） |
| 序列化方式 | Protobuf（高性能）、JSON（通用）、Hessian（Java 生态）、Thrift（跨语言） |
| 典型框架 | gRPC、Dubbo、Thrift、Spring Cloud OpenFeign |
| 适用场景 | 微服务内部同步调用（如订单服务调用库存服务）、高吞吐低延迟的跨节点交互 |
| 优点 | 调用简洁、性能优异、跨语言支持（部分框架）、适配复杂业务逻辑调用 |
| 缺点 | 强依赖网络稳定性、服务耦合度高于消息队列、不适合异步解耦场景 |
RPC 与类似通信协议对比表格
| 通信协议/方式 | 核心特点 | 通信方式 | 性能 | 耦合度 | 电商场景适配性 |
|---|---|---|---|---|---|
| RPC（gRPC/Dubbo） | 透明函数调用，二进制传输，支持流式通信 | 同步为主 | 高（低延迟、高吞吐） | 中高 | 核心服务同步交互（下单→库存→支付） |
| REST API | 基于 HTTP/HTTPS，资源导向，文本/JSON 传输 | 同步为主 | 中（开销略高） | 低 | 对外接口（APP/小程序调用）、跨系统轻量交互 |
| WebSocket | 基于 HTTP 握手，全双工通信，支持实时推送 | 异步实时 | 高（长连接无重复握手） | 中 | 实时场景（订单状态推送、直播商品互动） |
| 消息队列（Kafka/RabbitMQ） | 异步解耦，基于队列/主题分发消息，支持重试、削峰 | 异步为主 | 中（依赖队列存储） | 低 | 非核心异步场景（日志收集、消息推送、订单异步通知） |
二、Raft：简单易实现的分布式共识算法
核心总结
Raft 的核心是通过“领导者选举+日志复制”机制，让分布式集群中多个节点对数据达成一致，兼顾容错性（允许半数以下节点故障）和易实现性，是分布式一致性领域的主流选择。
Raft 核心信息表格
| 维度 | 具体内容 |
|---|---|
| 核心目标 | 解决分布式节点数据一致性问题，保证集群故障时数据不丢失、行为一致 |
| 核心机制 | 领导者选举、日志复制、任期机制、多数派确认（超过半数节点同意才生效） |
| 角色划分 | 领导者（Leader）、追随者（Follower）、候选人（Candidate） |
| 容错能力 | 支持半数以下节点故障（如 3 节点集群可容忍 1 节点故障，5 节点可容忍 2 节点） |
| 典型应用 | etcd、Consul、TiDB PD、Redis Cluster（变种） |
| 适用场景 | 分布式配置中心、分布式锁、数据库主从同步、库存一致性存储 |
| 优点 | 逻辑简单易实现、安全性高（日志完整性保障）、容错性强、收敛速度快 |
| 缺点 | 依赖网络连通性（网络分区可能导致集群不可用）、不适合超大规模节点集群 |
Raft 与类似共识算法对比表格
| 共识算法 | 核心特点 | 复杂度 | 选举机制 | 容错性 | 典型应用 | 电商场景适配性 |
|---|---|---|---|---|---|---|
| Raft | 领导者选举+日志复制，任期机制，多数派确认 | 低 | 超时触发选举，多数投票胜出 | 容忍半数以下节点故障 | etcd、Consul | 配置中心（如商品配置同步）、分布式锁（库存扣减） |
| Paxos | 基于提案-批准机制，无明确领导者（原始版本） | 高 | 提案需获得多数节点批准 | 容忍半数以下节点故障 | Chubby、Google Spanner | 复杂分布式存储（如电商核心数据库分片） |
| ZAB（ZooKeeper Atomic Broadcast） | 基于 Raft 改进，领导者固定任期，支持崩溃恢复 | 中 | 领导者选举+数据广播 | 容忍半数以下节点故障 | ZooKeeper | 服务注册中心、分布式协调（如订单状态同步） |
| Gossip | 去中心化，节点随机同步数据，最终一致性 | 低 | 无领导者，数据扩散式同步 | 容忍任意节点故障（最终一致） | Redis Cluster、Cassandra | 非核心数据同步（如商品浏览记录、统计数据） |
三、RPC 与 Raft 核心差异对比表格
| 维度 | RPC | Raft |
|---|---|---|
| 技术定位 | 分布式通信协议 | 分布式共识算法 |
| 解决问题 | 跨节点“如何调用”的通信问题 | 跨节点“数据如何一致”的共识问题 |
| 核心逻辑 | 封装网络交互，模拟本地调用 | 选举领导者+同步日志，达成一致 |
| 依赖关系 | Raft 实现需依赖 RPC 完成节点通信 | 不依赖 Raft，可独立使用 |
| 电商场景作用 | 服务间同步交互（如下单→支付） | 核心数据一致性保障（如库存、配置） |