Семантика RPC, что именно является целью

Ответ 1

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

Что касается того, как они реализованы, это может различаться, но псевдокод может выглядеть так:

At least once:
    request_received = false
    while not request_received:
       send RPC
       wait for acknowledgement with timeout
       if acknowledgment received and acknowledgement.is_successful:
          request_received = true


At most once:
   request_sent = false
   while not request_sent:
      send RPC
      request_sent = true
      wait for acknowledgement with timeout
      if acknowledgment received and not acknowledgement.is_successful:
         request_sent = false

Примерный случай, когда вы хотите сделать "максимально-один раз", будет чем-то вроде платежей (вы не захотите случайно списать счет кредитной карты дважды), где примерный пример "по крайней мере один раз", было бы чем-то вроде обновления базы данных с определенным значением (если вам приходится дважды записывать одно и то же значение в базу данных, что на самом деле не повлияет ни на что). Вы почти всегда хотите использовать "по крайней мере один раз" для операций без мутирования (a.k.a. idempotent); напротив, большинство мутирующих операций (или, по крайней мере, те, которые инкрементально мутируют состояние и, следовательно, зависят от текущего/предшествующего состояния при применении мутации), должны были бы "максимально-раз".

Я должен добавить, что довольно просто реализовать семантику "не более одного раза" поверх системы "по крайней мере один раз", включив в тело RPC идентификатор, который однозначно идентифицирует его, и обеспечивая на сервере, что каждый идентификатор, видимый системой, обрабатывается только один раз. Вы можете представить порядковые номера в пакетах TCP (гарантируя, что пакеты доставляются один раз и в порядке) в качестве частного случая этого шаблона. Однако этот подход может быть несколько сложным для правильной реализации распределенных систем, где повторы одного и того же RPC могут поступать на два отдельных компьютера, на которых выполняется одно и то же серверное программное обеспечение. (Один из способов борьбы с этим - записать транзакцию, в которой получен RPC, а затем скомпилировать и дедуплицировать эти записи с использованием централизованной системы до перераспределения запросов внутри системы для дальнейшей обработки, другой способ - оппортунистически обрабатывать RPC, но для согласования/восстановления/отката, когда синхронизация между серверами в конечном итоге обнаруживает это дублирование... этот подход, вероятно, не будет летать для платежей, но может быть полезен в других ситуациях, таких как сообщения на форуме).