Параллельный выбор данных из таблицы

Тема в разделе "SQL", создана пользователем -, 23 июл 2005.

Статус темы:
Закрыта.
  1. Гость

    Небольшой 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) во время выбора. Правда, тогда всем остальным

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

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

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

    Barmutik Гость

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

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

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

    Barmutik Гость

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

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

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

    Barmutik Гость

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

Поделиться этой страницей