Технология для надежного, постоянного стека

Question

Попытка умственного сброса здесь: я пытался создать надежный, постоянный стек с MSMQ, не работал

Итак, в более общих чертах:

У меня есть производитель (веб-служба,так что многопоточный, хотя "только один") / потребитель (несколько процессов, столько, сколько нужно) настройки.Ключевыми проблемами являются - Данные должны потребляться / обрабатываться в порядке LIFO (~> стек) - Данные должны храниться / обрабатываться надежным способом (т. Е. Поддерживаются диском, очередью сообщений и т. Д.).Бонусные баллы за сопровождение транзакции.- Вовлечено межпроцессное взаимодействие

Учитывая вышеприведенные вопросы, я изо всех сил пытаюсь найти правильное решение.То, на что я смотрел:

1. Сделай сам Сам не собирался этого делать, но первоначальное подтверждение концепции этого просто подтвердило, что это сложно (для меня) и помогло мнелучшее понимание множества препятствий.

2. MSMQ Было бы неплохо и просто, поскольку он легко поддается «надежному», легко настраивается и уже является частью целевой инфраструктуры.,К сожалению, "LIFO" / "Stack" здесь убийца.Это, кажется, невозможно сделать -> Bzzzt.

3. База данных (SQL Server) Я попытался взглянуть на подход, основанный на БД, но в нем есть много уродливых вещей:

   • Мне нужно было бы хранить мои данные в виде большого двоичного объекта (поскольку он не легко поддается хранилищу на основе столбцов)
   • Опрос базы данных для работы просто кажется неправильным (не так ли?)
   • Блокировка с несколькими потребителями кажется сложной задачей ..

Есть какие-нибудь предложения по технологии, которые я должен оценить?Подход, основанный на базе данных, кажется наиболее «многообещающим» до сих пор, но я до сих пор не нашел хороших примеров / историй успеха подобных примеров использования.

---

Обновления

• Только для Windows
• На данный момент мне даже не нужно устанавливать межмашинное взаимодействие (т. Е. Производитель / потребитель, вероятно, будет пока находиться на одной машине)
• ключевая часть в вопросе, трудная задача для меня: я не могу потерять работу / сообщение, даже если все процессы прекращаются.БД дала бы мне, что "бесплатно", очереди сообщений могут быть установлены, чтобы быть надежными.Сопоставление / уменьшение, хотя и интересно, не решает основной проблемы: как мне убедиться, что сообщения / задания не потеряны?

Answer 1

Я бы пошел с SQL Server для этого.

1. Очевидно, что вам придется сериализовать ваши данные в большой двоичный объект, но любое решение должно будет сделать это (по крайней мере, позадисцены).Тогда у вас будет просто таблица типа CREATE TABLE Stack (Id int identity, Data varbinary(MAX))

2. Опрос базы данных не требуется.В SQL Server есть служба уведомлений о запросах, в которой вы просто отправляете запрос, и он будет уведомлять вас, когда результаты будут другими.Ваш запрос на уведомление будет просто SELECT * FROM Stack

3. Блокировка - это проблема базы данных, а не ваша.Вы бы просто заставили каждого потребителя выполнить запрос (или хранимую процедуру), который использует транзакцию, чтобы вернуть самую последнюю запись (строку с самым высоким Id) и одновременно удалить ее.Если запрос возвращает результат, обработайте его и запустите снова.Если запрос не возвращает результатов, см. # 2.

Вот пример запроса:

BEGIN TRANSACTION
SELECT Data FROM Stack WHERE Id = (SELECT MAX(Id) FROM Stack)
DELETE FROM Stack WHERE Id = (SELECT MAX(Id) FROM Stack)
COMMIT

Вот более элегантная версия, которая даже не требует явноготранзакция:

DELETE Stack
OUTPUT DELETED.Data
WHERE Id = (SELECT MAX(Id) FROM Stack)

Если вы хотите выполнять пакетную обработку 10 элементов одновременно, вы должны использовать SQL следующим образом:

DELETE Stack
OUTPUT DELETED.*
WHERE Id IN (SELECT TOP 10 Id FROM Stack ORDER BY Id DESC)

Answer 2

MapReduce звучит идеально для этого и может быть очень масштабируемым, поскольку это то, что Google использует для индексации веб-страниц.Не уверен, какой у вас предпочтительный стек, но вы можете попробовать Hadoop

Answer 3

Если вы идете по маршруту БД, вы можете посмотреть на Триггеры.Это зависит от того, насколько редки ваши сообщения и как долго вы можете ждать их обработки.

Answer 4

Что касается пункта 3, вы можете посмотреть на this с помощью фанатика SO Джона Скита, средства сериализации данных в двоичный двоичный объект, который можно легко вывести ...

Что касается межпроцессного взаимодействия - о какой платформе мы говорим здесь, если это окна, обменивающиеся данными с другими машинами Windows, разве WCF не подойдет? Что касается поддержки транзакций - большинство ADO.NET имеет поддержку транзакций (согласно статье MSDN ), если вы не говорите о поддержке транзакций файловой системы согласно этой записи blog или даже не используете Пространство имен System.Transaction, как пояснено здесь в отношении распределенных транзакций.

Answer 5

Вы должны проверить AMQP.Я копаюсь в google atm, и, к сожалению, у меня нет оснований полагать, что он может поддерживать стек вместо очереди, но есть несколько реализаций с открытым исходным кодом, и помимо проблемы FIFO и LIFO, это хорошо подходит для того,хочу.

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