Очередь параллельных запросов Carrier Lookup API для общих учетных записей
Практическое руководство по организации очереди параллельных запросов Carrier Lookup API для общих учетных записей с учетом лимитов и этапов проверки.
Очередь параллельных запросов Carrier Lookup API должна координировать всех исполнителей, использующих одну учетную запись, а не позволять каждому процессу самостоятельно определять доступную емкость.
Очередь параллельных запросов Carrier Lookup API должна координировать всех исполнителей, использующих одну учетную запись, а не позволять каждому процессу самостоятельно определять доступную емкость. CarrierLookup регламентирует количество одновременно выполняемых запросов в реальном времени и отдельный шлюз для одного мультизапроса. Направляйте одиночные и синхронные мультизапросы через контроллер на уровне учетной записи, сохраняйте порядок ввода для каждого мультизапроса и освобождайте слот только после завершения запроса. Эти элементы управления регулируют одновременную работу; они не являются квотой в минуту или гарантией времени ответа.
Моделируйте учетную запись, а не отдельного исполнителя приложения
Определение исходного оператора (Original Carrier Lookup) возвращает контекст первоначального распределения номера: исходного оператора, базового оператора, тип номера и географию распределения. Оно не сообщает текущего оператора после переноса номера и не определяет, может ли номер принимать вызовы или сообщения. Термин «в реальном времени» здесь означает рабочий процесс «запрос-ответ», а не проверку сети в режиме live. Определение исходного оператора API является соответствующей страницей продукта, а документация API должна оставаться источником актуальных сведений об интеграции.
Когда несколько служб используют одну учетную запись API, семафора на уровне процесса недостаточно. Два веб-воркера, фоновый импорт и аналитический инструмент могут одновременно «считать», что у учетной записи есть свободные слоты. Документированные публичные правила описывают пять общих слотов для запросов в реальном времени и один мультизапрос на учетную запись. Поэтому контроллер на стороне клиента должен использовать единый координатор уровня учетной записи или другой механизм, который предоставляет всем участвующим исполнителям согласованное представление о текущих вызовах. Выбор технологии хранения или очереди остается за клиентом.
Очередь должна содержать конверт запроса с отправленным идентификатором E.164 (или идентификаторами), режим запроса, ссылку на рабочее задание приложения и время постановки в очередь. Это предлагаемые поля на стороне клиента, а не утверждение о схеме ответа CarrierLookup. Избегайте логирования полных номеров или учетных данных, если политика организации не требует их защиты.
Разделите шлюзы для одиночных и мультивызовов
Одиночный запрос принимает один номер E.164. Синхронный мультизапрос принимает от 1 до 100 номеров E.164 и возвращает упорядоченный результат в одном ответе. Оба варианта являются проверками в реальном времени, но мультизапрос также имеет ограничение «один за раз» на уровне учетной записи. Спроектируйте два шлюза: общий счетчик емкости для всех выполняемых запросов в реальном времени и эксклюзивный шлюз для мультизапроса. Мультизапрос должен запрашивать необходимую емкость в соответствии с документированными правилами учетной записи и эксклюзивным шлюзом; реализация должна освобождать оба ресурса вместе после завершения ответа или терминальной ошибки.
Не рассматривайте мультизапрос как асинхронную задачу с файлом. Отдельный продукт Global carrier lookup принимает файлы TXT или CSV, подготавливает идентификаторы и позже создает один CSV-файл. Он относится к другому рабочему процессу. Страница как работает CarrierLookup помогает читателям различать эти режимы. Если приложению требуется обработка большого файла, осознанно выбирайте документированный продукт для массовой обработки, а не отправляйте файл в синхронную очередь.
Координатору также необходима справедливость. Постоянный поток одиночных запросов не должен блокировать уже поставленный в очередь мультизапрос, в то время как один крупный импорт не должен бесконечно блокировать небольшие интерактивные проверки. Правило планирования на стороне клиента может резервировать очередь по времени поступления или использовать политику ограниченного приоритета. Это рекомендация по рабочему процессу, а не гарантия планирования со стороны провайдера.
Обработка тайм-аутов и сбоев исполнителей как терминальных событий очереди
Одиночный запрос и мультизапрос имеют документированные пределы тайм-аута в публичном API. Используйте текущую документацию API для получения точных значений и контракта ответа, а не предполагайте стандартное время завершения. Тайм-аут на стороне клиента может оставить неопределенность относительно того, завершил ли сервер вызов, поэтому контроллер должен записывать эту неопределенность отдельно от завершенного результата. Для синхронного мультизапроса продукт документирует, что тайм-аут мультизапроса приводит к сбою всего запроса без частичных результатов. Не создавайте успешные результаты на уровне строк из неполного ответа.
Каждая аренда слота в очереди нуждается в пути освобождения, даже если исполнитель приложения аварийно завершил работу. Контроллер клиента может пометить задание как неопределенное, освободить локальную емкость, как только станет известно, что исполнитель неактивен, и передать запрос на проверку или тщательно контролируемую политику повторных попыток. Не перегружайте службу автоматическими повторными попытками после сетевого инцидента. Если выбрана повторная попытка, сохраните исходную ссылку на задание приложения и отличите последующее наблюдение от предыдущей неопределенной попытки.
Завершенная проверка может содержать пустые поля оператора и оставаться завершенным, тарифицируемым результатом. Это не является тайм-аутом и не должно приводить к повторной попытке только ради получения непустого значения оператора. И наоборот, отклоненный формат ввода не является результатом «оператор не найден». Очередь записывает состояние запроса; она не интерпретирует значение проверки.
Мониторинг очереди без выдумывания лимитов скорости
Полезные метрики на стороне клиента включают текущее количество выполняемых одиночных запросов, активность мультизапроса, возраст запросов в очереди по классам заданий, завершенные ответы, отклонения по формату, тайм-ауты и неопределенные результаты передачи. Они показывают, соблюдает ли приложение правила параллелизма и ожидают ли пользователи ответа от контролируемого клиентом исполнителя. Они не подразумевают фиксированного количества запросов в минуту или дневной квоты, о которых не говорится в публичных фактах.
Перед запуском протестируйте одновременную отправку двумя веб-воркерами, постановку в очередь мультизапроса при активных одиночных запросах, завершение работы воркера до получения ответа и тайм-аут. Убедитесь, что для учетной записи активен не более чем один мультизапрос и что все полученные локальные шлюзы в конечном итоге освобождаются. Проверьте, что результат сопоставлен с отправленным каноническим номером и что упорядоченные строки мультизапроса согласованы перед обновлением записей контактов.
В заключительном примечании следует пояснить, что возвращаемый оператор описывает исходное распределение. Быстрой очереди все равно требуется точная метка для исходного распределения оператора. Сохраняйте ее с источником и временем проверки, держите регион и город распределения отдельно от местоположения человека и используйте другие доказательства для вопросов о возможности контакта или идентификации.
Часто задаваемые вопросы
Как командам координировать несколько исполнителей, использующих одну учетную запись CarrierLookup?
Используйте контроллер уровня учетной записи, общий для всех исполнителей, с общим шлюзом емкости для запросов в реальном времени и эксклюзивным шлюзом для синхронных мультизапросов.
Создает ли документированное правило параллелизма квоту в минуту?
Нет. Оно ограничивает количество одновременных запросов и не устанавливает фиксированное число запросов в минуту.
Может ли мультизапрос с тайм-аутом быть принят частично?
Документированный тайм-аут мультизапроса приводит к сбою всего запроса без частичных результатов. Относитесь к этому как к сбою на уровне запроса и не создавайте успешные строки искусственно.
Должны ли пустые поля оператора вызывать автоматическую повторную попытку?
Сами по себе — нет. Завершенная проверка с пустыми полями распределения остается завершенным результатом; команда должна точно сохранять этот исход.
Узнайте больше
Выберите информацию о продукте, соответствующую следующему шагу вашего рабочего процесса.