请教数据库请求与 rpc 之间的差异

[bbmike253455]

背景:应用原请求方式，a->b->数据库，改成了 a->数据库，流量很大。 按道理说只是避免了 b 应用的转发逻辑，但实际上 a 应用 cpu 降了 8 个点左右，不知道是不是我带来的，所以想问 rpc 调用与直接调用数据库，有很大的差异吗？数据量大小，序列化方式什么，这些会影响 CPU 水位

[leaves615]

假设每个 IO 花费 20ms 时间，IO 等待在现代操作系统基本不消耗 CPU 资源。 序列化和反序列化是需要花费 CPU 资源，同样假设没错处理花费 10 个单位 CPU 占用。
a->b->数据库: 有两次 IO ，共计 40ms 时间，两次序列 /反系列操作，20 个单位占用。
a->数据库: 一次 IO ，计 20ms 时间，无序列 /反系列操作，0 个单位占用。

[bbmike253455]

@leaves615 你的计算方式是从整体上看的，b 应用 CPU 确实减少了，但是对于 a 应用来说，之前他与 b 应用发生 rpc 调用，后来与数据库，但是对于 a 来说调用次数并没有减少，只是协议发生变化，以前是 rpc ，现在数据库的

[leaves615]

a -> b -> db
a <- b <- db

a -> db
a <- db

[bbmike253455]

@leaves615 a 应用与数据库通信，也类似有序列化与反序列化的过程吧

[leaves615]

假设有，你的场景没有去掉数据库通信，在对比场景下它是恒定的。

[Jooooooooo]

rpc 本身就是耗性能的操作, 至少序列化 /反序列化就是要干活的.

[lambdaq]

说明你们 b 性能不行。

[cheng6563]

RPC 一是会增加延迟，也就是说会增加线程 /连接数等负担。二是序列化挺废性能的，尤其是你用 JSON 这类文本序列化的情况下，换用 Protocol 之类的二进制序列化方案会快很多，数据库通信应该就是用了二进制协议优化的。

[Macolor21]

IO 方面没有差异，主要是序列化的差别

- 数据库是：StringUtils.getBytes()
- 不太清楚你这边 RPC 用什么协议，JSON ？ Protobuf ？

对比下这两个方法的基本上就是你这边的性能差异了。