【聊天系统的优化】RPC方式的优化

聊天系统的中RPC的选择

在RPC方式中，常用的三种方式：Json，protobuf，Msgback

设定一个简单的加和服务，客户端发送一个list给服务端，需要将list的数据都加和之后，返回加和的结果

在本地机器中不使用RPC方式：

cpp 复制代码

int sum(list* node){
	"计算加和值"
	return res;
}

执行10000，考虑"低数据量"和"高数据量"的两个场景

低数据量：node = [1,2] ,time:1.93ms

高数据量：node = [1,2,3,...], time:52ms

Json是使用最广泛的序列化方式，广泛应用于前后端之间的通信

优点：可读性高，兼容性广泛

{"name":"heyue","sex":"\u7537","company":"sina","age":30}
缺点：安全性低

如果使用json进行序列化，执行同样的次数耗时：

低数据量：nums=[1,2]: 18590.62ms

高数据量：nums=[1,2,3...,1000]: 20385.60ms

protobuf是一种比json性能更高的序列化方式，但是可读性要差一些，由于序列化之后数据是二进制的，所以其可读性会比较差

使用同样的执行次数，

低数据量：nums=[1,2]: 8654.08ms

高数据量：nums=[1,2,3...,1000]: 10014.39ms

protobuf的使用流程：

1、编写一个proto文件，其中定义需要处理的结构化数据（类似于一个结构体，内部定义了不同数据类型）

2、编译proto文件生成C++文件，编译结果为：一个.pb.h文件和一个.pb.c文件

3、编写main代码文件，填充proto文件中的结构体，并且将其序列化到一个数组中

msgpcak也是一种二进制的传输协议，比json更小更快，同时整体性能比protobuf更高，也不需要预先设定proto文件，也没有相应的数据校验。

优点：性能高，速度快，序列化之后的数据包小

缺点：由于没有数据校验，使得项目的维护成本比较高

其执行10000次的耗时：

低数据量：nums=[1,2]: 1111.17ms

高数据量：nums=[1,2,3...,1000]: 1610.63ms

以下是三种序列化方式柱状图的对比结果：

可以看到，Protobuf相比Json，快了1倍，而msgpack相比protobuf，快了10倍，这也就是说明了各自的性能差距，但是我们不能只看性能，有时候对性能的要求不是那么高的时候，我们还需要看是否高效好用。

由于protobuf比json的可读性差，那么如果需要可读性很好但是对性能要求不是那么高的场景下，我们就可以使用Json，而在前后端之间通信最常用的就是Json(为了可读性好)

由于msgpack相比protubuf少了数据校验，所以需要相互协作的场景下，就适合使用protobuf，而在后端不同服务之间的协作一般采用protobuf。