gRP C Параллелизм для Stubs - PullRequest
0 голосов
/ 24 марта 2020

В gRP C Я хотел бы получить дополнительную информацию о том, как сервер обрабатывает запросы.

Параллельно выполняются запросы? Или сервер порождает новый поток для каждого запроса и выполняет их параллельно? Есть ли способ изменить это поведение? Я понимаю, что при потоковой передаче клиента rp c этот порядок сообщений гарантирован.

  • Если я отправлю Запрос A, за которым следует Запрос B, на тот же RP C, гарантируется ли, что A будет выполнен первым, прежде чем B начнет обработку? Или каждый из них имеет свой собственный поток и выполняется параллельно без гарантии того, что A завершится до B.

В идеале я хотел бы отправить запрос на сервер, сервер подтвердил бы получение запроса и затем запрос добавляется в очередь для последовательной обработки и возвращает ответ после его обработки. Подход, который я изучал, состоит в том, чтобы использовать внешнюю очередь задач (например, RabbitMQ), чтобы ставить в очередь работу, выполняемую службой, но я хочу знать, есть ли лучший подход.

Кроме того - на некоторой связанной ноте - есть ли у gRP C собственный механизм счетчиков повторов? У меня есть особо подверженный ошибкам RP C, который может потребоваться повторить до 3 раз (с произвольной задержкой между попытками), прежде чем он будет успешным. Это то, что может быть реализовано и с RabbitMQ.

1 Ответ

1 голос
/ 25 марта 2020

grp c - java передает RPC службе, используя Executor, предоставленный ServerBuilder.executor(Executor), или кешированный пул потоков , если не указан исполнитель.

Там нет порядка между одновременными RPC. RPC могут поступать в любом порядке.

Вы можете использовать RP C потокового сервера, чтобы сервер мог ответить дважды, один раз для подтверждения и один раз для завершения. Вы можете использовать oneof в ответном сообщении, чтобы разрешить отправку двух разных ответов.

grp c - java в качестве экспериментальной поддержки повторов. gRF C A6 описывает поддержку. Конфигурация доставляется клиенту через сервис конфигурации. Повторные попытки отключены по умолчанию, поэтому в целом вам нужно что-то вроде channelBuilder.defaultServiceConfig(serviceConfig).enableRetry(). Вы также можете сослаться на пример хеджирования , который очень похож на повторные попытки.

...