Небольшой Callcenter. Агенты при помощи клиентской программы получают контактные телефоны.
Само собой разумеется, различным агентам не должны попасть одинаковые телефоны одновремменно. Хорошо.

Выбираем строку из таблицы, запираем ее(id агента в столбец, скажем "lock_agent_id") и говорим этот агент ее выбрал.

Результат разговора сохраняется и телефон больше не выбирается. Тут все нормально.

Но, сам выбор: допустим

BEGIN
SELECT phone_id,name,phone INTO @phone_id,@name,@phone
FROM phones
WHERE lock_agent_id IS NULL.... LIMIT 1 FOR UPDATE;
UPDATE phones SET lock_agent_id=@agent_id WHERE phone_id = @phone_id;
...
RETURN
END

Агенты не получат одновременно один и тот же номер, но если одновременно несколько агентов выбирают из таблицы, то

один из них действительно получает номер, а остальные пустую строку.

Кажется, выход только один,- запереть всю таблицу (LOCK TABLE) во время выбора. Правда, тогда всем остальным

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

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

Может быть кто-то подскажет. Заранее благодарен.

 

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

 

Если я правильно понял - это сервис, который хранит внутри себя, для скорости - в ram'е, какое количество строк, ставит в очередь клиентов и выдает им телефоны. Соответственно принимает результаты, сохраняет их снова только внутри себя, и после, при известном условии(количество необработанных адрессов мало или окончание работы), обновляет базу данных результатами, и выбирает новые данные.

Мне кажется, что реализация довольно таки сложная. Но выглядит очень здорово.

 

В принципе она конечно сложнее чем просто обращения к серверу баз данных. Но ничего архи сложного там нет...

Но такая схема точно работает .. потому как реализована в существующем работающем (большом) Call center-е

 

Я соглашусь. Но мне, к сожалению, приходится думать и о том, сколько программа стоит, и сколь часов уйдет на ее реализацию. Тот, кто отдает за, к примеру, автомобиль 1000 долларов, не ждет от нее комфортности и надежности нового Мерседеса.
Как я написал, callcenter не очень большой, максимум 30 агентов. Думаю, что все же решусь писать и читать напрямую через базу. Небольшую программу для тестирования и поглядеть на результаты.
А за совет спасибо, думаю, что в дальнейшем, если появится необходимость в больших мощностях, именно так и нужно будет попробовать.
Если можно, вопрос: сколько агентов работает в callcenter, который был упомянут?

 

Проектная мощность до 1000... максимальное на текущее время одновременно работающих не более 100...