Есть что-то вроде сервиса приложения (с++), или хост — процесса, подгружающего модули, которые образуют подобие акторной модели взаимодействия
в рамках одного процесса. Обмениваемые данные изначально поступают из внешней среды, например сеть, клиентом которой является каждый из модулей.
Дальнейший межмодульный транзит определен маршртизацией в зависимости от типа сообщения.
Один компонент — отдельный агент-поток со своим неким почтовым ящиком. При разработке системы возникла проблема потери сообщений в ряде случаев.
Это kill -9, отвалилась сеть, модуль нужно перезапустить, аварийное завршение и прочие причины, когда компонент завершит свое исполнние, не разобрав ящик.
Не мог бы кто-то посоветовать, что почитать, какте методики применяются. Какие-то моменты уяснил из документации для akka, но тем не менее. Ситуация усугубляется тем, что при отправке модулем во внешнюю среду сообщения буфферизируются в пачку по N (асинхронность).
У меня лично была мысль такая. Для каждого агента создать что — то вроде mpsc ring buffer на диске, в который отправители сохраняют данные перед передачей в ящик.
Агент при чтении с своего почтового ящика также должен будет вызвать pop() для кольца. Главное только обеспечить одинаковый порядок данных.
При рестарте после внештатной ситуации этот ring buffer разгребается.
Здравствуйте, Sazon, Вы писали:
S>Не мог бы кто-то посоветовать, что почитать, какте методики применяются.
Обычно используются брокеры сообщений (например, rabbitmq). На брокер возложено хранение сообщений, пока оно не будет обработано. Отправители записывают сообщения в очередь, которая хранится на брокере. Агенты-обработчики вытаскивают сообщения из очереди, выполняют полезную работу, удаляют обработанное сообщение.
Я бы сделал хранение очередей сообщений в mmap'ленном файле без синхронизации на диск при изменении очереди. В таком случае после падения приложения, если есть измененные страницы, данные сбросятся на диск ядром ОС. При этом во время чтения/записи очередей в памяти они на диск сразу попадать не будут (нет накладных расходов на регулярную запись данных на диск). Шанс потерять данные есть только в случае, если машина перезагрузится аппаратно (по питанию, например) или если ядро зависнет или диск испортится. При старте нужно будет считывать эти данные (на самом деле, когда сделаешь mmap(), данные сразу окажутся в приложении в том виде, как были записаны). Возможно, нужно будет сделать структуру очереди независящей от адреса в памяти, т.е. база и смещения относительно ее. Также, полезно будет сделать какую-то проверку (типа контрольной суммы или чего-то еще), чтобы убедиться в целостности данных после mmap() на старте. Впрочем, при падении по питанию, например, ты не сможешь распознать, насколько это древняя копия данных, т.к. нет постоянной записи на диск при изменении данных, возможно, на диске данные в состоянии, когда приложение стартануло в предыдущий раз (а затем обработало много сообщений ни разу не сохранив состояние, а потом выключили питание). В общем, такой подход довольно просто решит большинство твоих задач, но не все.
Таким образом, получится и данные сохранять на диск при падении приложения (если ядро ОС и диск работоспособны) и при изменении данных в памяти не будет задействован диск (нулевые накладные расходы или около того). Могут быть нюансы в этой схеме, например, что делать, если модуль стал хранить очередь в другом формате (старый формат придется прочитать или приложение аккуратно остановить, чтобы очереди очистились).
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Sazon, Вы писали:
S>>Не мог бы кто-то посоветовать, что почитать, какте методики применяются.
Б>Обычно используются брокеры сообщений (например, rabbitmq). На брокер возложено хранение сообщений, пока оно не будет обработано. Отправители записывают сообщения в очередь, которая хранится на брокере. Агенты-обработчики вытаскивают сообщения из очереди, выполняют полезную работу, удаляют обработанное сообщение.
Именно он, "кролик", и подразумевается в качестве внешней среды. Частично проблемы можно решить, используя amqp.confirm, amqp.ack и mandatory флаг. Более того rabbitmq применяется при передаче сообщений с модуля одного сервиса приложений на модуль другого сервиса. Однако тут момент, что брокер имеет весьма ограниченную пропрускную способность, поэтому приходится выходные сообщения объединять в "батчи". То есть фактический уход сообщения в внешнюю среду очень "асинхронен", если можно так выразитmся. Еще одна деталь: в рамках одного сервиса приложения на определенном модуле обрабатываемые сообщения могут порождать дргуие, о которых брокер вообще ничего не знает.
Почему все модули не связаны строго через брокер: есть желание экономить на (де)сереализации и оверхэдах самого rabbitmq . Про aeron в курсе, но до этого далеко.
Здравствуйте, Masterspline, Вы писали:
M>Я бы сделал хранение очередей сообщений в mmap'ленном файле без синхронизации на диск при изменении очереди. В таком случае после падения приложения, если есть измененные страницы, данные сбросятся на диск ядром ОС. При этом во время чтения/записи очередей в памяти они на диск сразу попадать не будут (нет накладных расходов на регулярную запись данных на диск). Шанс потерять данные есть только в случае, если машина перезагрузится аппаратно (по питанию, например) или если ядро зависнет или диск испортится. При старте нужно будет считывать эти данные (на самом деле, когда сделаешь mmap(), данные сразу окажутся в приложении в том виде, как были записаны). Возможно, нужно будет сделать структуру очереди независящей от адреса в памяти, т.е. база и смещения относительно ее. Также, полезно будет сделать какую-то проверку (типа контрольной суммы или чего-то еще), чтобы убедиться в целостности данных после mmap() на старте. Впрочем, при падении по питанию, например, ты не сможешь распознать, насколько это древняя копия данных, т.к. нет постоянной записи на диск при изменении данных, возможно, на диске данные в состоянии, когда приложение стартануло в предыдущий раз (а затем обработало много сообщений ни разу не сохранив состояние, а потом выключили питание). В общем, такой подход довольно просто решит большинство твоих задач, но не все.
M>Таким образом, получится и данные сохранять на диск при падении приложения (если ядро ОС и диск работоспособны) и при изменении данных в памяти не будет задействован диск (нулевые накладные расходы или около того). Могут быть нюансы в этой схеме, например, что делать, если модуль стал хранить очередь в другом формате (старый формат придется прочитать или приложение аккуратно остановить, чтобы очереди очистились).
Да вот как раз только такая идея в голове есть, чем — то напоминает WAL в БД c его политикой синхронизации на диск. Коллеги не все оценили идею, аргументируя, что можно просесть по производительности. Хотя вроде запись последовательная, механический диск подойдет.
S>Почему все модули не связаны строго через брокер: есть желание экономить на (де)сереализации и оверхэдах самого rabbitmq . Про aeron в курсе, но до этого далеко.
Не надо. Современный подход — scale out, то есть поставить две железки и сбалансировать нагрузку. Это дешевле, чем программировать.
SD>Не надо. Современный подход — scale out, то есть поставить две железки и сбалансировать нагрузку. Это дешевле, чем программировать.
Удваиваю. Честно говоря, при чтении некоторых предложений тут остатки волос на голове шевелились от ужаса при мысли, сколько же будет стоить их поддержка. Не нужно "разгружать" брокеры сообщений: нагрузка — их работа. Нужно построить максимально простую архитектуру с обменами только через брокер. И при необходимости да, балансировать созданием кластера.
M>>Я бы сделал хранение очередей сообщений в mmap'ленном файле без синхронизации на диск при изменении очереди. В таком случае после падения приложения, если есть измененные страницы, данные сбросятся на диск ядром ОС. При этом во время чтения/записи очередей в памяти они на диск сразу попадать не будут (нет накладных расходов на регулярную запись данных на диск). Шанс потерять данные есть только в случае, если машина перезагрузится аппаратно (по питанию, например) или если ядро зависнет или диск испортится. При старте нужно будет считывать эти данные (на самом деле, когда сделаешь mmap(), данные сразу окажутся в приложении в том виде, как были записаны). Возможно, нужно будет сделать структуру очереди независящей от адреса в памяти, т.е. база и смещения относительно ее. Также, полезно будет сделать какую-то проверку (типа контрольной суммы или чего-то еще), чтобы убедиться в целостности данных после mmap() на старте. Впрочем, при падении по питанию, например, ты не сможешь распознать, насколько это древняя копия данных, т.к. нет постоянной записи на диск при изменении данных, возможно, на диске данные в состоянии, когда приложение стартануло в предыдущий раз (а затем обработало много сообщений ни разу не сохранив состояние, а потом выключили питание). В общем, такой подход довольно просто решит большинство твоих задач, но не все.
M>>Таким образом, получится и данные сохранять на диск при падении приложения (если ядро ОС и диск работоспособны) и при изменении данных в памяти не будет задействован диск (нулевые накладные расходы или около того). Могут быть нюансы в этой схеме, например, что делать, если модуль стал хранить очередь в другом формате (старый формат придется прочитать или приложение аккуратно остановить, чтобы очереди очистились).
S>Да вот как раз только такая идея в голове есть, чем — то напоминает WAL в БД c его политикой синхронизации на диск. Коллеги не все оценили идею, аргументируя, что можно просесть по производительности. Хотя вроде запись последовательная, механический диск подойдет.
Ты не понял (или я чего-то про mmap не знаю). В моем варианте вообще не будет записи на диск. Совсем. Никогда. Кроме случая завершения приложения (аварийного или штатного). После mmap на реальный файл у тебя будет адрес в обычной памяти и работать ты сможешь с этой памятью, как с обычной (а она и есть обычная). Однако, эти страницы памяти не анонимные, а отображены на файл и при вызове msync(), завершении приложения и каких-то редких случаев, про которые знают только разработчики ядра, данные из памяти будут записаны на диск. Но если не делать явный вызов msync(), данные будут меняться только в памяти и почти никогда не будут сохраняться на диск. Однако, если приложение остановится — ОС сохранит эти страницы памяти в файл, потому что знает, что эти страницы отображены на файлы и при первой же записи в такую страницу она будет помечена "гразной", т.е. содержащей не сохраненные данные, которые ОС и сохранит перед закрытием файла.
Итого, пока ты работаешь с памятью, полученной через mmap() на реальный файл, записи на диск не будет (почти или совсем). Но будет при остановке приложения (аварийной или штатной). При падении по питанию данные будут потеряны. Поэтому если нужна большая надежность, то, однозначно, требуется распределенная архитектура с очередями на отдельных физических машинах (о чем тут уже написали).
Здравствуйте, Masterspline, Вы писали:
M>>>Я бы сделал хранение очередей сообщений в mmap'ленном файле без синхронизации на диск при изменении очереди. В таком случае после падения приложения, если есть измененные страницы, данные сбросятся на диск ядром ОС. При этом во время чтения/записи очередей в памяти они на диск сразу попадать не будут (нет накладных расходов на регулярную запись данных на диск). Шанс потерять данные есть только в случае, если машина перезагрузится аппаратно (по питанию, например) или если ядро зависнет или диск испортится. При старте нужно будет считывать эти данные (на самом деле, когда сделаешь mmap(), данные сразу окажутся в приложении в том виде, как были записаны). Возможно, нужно будет сделать структуру очереди независящей от адреса в памяти, т.е. база и смещения относительно ее. Также, полезно будет сделать какую-то проверку (типа контрольной суммы или чего-то еще), чтобы убедиться в целостности данных после mmap() на старте. Впрочем, при падении по питанию, например, ты не сможешь распознать, насколько это древняя копия данных, т.к. нет постоянной записи на диск при изменении данных, возможно, на диске данные в состоянии, когда приложение стартануло в предыдущий раз (а затем обработало много сообщений ни разу не сохранив состояние, а потом выключили питание). В общем, такой подход довольно просто решит большинство твоих задач, но не все.
M>>>Таким образом, получится и данные сохранять на диск при падении приложения (если ядро ОС и диск работоспособны) и при изменении данных в памяти не будет задействован диск (нулевые накладные расходы или около того). Могут быть нюансы в этой схеме, например, что делать, если модуль стал хранить очередь в другом формате (старый формат придется прочитать или приложение аккуратно остановить, чтобы очереди очистились).
S>>Да вот как раз только такая идея в голове есть, чем — то напоминает WAL в БД c его политикой синхронизации на диск. Коллеги не все оценили идею, аргументируя, что можно просесть по производительности. Хотя вроде запись последовательная, механический диск подойдет.
M>Ты не понял (или я чего-то про mmap не знаю). В моем варианте вообще не будет записи на диск. Совсем. Никогда. Кроме случая завершения приложения (аварийного или штатного). После mmap на реальный файл у тебя будет адрес в обычной памяти и работать ты сможешь с этой памятью, как с обычной (а она и есть обычная). Однако, эти страницы памяти не анонимные, а отображены на файл и при вызове msync(), завершении приложения и каких-то редких случаев, про которые знают только разработчики ядра, данные из памяти будут записаны на диск. Но если не делать явный вызов msync(), данные будут меняться только в памяти и почти никогда не будут сохраняться на диск. Однако, если приложение остановится — ОС сохранит эти страницы памяти в файл, потому что знает, что эти страницы отображены на файлы и при первой же записи в такую страницу она будет помечена "гразной", т.е. содержащей не сохраненные данные, которые ОС и сохранит перед закрытием файла.
M>Итого, пока ты работаешь с памятью, полученной через mmap() на реальный файл, записи на диск не будет (почти или совсем). Но будет при остановке приложения (аварийной или штатной). При падении по питанию данные будут потеряны. Поэтому если нужна большая надежность, то, однозначно, требуется распределенная архитектура с очередями на отдельных физических машинах (о чем тут уже написали).
Да нет,именно это и имел в виду, когда упомянул кольцевой буфер. Про page cache в курсе. Правда момент есть, это идеально подходит на тот случаей, если обрабатываемые сообщения — POD структуры, то есть memcpy и ничего больше.
M>>>>Я бы сделал хранение очередей сообщений в mmap'ленном файле без синхронизации на диск при изменении очереди. В таком случае после падения приложения, если есть измененные страницы, данные сбросятся на диск ядром ОС. При этом во время чтения/записи очередей в памяти они на диск сразу попадать не будут (нет накладных расходов на регулярную запись данных на диск). Шанс потерять данные есть только в случае, если машина перезагрузится аппаратно (по питанию, например) или если ядро зависнет или диск испортится. При старте нужно будет считывать эти данные (на самом деле, когда сделаешь mmap(), данные сразу окажутся в приложении в том виде, как были записаны). Возможно, нужно будет сделать структуру очереди независящей от адреса в памяти, т.е. база и смещения относительно ее. Также, полезно будет сделать какую-то проверку (типа контрольной суммы или чего-то еще), чтобы убедиться в целостности данных после mmap() на старте. Впрочем, при падении по питанию, например, ты не сможешь распознать, насколько это древняя копия данных, т.к. нет постоянной записи на диск при изменении данных, возможно, на диске данные в состоянии, когда приложение стартануло в предыдущий раз (а затем обработало много сообщений ни разу не сохранив состояние, а потом выключили питание). В общем, такой подход довольно просто решит большинство твоих задач, но не все.
M>>>>Таким образом, получится и данные сохранять на диск при падении приложения (если ядро ОС и диск работоспособны) и при изменении данных в памяти не будет задействован диск (нулевые накладные расходы или около того). Могут быть нюансы в этой схеме, например, что делать, если модуль стал хранить очередь в другом формате (старый формат придется прочитать или приложение аккуратно остановить, чтобы очереди очистились).
S>>>Да вот как раз только такая идея в голове есть, чем — то напоминает WAL в БД c его политикой синхронизации на диск. Коллеги не все оценили идею, аргументируя, что можно просесть по производительности. Хотя вроде запись последовательная, механический диск подойдет.
M>>Ты не понял (или я чего-то про mmap не знаю). В моем варианте вообще не будет записи на диск. Совсем. Никогда. Кроме случая завершения приложения (аварийного или штатного). После mmap на реальный файл у тебя будет адрес в обычной памяти и работать ты сможешь с этой памятью, как с обычной (а она и есть обычная). Однако, эти страницы памяти не анонимные, а отображены на файл и при вызове msync(), завершении приложения и каких-то редких случаев, про которые знают только разработчики ядра, данные из памяти будут записаны на диск. Но если не делать явный вызов msync(), данные будут меняться только в памяти и почти никогда не будут сохраняться на диск. Однако, если приложение остановится — ОС сохранит эти страницы памяти в файл, потому что знает, что эти страницы отображены на файлы и при первой же записи в такую страницу она будет помечена "гразной", т.е. содержащей не сохраненные данные, которые ОС и сохранит перед закрытием файла.
M>>Итого, пока ты работаешь с памятью, полученной через mmap() на реальный файл, записи на диск не будет (почти или совсем). Но будет при остановке приложения (аварийной или штатной). При падении по питанию данные будут потеряны. Поэтому если нужна большая надежность, то, однозначно, требуется распределенная архитектура с очередями на отдельных физических машинах (о чем тут уже написали).
S>Да нет,именно это и имел в виду, когда упомянул кольцевой буфер. Про page cache в курсе. Правда момент есть, это идеально подходит на тот случаей, если обрабатываемые сообщения — POD структуры, то есть memcpy и ничего больше.
Тогда я не понимаю, причем тут "вроде запись последовательная, механический диск подойдет". Запись из памяти на диск будет только при остановке приложения. Тут любой диск подойдет. Также не понимаю, почему "можно просесть по производительности". Кроме того, там буфер будет кольцевой, поэтому от WAL это довольно сильно отличается. Тут данные пишутся в памяти поверх уже обработанных, а WAL дописывает в хвост и регулярно сбрасывает на диск.
Данные, которые хранятся в очереди, будут в той структуре, которую ты сам сделаешь (скорее всего, POD). Также, данные целиком должны быть в очереди, ибо если сохранить туда указатель, например, то после перезапуска программы от него толку будет ноль.
Здравствуйте, Masterspline, Вы писали:
M>>>>>Я бы сделал хранение очередей сообщений в mmap'ленном файле без синхронизации на диск при изменении очереди. В таком случае после падения приложения, если есть измененные страницы, данные сбросятся на диск ядром ОС. При этом во время чтения/записи очередей в памяти они на диск сразу попадать не будут (нет накладных расходов на регулярную запись данных на диск). Шанс потерять данные есть только в случае, если машина перезагрузится аппаратно (по питанию, например) или если ядро зависнет или диск испортится. При старте нужно будет считывать эти данные (на самом деле, когда сделаешь mmap(), данные сразу окажутся в приложении в том виде, как были записаны). Возможно, нужно будет сделать структуру очереди независящей от адреса в памяти, т.е. база и смещения относительно ее. Также, полезно будет сделать какую-то проверку (типа контрольной суммы или чего-то еще), чтобы убедиться в целостности данных после mmap() на старте. Впрочем, при падении по питанию, например, ты не сможешь распознать, насколько это древняя копия данных, т.к. нет постоянной записи на диск при изменении данных, возможно, на диске данные в состоянии, когда приложение стартануло в предыдущий раз (а затем обработало много сообщений ни разу не сохранив состояние, а потом выключили питание). В общем, такой подход довольно просто решит большинство твоих задач, но не все.
M>>>>>Таким образом, получится и данные сохранять на диск при падении приложения (если ядро ОС и диск работоспособны) и при изменении данных в памяти не будет задействован диск (нулевые накладные расходы или около того). Могут быть нюансы в этой схеме, например, что делать, если модуль стал хранить очередь в другом формате (старый формат придется прочитать или приложение аккуратно остановить, чтобы очереди очистились).
S>>>>Да вот как раз только такая идея в голове есть, чем — то напоминает WAL в БД c его политикой синхронизации на диск. Коллеги не все оценили идею, аргументируя, что можно просесть по производительности. Хотя вроде запись последовательная, механический диск подойдет.
M>>>Ты не понял (или я чего-то про mmap не знаю). В моем варианте вообще не будет записи на диск. Совсем. Никогда. Кроме случая завершения приложения (аварийного или штатного). После mmap на реальный файл у тебя будет адрес в обычной памяти и работать ты сможешь с этой памятью, как с обычной (а она и есть обычная). Однако, эти страницы памяти не анонимные, а отображены на файл и при вызове msync(), завершении приложения и каких-то редких случаев, про которые знают только разработчики ядра, данные из памяти будут записаны на диск. Но если не делать явный вызов msync(), данные будут меняться только в памяти и почти никогда не будут сохраняться на диск. Однако, если приложение остановится — ОС сохранит эти страницы памяти в файл, потому что знает, что эти страницы отображены на файлы и при первой же записи в такую страницу она будет помечена "гразной", т.е. содержащей не сохраненные данные, которые ОС и сохранит перед закрытием файла.
M>>>Итого, пока ты работаешь с памятью, полученной через mmap() на реальный файл, записи на диск не будет (почти или совсем). Но будет при остановке приложения (аварийной или штатной). При падении по питанию данные будут потеряны. Поэтому если нужна большая надежность, то, однозначно, требуется распределенная архитектура с очередями на отдельных физических машинах (о чем тут уже написали).
S>>Да нет,именно это и имел в виду, когда упомянул кольцевой буфер. Про page cache в курсе. Правда момент есть, это идеально подходит на тот случаей, если обрабатываемые сообщения — POD структуры, то есть memcpy и ничего больше.
M>Тогда я не понимаю, причем тут "вроде запись последовательная, механический диск подойдет". Запись из памяти на диск будет только при остановке приложения. Тут любой диск подойдет. Также не понимаю, почему "можно просесть по производительности". Кроме того, там буфер будет кольцевой, поэтому от WAL это довольно сильно отличается. Тут данные пишутся в памяти поверх уже обработанных, а WAL дописывает в хвост и регулярно сбрасывает на диск.
M>Данные, которые хранятся в очереди, будут в той структуре, которую ты сам сделаешь (скорее всего, POD). Также, данные целиком должны быть в очереди, ибо если сохранить туда указатель, например, то после перезапуска программы от него толку будет ноль.
Все, я понял , что смутило вам. Касаемо wal, казалось , что там кольцо.
Здравствуйте, Kswapd, Вы писали:
SD>>Не надо. Современный подход — scale out, то есть поставить две железки и сбалансировать нагрузку. Это дешевле, чем программировать.
K>Удваиваю. Честно говоря, при чтении некоторых предложений тут остатки волос на голове шевелились от ужаса при мысли, сколько же будет стоить их поддержка. Не нужно "разгружать" брокеры сообщений: нагрузка — их работа. Нужно построить максимально простую архитектуру с обменами только через брокер. И при необходимости да, балансировать созданием кластера.
Если бы брокеры еще справлялись с этой нагрузкой.
Кролик — медленный и плохо живет в кластере (да и с персистансом там не прекрасно)
Кафка — в разы быстрее, но есть проблема с количеством поддерживаемых топиков
Pulsar — не очень популярен
Ну и в любом случае нужно глубоко погружаться в решение, что бы понять, какие гарантии реально даются.
Здравствуйте, Sazon, Вы писали:
S>Всем привет, такой вопрос.
S>Один компонент — отдельный агент-поток со своим неким почтовым ящиком. При разработке системы возникла проблема потери сообщений в ряде случаев. S>Это kill -9, отвалилась сеть, модуль нужно перезапустить, аварийное завршение и прочие причины, когда компонент завершит свое исполнние, не разобрав ящик. S>Не мог бы кто-то посоветовать, что почитать, какте методики применяются. Какие-то моменты уяснил из документации для akka, но тем не менее. Ситуация усугубляется тем, что при отправке модулем во внешнюю среду сообщения буфферизируются в пачку по N (асинхронность).
Стандартные вопросы:
1) Сколько очередей нужно (сколько акторов в системе)
2) Сколько событий в секунду нужно уметь обрабатывать на одном хосте и на всей системе?
3) Какие гарантии нужны (гарантия доставки, гарантия обработки, гарантия only-once или что-то еще)?
Тогда можно и о решениях говорить )
Может, вся задача решается простой СУБД или кафкой..
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Здравствуйте, Sazon, Вы писали:
S>>Всем привет, такой вопрос.
S>>Один компонент — отдельный агент-поток со своим неким почтовым ящиком. При разработке системы возникла проблема потери сообщений в ряде случаев. S>>Это kill -9, отвалилась сеть, модуль нужно перезапустить, аварийное завршение и прочие причины, когда компонент завершит свое исполнние, не разобрав ящик. S>>Не мог бы кто-то посоветовать, что почитать, какте методики применяются. Какие-то моменты уяснил из документации для akka, но тем не менее. Ситуация усугубляется тем, что при отправке модулем во внешнюю среду сообщения буфферизируются в пачку по N (асинхронность).
ДФ>Стандартные вопросы: ДФ>1) Сколько очередей нужно (сколько акторов в системе) ДФ>2) Сколько событий в секунду нужно уметь обрабатывать на одном хосте и на всей системе? ДФ>3) Какие гарантии нужны (гарантия доставки, гарантия обработки, гарантия only-once или что-то еще)?
ДФ>Тогда можно и о решениях говорить ) ДФ>Может, вся задача решается простой СУБД или кафкой..
1. ~15
2. Допустим, через всю цепочку 70000 событий на хосте. Речь пока не идет о распр. системе.
3. Доставка, обработка. Касаемо дедупликации хз, терять ничего не должны.
ДФ>Кролик — медленный и плохо живет в кластере (да и с персистансом там не прекрасно) ДФ>Кафка — в разы быстрее, но есть проблема с количеством поддерживаемых топиков
И у вас, конечно же, есть тесты, для вашей доменной отрасли, подтверждающие такие высказывания?
ДФ>>Стандартные вопросы: ДФ>>1) Сколько очередей нужно (сколько акторов в системе) ДФ>>2) Сколько событий в секунду нужно уметь обрабатывать на одном хосте и на всей системе? ДФ>>3) Какие гарантии нужны (гарантия доставки, гарантия обработки, гарантия only-once или что-то еще)?
S>1. ~15 S>2. Допустим, через всю цепочку 70000 событий на хосте. Речь пока не идет о распр. системе. S>3. Доставка, обработка. Касаемо дедупликации хз, терять ничего не должны.
70K mps и небольшое количество топиков — это вполне себе задача для kafka, проще на ней и реализовывать.
Гарантии доставки там есть, гарантии обработки нужно будет делать самому (но это вообще не всегда возможно)
ДФ>>Кролик — медленный и плохо живет в кластере (да и с персистансом там не прекрасно) ДФ>>Кафка — в разы быстрее, но есть проблема с количеством поддерживаемых топиков
SD>И у вас, конечно же, есть тесты, для вашей доменной отрасли, подтверждающие такие высказывания?
Конечно. И тесты и опыт )
