Добрый вечер.

Посоветуйте, пожалуйста, распределенный сервер блокировки.
Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он как-то
старовато выглядит.

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

Требования:
- работает на нескольких машинах, без центральной точки отказа
- обслуживает запросы lock(keys[]) и unlock(keys[])
- если клиент умирает, то unlock() для него производится автоматически

Примечание
Работа без центральной точки отказа очень желательно, ибо, если этого нет,
то можно вообще постгресовыми функциями пользоваться.

Здравствуйте, Dmitry.

memcached или memcachedb с репликацией в зависимости требований по
надёжности наверное может подойти.

> Посоветуйте, пожалуйста, распределенный сервер блокировки.
> Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он как-то старовато выглядит.

> Задача - синхронизация между собой демонов на нескольких машинах,
> обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не
> могли захватить одновременно больше одного демона.

> Требования:
> - работает на нескольких машинах, без центральной точки отказа
> - обслуживает запросы lock(keys[]) и unlock(keys[])
> - если клиент умирает, то unlock() для него производится автоматически

> Примечание
> Работа без центральной точки отказа очень желательно, ибо, если
> этого нет, то можно вообще постгресовыми функциями пользоваться.



--
С уважением,
Michael mailto:softsearch@gmail.com

Gearman

2 февраля 2010 г. 22:37 пользователь Michael Monashev
<softsearch@gmail.com>написал:

> Здравствуйте, Dmitry.
>
> memcached или memcachedb с репликацией в зависимости требований по
> надёжности наверное может подойти.
>
> > Посоветуйте, пожалуйста, распределенный сервер блокировки.
> > Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он
> как-то старовато выглядит.
>
> > Задача - синхронизация между собой демонов на нескольких машинах,
> > обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не
> > могли захватить одновременно больше одного демона.
>
> > Требования:
> > - работает на нескольких машинах, без центральной точки отказа
> > - обслуживает запросы lock(keys[]) и unlock(keys[])
> > - если клиент умирает, то unlock() для него производится автоматически
>
> > Примечание
> > Работа без центральной точки отказа очень желательно, ибо, если
> > этого нет, то можно вообще постгресовыми функциями пользоваться.
>
>
>
> --
> С уважением,
> Michael mailto:softsearch@gmail.com
>
>


--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com

может быть вот это подойдет
http://www.terracotta.orghttp://www.terracotta.org/products
?

2010/2/2 Michael Monashev <softsearch@gmail.com>

> Здравствуйте, Dmitry.
>
> memcached или memcachedb с репликацией в зависимости требований по
> надёжности наверное может подойти.
>
> > Посоветуйте, пожалуйста, распределенный сервер блокировки.
> > Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он
> как-то старовато выглядит.
>
> > Задача - синхронизация между собой демонов на нескольких машинах,
> > обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не
> > могли захватить одновременно больше одного демона.
>
> > Требования:
> > - работает на нескольких машинах, без центральной точки отказа
> > - обслуживает запросы lock(keys[]) и unlock(keys[])
> > - если клиент умирает, то unlock() для него производится автоматически
>
> > Примечание
> > Работа без центральной точки отказа очень желательно, ибо, если
> > этого нет, то можно вообще постгресовыми функциями пользоваться.
>
>
>
> --
> С уважением,
> Michael mailto:softsearch@gmail.com
>
>

http://sector.sourceforge.net/

2010/2/2 Александр Лозовюк <aleks.raiden@gmail.com>

> Gearman
>
> 2 февраля 2010 г. 22:37 пользователь Michael Monashev <
> softsearch@gmail.com> написал:
>
> Здравствуйте, Dmitry.
>>
>> memcached или memcachedb с репликацией в зависимости требований по
>> надёжности наверное может подойти.
>>
>> > Посоветуйте, пожалуйста, распределенный сервер блокировки.
>> > Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он
>> как-то старовато выглядит.
>>
>> > Задача - синхронизация между собой демонов на нескольких машинах,
>> > обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не
>> > могли захватить одновременно больше одного демона.
>>
>> > Требования:
>> > - работает на нескольких машинах, без центральной точки отказа
>> > - обслуживает запросы lock(keys[]) и unlock(keys[])
>> > - если клиент умирает, то unlock() для него производится автоматически
>>
>> > Примечание
>> > Работа без центральной точки отказа очень желательно, ибо, если
>> > этого нет, то можно вообще постгресовыми функциями пользоваться.
>>
>>
>>
>> --
>> С уважением,
>> Michael mailto:softsearch@gmail.com
>>
>>
>
>
> --
> C уважением, Александр Лозовюк
> Alpha-Beta-Release Blog
> http://abrdev.com
>

On 02/03/10 00:02, Khazret Sapenov wrote:
> http://sector.sourceforge.net/

жалко что уже есть, а то я подумал, может стоит такую штуку написать,
раз людям нужно....

мы кладем в очередь memcacheq задание на исполнение,
первый из освободившихся демонов забирает на исполнение
работает без сбоев и проблем.


>
> Посоветуйте, пожалуйста, распределенный сервер блокировки.
> Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он как-то
> старовато выглядит.
>
> Задача - синхронизация между собой демонов на нескольких машинах,
> обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не могли
> захватить одновременно больше одного демона.
>
> Требования:
> - работает на нескольких машинах, без центральной точки отказа
> - обслуживает запросы lock(keys[]) и unlock(keys[])
> - если клиент умирает, то unlock() для него производится автоматически
>
> Примечание
> Работа без центральной точки отказа очень желательно, ибо, если этого нет,
> то можно вообще постгресовыми функциями пользоваться.
>

Но ведь есть условие "... без центральной точки отказа".
Что случится, если сервер memcacheq с конкретным сообщением скоропостижно
вывалился, не успев отдать его на исполнение? Как реализовано high
availability/ store redundancy?

2010/2/3 Alexandre Kalendarev <akalend@mail.ru>

> мы кладем в очередь memcacheq задание на исполнение,
> первый из освободившихся демонов забирает на исполнение
> работает без сбоев и проблем.
>
>
> >
> > Посоветуйте, пожалуйста, распределенный сервер блокировки.
> > Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он
> как-то
> > старовато выглядит.
> >
> > Задача - синхронизация между собой демонов на нескольких машинах,
> > обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не могли
> > захватить одновременно больше одного демона.
> >
> > Требования:
> > - работает на нескольких машинах, без центральной точки отказа
> > - обслуживает запросы lock(keys[]) и unlock(keys[])
> > - если клиент умирает, то unlock() для него производится автоматически
> >
> > Примечание
> > Работа без центральной точки отказа очень желательно, ибо, если этого
> нет,
> > то можно вообще постгресовыми функциями пользоваться.
> >
>

memcacheq вполне масштабируемое решение

Спасибо за ответы.

Gearman
> http://www.terracotta.org
> http://sector.sourceforge.net/
> memcacheq
>

Ознакомился. Такое ощущение, что это не совсем то... Нужен именно сервер
блокировок, у которого есть 2 функции: lock(key1, key2, ..., keyN) и
unlock(key1, key2, ..., keyN), плюс - автоматический unlock(), если
соединение с клиентом неожиданно умирает. С очередью задач проблем нет (сами
задачи являются частью уже шарденной БД, в моем случае нет смысла их в виде
отдельных элементов куда-то еще "впрыскивать", хотя я понимаю, что иногда
"впрыск" оказывается удобен в других приложениях).




2010/2/3 Alexandre Kalendarev <akalend@mail.ru>

> memcacheq вполне масштабируемое решение
>

On 05.02.10 2:14, Dmitry Koterov wrote:
> Спасибо за ответы.
>
> Gearman
> http://www.terracotta.org
> http://sector.sourceforge.net/
> memcacheq
>
>
> Ознакомился. Такое ощущение, что это не совсем то... Нужен именно
> сервер блокировок, у которого есть 2 функции: lock(key1, key2, ...,
> keyN) и unlock(key1, key2, ..., keyN), плюс - автоматический unlock(),
> если соединение с клиентом неожиданно умирает. С очередью задач
> проблем нет (сами задачи являются частью уже шарденной БД, в моем
> случае нет смысла их в виде отдельных элементов куда-то еще
> "впрыскивать", хотя я понимаю, что иногда "впрыск" оказывается удобен
> в других приложениях).
>
>

http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock


>
>
> 2010/2/3 Alexandre Kalendarev <akalend@mail.ru <mailto:akalend@mail.ru>>
>
> memcacheq вполне масштабируемое решение
>
>

> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock

думаю это немножко не то.
даи и лочить что-то в БД - это издевательство над hiload

On 10.02.10 17:41, Alexandre Kalendarev wrote:
>
>> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
>> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock
>>
> думаю это немножко не то.
> даи и лочить что-то в БД - это издевательство над hiload
>
>
>
У нас сейчас так работает.
В пики нагрузка на mysql ~1100, из них 100-120 запросов на блокировку.
Если было бы какое-то легкое и простое альтернативное решение для PHP,
то использовали бы его.
Но пока ничего не нашли. :)

а локи через шаред мемори или APC?

10 февраля 2010 г. 19:31 пользователь Konstantin Belov
<belov1985@gmail.com>написал:

> On 10.02.10 17:41, Alexandre Kalendarev wrote:
> >
> >>
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
> >>
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock
> >>
> > думаю это немножко не то.
> > даи и лочить что-то в БД - это издевательство над hiload
> >
> >
> >
> У нас сейчас так работает.
> В пики нагрузка на mysql ~1100, из них 100-120 запросов на блокировку.
> Если было бы какое-то легкое и простое альтернативное решение для PHP,
> то использовали бы его.
> Но пока ничего не нашли. :)
>



--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com

On 10.02.10 20:03, Александр Лозовюк wrote:
> а локи через шаред мемори или APC?
>
как вы себе это представляете на нескольких серверах? :)

> 10 февраля 2010 г. 19:31 пользователь Konstantin Belov
> <belov1985@gmail.com <mailto:belov1985@gmail.com>> написал:
>
> On 10.02.10 17:41, Alexandre Kalendarev wrote:
> >
> >>
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
> >>
> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock
> >>
> > думаю это немножко не то.
> > даи и лочить что-то в БД - это издевательство над hiload
> >
> >
> >
> У нас сейчас так работает.
> В пики нагрузка на mysql ~1100, из них 100-120 запросов на блокировку.
> Если было бы какое-то легкое и простое альтернативное решение для PHP,
> то использовали бы его.
> Но пока ничего не нашли. :)
>
>
>
>
> --
> C уважением, Александр Лозовюк
> Alpha-Beta-Release Blog
> http://abrdev.com

да точно :) сразу видно, что не выспался :)

10 февраля 2010 г. 22:35 пользователь Konstantin Belov
<belov1985@gmail.com>написал:

> On 10.02.10 20:03, Александр Лозовюк wrote:
>
> а локи через шаред мемори или APC?
>
> как вы себе это представляете на нескольких серверах? :)
>
>
> 10 февраля 2010 г. 19:31 пользователь Konstantin Belov <
> belov1985@gmail.com> написал:
>
>> On 10.02.10 17:41, Alexandre Kalendarev wrote:
>> >
>> >>
>> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
>> >>
>> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock
>> >>
>> > думаю это немножко не то.
>> > даи и лочить что-то в БД - это издевательство над hiload
>> >
>> >
>> >
>> У нас сейчас так работает.
>> В пики нагрузка на mysql ~1100, из них 100-120 запросов на блокировку.
>> Если было бы какое-то легкое и простое альтернативное решение для PHP,
>> то использовали бы его.
>> Но пока ничего не нашли. :)
>>
>
>
>
> --
> C уважением, Александр Лозовюк
> Alpha-Beta-Release Blog
> http://abrdev.com
>
>
>


--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com

2010/2/10 Alexandre Kalendarev <akalend@mail.ru>:
>
>> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock
>> http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_release-lock
>
> думаю это немножко не то.
> даи и лочить что-то в БД - это издевательство над hiload
>

почему издевательство
когда выйдет мыскль с либевентом - ваще вопрос отпадёт.
но с единой точкой отказа, да.
по-моему важность проблемы единой точки отказа в подавляющем
количистве веб-проектов сильно преувеличена ;)

--

wbr,
fisher

> когда выйдет мыскль с либевентом - ваще вопрос отпадёт.
MariaDB уже умеет libevent

On 02.02.10 21:36, Dmitry Koterov wrote:
> Добрый вечер.
>
> Посоветуйте, пожалуйста, распределенный сервер блокировки.
> Я нашел пока только OpenDLM: http://opendlm.sourceforge.net/ - но он
> как-то старовато выглядит.
>
> Задача - синхронизация между собой демонов на нескольких машинах,
> обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не
> могли захватить одновременно больше одного демона.
>
> Требования:
> - работает на нескольких машинах, без центральной точки отказа
> - обслуживает запросы lock(keys[]) и unlock(keys[])
> - если клиент умирает, то unlock() для него производится автоматически
>
> Примечание
> Работа без центральной точки отказа очень желательно, ибо, если этого
> нет, то можно вообще постгресовыми функциями пользоваться.

Вот еще парочка:
http://hadoop.apache.org/zookeeper/
http://danga.com/gearman/

Но опять же, если использовать только для блокировок, то очень
громоздкое решение получается :(

> http://danga.com/gearman/

про gearman говорили - это ведь фреймворк для распределенных систем
обработки очередей, а где там блокировки?


--

wbr,
fisher

какой он фреймворк то? это распределенный сервер очередей работ. если
принять что работа (job) это лок, тогда можно сделать.

11 февраля 2010 г. 14:57 пользователь Alexey A. Rybak <
alexey.rybak@gmail.com> написал:

> > http://danga.com/gearman/
>
> про gearman говорили - это ведь фреймворк для распределенных систем
> обработки очередей, а где там блокировки?
>
>
> --
>
> wbr,
> fisher
>



--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com

2010/2/11 Александр Лозовюк <aleks.raiden@gmail.com>:
> если принять что работа (job) это лок, тогда можно сделать.

это как интересно?

--

wbr,
fisher

On 02/10/2010 08:31 PM, Konstantin Belov wrote:
> Если было бы какое-то легкое и простое альтернативное решение для PHP,
> то использовали бы его.
> Но пока ничего не нашли. :)

http://gearman.org ?

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

Может elock? http://github.com/dustin/elock

On 2 фев, 23:36, Dmitry Koterov <dmi...@koterov.ru> wrote:
> Добрый вечер.
>
> Посоветуйте, пожалуйста, распределенный сервер блокировки.
> Я нашел пока только OpenDLM:http://opendlm.sourceforge.net/- но он как-то
> старовато выглядит.
>
> Задача - синхронизация между собой демонов на нескольких машинах,
> обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не могли
> захватить одновременно больше одного демона.
>
> Требования:
> - работает на нескольких машинах, без центральной точки отказа
> - обслуживает запросы lock(keys[]) и unlock(keys[])
> - если клиент умирает, то unlock() для него производится автоматически
>
> Примечание
> Работа без центральной точки отказа очень желательно, ибо, если этого нет,
> то можно вообще постгресовыми функциями пользоваться.

On 13.02.10 20:05, alekciy wrote:
> Может elock? http://github.com/dustin/elock
>
>
Хорошая замена MySQL блокировкам.
Смущает только то, что он написан на erlang, на сколько быстро работает?

> On 2 фев, 23:36, Dmitry Koterov <dmi...@koterov.ru> wrote:
>
>> Добрый вечер.
>>
>> Посоветуйте, пожалуйста, распределенный сервер блокировки.
>> Я нашел пока только OpenDLM:http://opendlm.sourceforge.net/- но он как-то
>> старовато выглядит.
>>
>> Задача - синхронизация между собой демонов на нескольких машинах,
>> обрабатывающих единый пул задач, так, чтобы одну и ту же задачу не могли
>> захватить одновременно больше одного демона.
>>
>> Требования:
>> - работает на нескольких машинах, без центральной точки отказа
>> - обслуживает запросы lock(keys[]) и unlock(keys[])
>> - если клиент умирает, то unlock() для него производится автоматически
>>
>> Примечание
>> Работа без центральной точки отказа очень желательно, ибо, если этого нет,
>> то можно вообще постгресовыми функциями пользоваться.

У меня текст нечитаемый.

On 16 фев, 15:41, Konstantin Belov <belov1...@gmail.com> wrote:
> On 13.02.10 20:05, alekciy wrote:> elock?http://github.com/dustin/elock
>
> MySQL .
> , erlang, ?
>
>
>
> > On 2 , 23:36, Dmitry Koterov <dmi...@koterov.ru> wrote:
>
> >> .
>
> >> , , .
> >> OpenDLM:http://opendlm.sourceforge.net/--
> >> .
>
> >> - ,
> >> , ,
> >> .
>
> >> :
> >> - ,
> >> - lock(keys[]) unlock(keys[])
> >> - , unlock()
>
> >>
> >> , , ,
> >> .