在 gRPC 中，我想了解有关服务器处理请求方式的更多信息。
请求是否并行执行？或者服务器是否为每个请求生成一个新线程，并并行执行它们？有没有办法改变这种行为？据我了解，在客户端流式 RPC 中，消息顺序是得到保证的。
- 如果我将请求 A 和请求 B 发送到同一个 RPC，是否可以保证 A 在 B 开始处理之前先执行？或者它们各自有自己的线程并并行执行，但不能保证 A 在 B 之前完成。
理想情况下，我想向服务器发送请求，服务器确认收到请求，然后将请求添加到队列中以顺序处理，并在处理后返回响应。我正在探索的一种方法是使用外部任务队列(如 RabbitMQ)对服务完成的工作进行排队，但我想知道是否有更好的方法。
此外，在某种程度上相关的说明上，gRPC 是否有 native 重试计数器机制？我有一个特别容易出错的 RPC，可能需要重试最多 3 次(重试之间有任意延迟)才能成功。这也可以使用 RabbitMQ 来实现。
最佳答案
grpc-java 使用 ServerBuilder.executor(Executor) 提供的 Executor 或 cached thread pool 将 RPC 传递给服务。如果没有提供执行者。
同时 RPC 之间没有顺序。 RPC 可以按任意顺序到达。
您可以使用服务器流 RPC 来允许服务器响应两次，一次用于确认，一次用于完成。您可以在响应消息中使用 oneof 来允许发送两个不同的响应。
grpc-java 作为实验性重试支持。 gRFC A6描述了支持。配置通过服务配置传递给客户端。默认情况下禁用重试，因此总的来说，您需要类似 channelBuilder.defaultServiceConfig(serviceConfig).enableRetry() 的内容。您还可以引用hedging example这与重试非常相似。
关于java - stub 的 gRPC 并发，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60832849/