Задача: есть множество процессов на разных машинах, между которыми гуляют некоторые сообщениями через очередь с множественным доступом как на запись, так и на чтение. У всех их общая реляционная база данных. Предоставить другие средства для обмена в силу специфики задачи проблематично. Нужно обеспечить гарантированную безопасность при обмене сообщениями и чтоб при этом параллельность обработке не сводилась на нет. Видимые варианты решения:

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

2) Смена статуса + таймаут + оптимистичная автономная блокировка (последнее нужно на случай, если процесс по каким-то причинам не укладывается в отведённый заведомо большой таймаут). Всё замечательно с точки зрения гарантии ничего не потерять и изоляции. Но относительно сложно в реализации: легко где-нибудь ошибиться и сложно обеспечить полноценное тестирование.

Есть ещё какие-нибудь идеи?

P.S. Я знаю, что RDBMS не предназначены для использования в качестве очередей, но внешние условия такие.

Предоставить другие средства для обмена в силу специфики задачи проблематично.

Это жесткое ограничение, или всё же возможны варианты? Например, rabbit-mq как сервер и amqplib как клиент?

Или постановка звучит наиболее строго “есть сервер СУБД, более никаких серверов, есть py-клиенты, сделать py-клиентам очередь”.

Что имеется ввиду - под безопасностью?

j2a
Это жесткое ограничение, или всё же возможны варианты? Например, rabbit-mq как сервер и amqplib как клиент?

Или постановка звучит наиболее строго “есть сервер СУБД, более никаких серверов, есть py-клиенты, сделать py-клиентам очередь”.

Не очень жёсткое, но:
1) дополнительные средства нужно изучать, обслуживать, обеспечивать отказоустойчивость (выход любого сервера не должен влиять на работоспособность системы).
2) очередь нужно иметь возможность мониторить и управлять ей вручную, что достаточно просто в случае с RDBMS.
В таких условиях даже сложное решение на базе RDBMS оказывается лучше, чем дополнительные средства.

shiza
Что имеется ввиду - под безопасностью?

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

Пока идей в голову не приходит.

ods
2) Смена статуса + таймаут + оптимистичная автономная блокировка (последнее нужно на случай, если процесс по каким-то причинам не укладывается в отведённый заведомо большой таймаут). Всё замечательно с точки зрения гарантии ничего не потерять и изоляции. Но относительно сложно в реализации: легко где-нибудь ошибиться и сложно обеспечить полноценное тестирование.

Но этот вариант - на первый взгляд выглядит IMHO совсем не сложно (я сужу по самому простому варианту, так как конечно не знаю - какая нужна функциональность)

БД тут конечно здорово поможет.
Транзакции - для сбоя в траснпорте.
Кластер в миррор - на случай если сервер откажет.
Только наверное нужен какой-то cron (зависит от СУБД) чтоб таймауты отслеживать - перекладывать на клиентов такое конечно не стоит.

Можно тестировать в лоб (не интрепрайз уровень конечно… но…) - сделать кучу рандомных клиентов с рандомными параметрами и гонять… гонять….

А если весь функционал на БД-шных процедурах сделать, то размазни не будет, и вообще красота =)

shiza
Но этот вариант - на первый взгляд выглядит IMHO совсем не сложно (я сужу по самому простому варианту, так как конечно не знаю - какая нужна функциональность)

Автономная блокировка - это длинная транзакция, что всегда плохо: нужно быть очень внимательным, чтобы не убить параллельность и не наделать dead-lock'ов.

shiza
Можно тестировать в лоб (не интрепрайз уровень конечно… но…) - сделать кучу рандомных клиентов с рандомными параметрами и гонять… гонять….

Ага, на нескольких машинках с time clash… Я бы назвал это нереальным. Создать test case на race condition не так просто. Я уж не говорю о том, чтобы такой test suite гонять после каждого изменения кода, всегда помня, что нет никакой гарантии, что он ошибку отловит.

Ну… в составных системах (параллельных) - вообще невозможно все оттестировать в идеале. Больше думаешь и гоняешь - вероятность ошибок меньше =)

А над оптимистической автономной блокировкой. да… действительно надо подумать…
насколько глубокая проверка?

“если процесс по каким-то причинам не укладывается в отведённый заведомо большой таймаут” - можно немного распространить?

shiza
“если процесс по каким-то причинам не укладывается в отведённый заведомо большой таймаут” - можно немного распространить?

Конечно, можно засечь время обработки сообщения на хорошо загруженной системе и умножить его на 1000. Должно быть достаточно, но всякое бывает:
- процесс завис на длительное время по каким-то причинам (долго тормозят какие-то внешние ресурсы или ожидается снятие блокировки на нужные данные в базе, процессы занимаются переделом свопа вместо нормальной работы и т.п.)
- банальный time clash (от него, конечно же, будет отдельная защита).
Здесь действует принцип: если что-то может случиться, то оно обязательно случится. Посему всё должно работать в любой ситуации, даже в случае ошибок в коде ;). И уж точно никакие данные ни при каких обстоятельствах не должны быть потеряны.