cheungsuifai commented on issue #2769:
URL: https://github.com/apache/brpc/issues/2769#issuecomment-2401126289
更新一下当前的进展。
我尝试了使用streaming的方式来保序，技术上的确可行。但是考虑再三（参考了ChatGPT的意见），最后还是没有采用此方式。
原因包括：
1. 将 RPC 请求和响应通过流传输的设计不合理：
RPC 与 Streaming 的区别： 在 brpc 中，RPC 通常用于一次请求对应一次响应的通信模式，而 Streaming
更适合于传输大量数据或需要持续通信的场景。
混淆了 RPC 和 Streaming 的使用场景： 您的需求是在 Streaming 模式下传输 RPC 的请求和响应，这可能导致设计上的混乱。
2. 潜在的线程安全问题：
服务端的 StreamId 管理： 在服务端代码中，StreamingEchoService 使用了成员变量 _sd 来存储
StreamId。如果有多个客户端连接，可能会导致不同客户端的 StreamId 覆盖，产生线程安全问题。
3. 性能和效率问题：
重复的序列化和反序列化： 每次发送和接收消息时，都需要手动进行序列化和反序列化，增加了 CPU 开销。
缺乏流控和背压处理： 在高并发或大数据量的情况下，可能会出现消息堆积或网络拥塞的问题。
4. 未充分利用 brpc 的特性：
brpc 已支持异步 RPC 调用： 您希望实现低时延通信，但 brpc 本身已经支持异步的 RPC 调用，完全可以满足低时延的需求。
Streaming 适用场景： brpc 的 Streaming 更适合于大数据量的传输，而非频繁的小数据包传输。
最后我是采用在服务端根据log_id进行重新排序的方式实现保序的。
谢谢各位的支持。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For additional commands, e-mail: dev-h...@brpc.apache.org
