Каково правильное решение для службы авторизации с высокой доступностью?

Question

Я работаю в магазине программного обеспечения, у которого есть собственный продукт predictive dialer, и нам нужно внедрить решение для соблюдения списков НЕЖЕЛАТЕЛЬНЫХ ЗВОНКОВ.

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

Хранилище телефонных номеров для программы предиктивного набора представляет собой базу данных PostgreSQL.Программа интеллектуального набора выбирает набор номеров из базы данных и отправляет команду на УАТС для набора набора, а затем бизнес-логика переходит к передаче действительных вызовов сотрудникам колл-центра и т.д. (Это не имеет значения, поскольку моя проблема возникает до вызова).

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

Моей первой мыслью реализовать это было выполнить пакетную обработку, сопоставив СПИСОК "НЕ ЗВОНИТЬ" с моей текущей базой данных клиентов.Но я думаю, что, в зависимости от размера обеих баз данных, создание перекрестных ссылок потребовало бы очень больших затрат производительности и иногда не могло быть завершено в одночасье.У меня и раньше были такого рода проблемы с пакетной обработкой, и это не очень приятно видеть.

Моя вторая идея возникла, когда я подумал о том, как крупные учреждения управляют высокопроизводительными системами авторизации с высокой пропускной способностью, такими как кредитная карта или аутентификация / авторизация пользователя.Я подумал, что было бы неплохо создать службу аутентификации для номеров из СПИСКА "НЕ ЗВОНИТЬ" и изменить алгоритм моего средства предиктивного набора, чтобы проверять каждый номер на соответствие этой службе авторизации перед набором.

Поскольку я здесь всего лишь рассуждаю, я понятия не имею, какая идея лучше, или я понял ее совершенно неправильно и должен искать другое направление.Итак, мой вопрос заключается в следующем:какова была бы ваша рекомендация?Сохранить CSV-файл "НЕ ВЫЗЫВАТЬ" в памяти?использовать LDAP?используете MySQL?PostgreSQL?Занимаетесь пакетной обработкой?Или я определенно облажался?

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

Answer 1

Ваша задача - найти несколько записей из огромного количества возможных записей - напоминает мне о Черные / блокирующие списки DNS.

рблднсд это небольшой и быстрый DNS демон, который специально создан для обслуживания зон DNSBL.Этот демон был вдохновлен Дэном Дж.rbldns от Bernstein программа, найденная в пакете djbdns. Больше rbldnsd от Google

Он поддерживает зоны на основе имен, поэтому вы можете преобразовать список номеров в URI в стиле перечисления - например, +1-555-4242 становится 2.4.2.4.5.5.5.1.e164.arpa.Затем это заносится в файл данных rbldnsd, компилируется в память и к нему осуществляется доступ, как к любому другому списку блокировки.Запись по умолчанию означает can-call, или, если запись существует, ей будет присвоена запись DoNotCall.

Однако у вас все еще есть проблема с пакетным преобразованием, хотя это был бы несколько более простой скрипт, который вполне можно было бы выполнить с помощью Perl или AWK.Вы также можете разделить входящие CSV-файлы на несколько файлов для параллельной обработки и окончательного объединения.