Re: [I] Request handling order on Server side (brpc)
TousakaRin closed issue #2769: Request handling order on Server side URL: https://github.com/apache/brpc/issues/2769 -- 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
Re: [I] Request handling order on Server side (brpc)
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
Re: [I] Request handling order on Server side (brpc)
cheungsuifai commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2376275337 > [Streaming RPC](https://github.com/apache/brpc/blob/master/docs/cn/streaming_rpc.md)可以保证顺序。 > [Streaming RPC](https://github.com/apache/brpc/blob/master/docs/cn/streaming_rpc.md)可以保证顺序。 再思考了一下，的确可以用到streaming的方式。 我将原来的多个RPC方法接口，统一到一个接口中。然后在随后的streaming通信中传递request和返回response。 感觉似乎不太优雅和奇怪，但技术上的确可行。 另外streaming是如何保序，是因为单线程处理吗？ -- 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
Re: [I] Request handling order on Server side (brpc)
chenzhangyi commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2374095772 > > 如果 A2 依赖 A1 的结果是不是 client A 在收到 A1 回复后再调用 A2？如果不依赖结果，只要求顺序执行，也可以合并 A1、A2 为新的 RPC 来处理吧。 > > 十分感谢您的回复，您的建议十分的有启发性！ 我已经测试过完全同步的方式（即Client在收到前一个RPC的响应再发送后一个），业务逻辑的确是可以正确执行的。 > > 只是我的场景有一些额外约束： > > 1. 对时延的要求十分的高，如果每一个RPC都需要等待前者响应，那么时延就长到不可接受，所以我采用了异步的模式，也引入了这个问题。 > 2. 我的业务逻辑中**RPC之间的依赖关系的数量和次序可能并不固定**（举例说明，即有一些场景是A1->A2, 有一些场景是A1->A2->A3->A4，另外一个场景是A1->A2->A4）。所以如果要合并多个RPC，就会面临组合数爆炸的问题。理论上我可以再剪枝掉一些不可能的组合，但估计剪枝的效益并不明显。 听你的描述是需要一个动态的DAG执行引擎，这个引擎来决定没有数据依赖的RPC能并发，有依赖的等前者，这个可能需要包装一下。 -- 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
Re: [I] Request handling order on Server side (brpc)
cheungsuifai commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2373129217 > 如果 A2 依赖 A1 的结果是不是 client A 在收到 A1 回复后再调用 A2？如果不依赖结果，只要求顺序执行，也可以合并 A1、A2 为新的 RPC 来处理吧。 十分感谢您的回复，您的建议十分的有启发性！ 我已经测试过完全同步的方式（即Client在收到前一个RPC的响应再发送后一个），业务逻辑的确是可以正确执行的。 只是我的场景有一些额外约束： 1. 对时延的要求十分的高，如果每一个RPC都需要等待前者响应，那么时延就长到不可接受，所以我采用了异步的模式，也引入了这个问题。 2. 我的业务逻辑中**RPC之间的依赖关系的数量和次序可能并不固定**（举例说明，即有一些场景是A1->A2, 有一些场景是A1->A2->A3->A4，另外一个场景是A1->A2->A4）。所以如果要合并多个RPC，就会面临组合数爆炸的问题。理论上我可以再剪枝掉一些不可能的组合，但估计剪枝的效益并不明显。 -- 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
Re: [I] Request handling order on Server side (brpc)
wasphin commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2373038035 如果 A2 依赖 A1 的结果是不是 client A 在收到 A1 回复后再调用 A2？如果不依赖结果，只要求顺序执行，也可以合并 A1、A2 为新的 RPC 来处理吧。 -- 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
Re: [I] Request handling order on Server side (brpc)
chenBright commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2372840263 同一个client用一个stream发 A1，A2，A3，server顺序处理，根据请求的特点分发到不同接口，就可以满足需求了吧？ -- 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
Re: [I] Request handling order on Server side (brpc)
cheungsuifai commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2372826534 > 顺序要求是针对不同client、不同server接口还是两者都有？ 针对同一个client的不同的server接口 例如现在有两个client（Client A，Client B）发送一系列的RPC请求。 Client A发送顺序是 A1，A2，A3 Client B发送顺序是 B1，B2，B3 Server多个线程收到的请求的时间顺序是A1，B1，B2，A3，B3，A2。 其中Client B的请求顺序是OK，按序执行即可； 而Client A的请求是乱序的（A1，A3，A2），我希望可以Server在执行的时候能按（A1，A2，A3）的顺序执行。 -- 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
Re: [I] Request handling order on Server side (brpc)
chenBright commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2372815810 顺序要求是针对不同client、不同server接口还是两者都有？ -- 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
Re: [I] Request handling order on Server side (brpc)
cheungsuifai commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2372764411 > [Streaming RPC](https://github.com/apache/brpc/blob/master/docs/cn/streaming_rpc.md)可以保证顺序。 谢谢你的回复。 但streaming的机制似乎是发起一个RPC调用，RPC后续数据使用stream传输，它能保证stream中传输的数据是有序的。但它并不适用于多个RPC（如果有多个RPC，会有多个相互独立的stream） 我现在的场景是client会发起多个不同的rpc的请求，希望server能发送顺序来处理。这样似乎stream并合适？ -- 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
Re: [I] Request handling order on Server side (brpc)
chenBright commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2372753814 [Streaming RPC](https://github.com/apache/brpc/blob/master/docs/cn/streaming_rpc.md)可以保证顺序。 -- 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
Re: [I] Request handling order on Server side (brpc)
yanglimingcn commented on issue #2769: URL: https://github.com/apache/brpc/issues/2769#issuecomment-2372684184 那只能自己收到请求做一个排序，再一个一个处理了。 -- 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
