tRPC-Go 与 RPC 基础

Sat, 05 Jul 2025 00:00:00 +0800

tRPC-go

先说一说RPC

remote procedure call protocol 远程调用协议

客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。

C/S 架构

当客户端发送的请求消息到达服务器时，服务器上的操作系统就将他传递给服务器存根（server stub）， 服务器存根是客户存根在服务器端的对应程序和真正实现，用来将通过网络输入的请求转化为本地过程调用 服务器存根一直在等待客户端的调用，处于阻塞状态，等待消息输入。

RPC流程

客户端进程以正常方式调用客户存根
客户存根生成一个消息。然后调用本地操作系统的网络通信模块，存根进入阻塞状态。
客户端操作系统将网络消息发送给远程操作系统。
远程操作系统将网络消息交给服务器存根。
服务器存根从网络消息将参数提取出来，而后调用服务器存根。
服务器执行相应的程序，操作完成后将结果返回给服务器存根。
服务器存根打包消息，调用本地操作系统。
发送给客户端操作系统。
客户端操作系统将消息交给客户端存根，存根从阻塞状态回复，进入运行状态。
客户端存根从消息中提取结果，返回调用的客户端。
过程中需要考虑的问题：

参数传递
通信协议
出错
超时处理

一些说明

既然是协议就只是一套规范。那么就需要有人遵循这套规范来进行实现典型的RPC协议 Dubbo Thrift gRPC Hetty
网络协议和网络io模型 对其透明既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。
信息格式对其透明.
应该有跨语言能力，调用方也不清楚远程服务器的应用程序是使用的什么语言与你性的，对于调用方来说，无论服务器方使用的什么语言，本次调用都应该成功。并且放回置应该按照调用方程序语言所能理解的形式表达。

IDL interface definition language

protocol buffer language .proto version 3

syntax = "proto3" &nbsp; // 必须
message SearchRequest{
 string query = 1;
 int32 page_number = 2;
 int32 result_per_page = 3;
}

tRPC 能做什么

搭建多个端口支持多个协议（一个端口对应一个协议）
搭建消息队列消费者服务提供消息队列生产者客户端发送消息
搭建本地定时器分布式定时器服务
搭建流式服务实现push 文件上传消息下发等流式模型
访问各种私有协议后端服务
通过trpc工具生成桩代码和服务模板

需要基础知识

Go语言基础
context原理
RPC概念
tRPC术语
proto3知识

安装 proto

Raft 共识算法笔记

Wed, 25 Dec 2024 00:00:00 +0800

分布式系统下的一致性问题

分布式系统有多个服务节点，给定一系列操作，在约定协议的保障下，使得它们对处理结果达成某种程度的协同。

分布式系统中的节点通信存在两种模型：

共享内存（Shared memory）
消息传递（Messages passing）。基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会响应慢、被杀死或者重启，消息可能会延迟、丢失、重复；发生上面任意一种异常都会对分布式系统中各个节点对某一个值达成一致性产生问题。

一致性

强一致性
弱一致性
最终一致性

共识算法 共识算法（Consensus Algorithm）是分布式系统中用于在多个节点之间就某个值达成一致的算法，即使在存在节点故障、网络分区的情况下，也能确保系统状态的一致性。

共识算法解决的问题

共识算法解决的是分布式系统对某个提案（Proposal），大部分节点达成一致意见的过程。提案泛指多个事件发生的顺序、某个键对应的值…对于分布式系而言，各个节点通常都是相同的确定性状态机模型（又称为状态机复制问题，State-Machine Replication），从相同初始状态开始接收相同顺序的指令，则可以保证相同的结果状态。

这里共识算法需要解决两个基本问题：

如何提出一个待共识的提案（令牌传递、随机选取…）
如何让多个节点对提案达成共识（投票、规则验证…）

现实网络环境中存在各种各样的问题，在分布式环境下，共识算法还需要解决如通信问题（网络中断、分区）、节点故障、消息伪造…

CAP定理 CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点，只能满足三项中的两项：

C（一致性）：任何事务都应该是原子的，所有副本上的状态都是事务成功提交后的结果，并保持强一致性。
A（可用性）：系统正常节点能在有限时间内完成对操作请求的应答。
P（分区容错性）：系统中的网络可能发生分区故障（成为多个子网、节点上线和下线），节点之间的通信无法保障，而网络故障不应该影响到系统正常服务。

结论：在分布式系统中 P 必须要保证，只能在 C 和 A 之间权衡：

保 C（强一致性）→ 可能牺牲可用性（如 Zookeeper）
保 A（高可用）→ 只能是最终一致性（如 Dynamo、Cassandra）

三类系统模型

CA（一致性+可用性）：包括完全严格的仲裁协议，例如2PC（两阶段提交）。
CP（一致性+分区容错性）：包括多数仲裁协议，其中少数分区不可用，例如Paxos。
AP（可用性+分区容错性）：包括执行最终一致性的协议，例如Gossip。

ACID ACID 即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）四种特性的缩写，一般出现在分布式数据库等基于事务过程的系统中；ACID 原则描述了分布式数据库需要满足的一致性需求，同时允许付出可用性的代价。

Atomicity: 每次事务是原子的，事务包含的所有操作要么全部成功，要么全部不执行。一旦有操作失败，则需要回退状态到执行事务之前；
Consistency: 数据库的状态在事务执行前后的状态是一致的和完整的，无中间状态。即只能处于成功事务提交后的状态；
Isolation: 各种事务可以并发执行，但彼此之间互相不影响。按照标准 SQL 规范，从弱到强可以分为未授权读取、授权读取、可重复读取和串行化四种隔离等级；
Durability: 状态的改变是持久的，不会失效。一旦某个事务提交，则它造成的状态变更就是永久性的。

BASE原则 BASE即 Basic Availability（基本可用），Soft-state（弱状态），Eventual Consistency（最终一致性），为 eBay 技术专家 Dan Pritchett 提出的与ACID相对的一个原则，主要面向大型高可用分布式系统，主张牺牲掉对强一致性的追求，而实现最终一致性，来换取一定的可用性。