01.08.2009, 14:27 | #11 | |
Мне повезёт!
Регистрация: 05.05.2007
Сообщений: 1,076
Вес репутации: 276
|
Последний Герой, пожалуй да. У вас, в общем-то, грамотно описано, я лишь хочу сказать, что можно сделать идеологически то же самое, но проще:
Из мануала: Цитата:
Код:
UPDATE `table` SET `handler`=<идентификатор текущего процесса> WHERE `handler` is NULL AND `is_processed` = 0 LIMIT 1 А если нет разницы, то зачем платить больше! ;-)
__________________
If it's not great, it's not the end. |
|
01.08.2009, 14:42 | #12 | |
Магистр
Регистрация: 04.12.2007
Сообщений: 3,680
Вес репутации: 416
|
Цитата:
__________________
|
|
01.08.2009, 14:47 | #13 |
Bannеd
Регистрация: 17.09.2008
Сообщений: 6,446
Вес репутации: 369
|
не прав. как только один поставил, второй уже не может поставить, ибо
но тут вопрос, какому из них удалось поставить. ответ: |
01.08.2009, 14:48 | #14 | |
Магистр
Регистрация: 04.12.2007
Сообщений: 3,680
Вес репутации: 416
|
Цитата:
Насчет строкового поля- не-не-не. Таблица- миллион строк. тяжелых. Я буду писать туда текст и еще потом искать по нему? Не. Смерть.. Последний Герой, InnoDB не катит, ибо у транзакционных тейблов производительность на порядок ниже MyISAMовских. Вариант с тем, чтоп лочить всю тейблу - тоже вариант, но только до тех пор пока обработчиков мало. А станет много- начнется сплошная битва. Матрица, блин Склоняюсь к идее со схемой предиктор-корректор- когда добавлятор добавляет строки в тейблу с же прописанным признаком обработчика, а обработчик будет давать обратную связь о скорости своей работы- тада добавлятор будет равномерно раскидывать строки в зависимости от скоростей обработчиков. Типа идеально. Однако, как и обработчиков, добавляторов - несколько. И они равноправны. Отсюда рождается диспетчер. Типа никак не получается создать саморегулирующуюся децентрализованную структуру
__________________
|
|
01.08.2009, 14:52 | #15 |
Bannеd
Регистрация: 17.09.2008
Сообщений: 6,446
Вес репутации: 369
|
|
01.08.2009, 14:54 | #16 | |
Магистр
Регистрация: 04.12.2007
Сообщений: 3,680
Вес репутации: 416
|
Цитата:
есть два обработчика О1 и О2. Оба нашли свободную строчку- и ломятся ее сначала зарезервировать (тоесть как раз UPDATE SET столбец=айди WHERE столбец=0 ) а потом сделать контрольный Селект, так? Может получится, что О1 и О2 делают апдейт. Естессно- ктото успевает первым (пусть О1). Второй апдейт ждет. О1 сделал апдейт и делает селект (селект не ждет) - считывает свое только что установленное значение и свято верит что строчка им залочена. После этого доходит очередь до апдейта О2 и последующего егоже селекта. В результате оба верят что строчка залочена именно им. Тут играет роль приоритетность селекта и апдейта. В принципе это в mysql настраивается, но все равно выглядит это както хлипко.. Добавлено через 1 минуту угу.. ну это естессн..
__________________
Последний раз редактировалось Йода; 01.08.2009 в 14:54. Причина: Добавлено сообщение |
|
01.08.2009, 15:03 | #17 |
Bannеd
Регистрация: 17.09.2008
Сообщений: 6,446
Вес репутации: 369
|
он не может сделать апдейт, ибо в условии стоит WHERE столбец=0, а там уже вместо 0 число айди стоит. запрос UPDATE ... WHERE ... всегда выполняется монопольно.
ну да, раз оно установлено, оно не изменится, пока он его сам не обнулит |
01.08.2009, 16:38 | #19 |
Мне повезёт!
Регистрация: 05.05.2007
Сообщений: 1,076
Вес репутации: 276
|
Йода, хорошо, развиваем мысль.
Значит задача - сделать децентрализованную систему. И, желательно, простую (да, люблю я простоту. Считаю что все гениальное - просто). Делаем MEMORY таблицу с одним единственным AUTO_INCREMENT полем (хранится в памяти, на 1 запись тратится длина, равная sizeof(int), выборки и вставки ультра быстрые). Обработчик при своем запуске делает в нее INSERT, и забирает свой идентификатор через LAST_INSERT_ID(). Таким образом, мы получаем уникальные непересекающиеся числовые идентификаторы для каждого процесса, которые не будут сохраняться на диск. В памяти это будет занимать намного меньше места, чем любой диспетчер, ибо диспетчеру все равно надо хранить список обработчиков.
__________________
If it's not great, it's not the end. |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Помогите решить проблему . | Jenya | Курилка | 7 | 04.01.2009 11:27 |
Помогите решить проблему с MSN | Chervechok | Курилка | 2 | 12.12.2008 02:26 |
Помогите решить проблему! | yan21 | Яндекс | 3 | 20.11.2008 13:08 |
помогите решить проблему | ncx | Курилка | 24 | 04.08.2008 20:01 |
Помогите решить проблемы | ara | Вопросы по работе системы | 5 | 30.04.2007 22:45 |
Часовой пояс GMT +3, время: 00:09.