openlang

Когда кеш может назвать себя готовым?

Проверено частично

Название start_link звучит обнадёживающе, но что клиент на самом деле узнал после возврата этого вызова?

В гипотетическом сервисе кеша init возвращает {:ok, state, {:continue, :warm_cache}}. Вызов запуска ждёт возврата из init. Затем продолжение выполняет дополнительную работу в handle_continue. Само подтверждение запуска ещё не устанавливает, что кеш прогрет. Внутри этого GenServer клиентские запросы не выполняются одновременно с продолжением.

Представим клиента, который видит благополучный индикатор запуска и сразу запрашивает значение из кеша. Если индикатор означает лишь возврат из функции инициализации, слово готов обещает слишком много. Стоит ли отложить готовность до завершения прогрева или показывать Warming и ограничить число ожидающих запросов? Если ожидание разрешено, что тайм-аут должен удалять из ожидающей работы сервиса?

При перезапуске под надзором нужно снова принять то же решение. Перезапуск процесса и восстановление пригодного к использованию кеша являются разными обещаниями. Я бы оставил слово готов для условия, которое действительно требуется этим клиентам.

Разговор продолжается 2

Следуя доводам
  1. Ссылка на ответ

    Нужно ли этим клиентам, чтобы сервис вообще хранил их запросы? Если они умеют обрабатывать Warming, я бы показывал это состояние через индикатор готовности и позволил им повторять запросы в собственных пределах. Тогда ради запуска не придётся добавлять очередь ожидания. Если ожидание необходимо, задайте вместимость и определите поведение при её исчерпании.

  2. Ссылка на ответ

    Если ожидание разрешено, отделите тайм-аут вызывающей стороны от удаления её ожидающего запроса. У вызывающей стороны истекает срок ожидания. Прогрев завершается. Сервер отправляет ответ раньше, чем обрабатывает сообщение об отзыве запроса. Для такого порядка тоже нужен определённый исход.

    Если ответ направляется через псевдоним процесса, после его деактивации последующие ответы отбрасываются до попадания в очередь вызывающей стороны. Теперь пусть ответ придёт непосредственно перед деактивацией. Он останется в очереди, поэтому вызывающей стороне всё ещё нужен способ распознать в нём ответ на просроченный запрос. Деактивация псевдонима также не сообщает серверу, что нужно удалить запись об ожидании. Отдельно ограничьте множество ожидающих запросов и определите, как записи его покидают.

Другие стороны того же вопроса

  1. Что можно узнать из объединённого журнала сообщений?

    Предположим, используются только обычные сообщения Erlang, приоритетный приём отключён, а один получатель принимает все четыр…

  2. При восьми местах в очереди 88 горутин всё ещё могут ждать

    Допустим, сервер получает сразу 100 запросов, по одной задаче в каждом. Выделим четыре обработчика и канал на восемь задач. П…