|
Действия ...
|
17.12.2019, 10:55
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
|
|
17.12.2019, 13:31
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
|
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
17.12.2019, 10:55
|
|||
|---|---|---|---|
вопрос про очереди когда плохая сеть |
|||
|
#18+
есть два сервера между которыми очень плохое соединение иногда сеть может лежать часами нужен удаленный вызов процедур как правильно такое организовать? например если делать это с rabbitmq правильно ли я понимаю что схема такая? 1) на обоих серерах должны стоять серверы rabbitmq1 и rabbitmq2 2) приложение клиент добавляет сообщение в очередь отправок на своем сервере(rabbitmqсервер1) и начинает проверять очередь результатов 3) rabbitmqсервер1 пытается доставить его на rabbitmqсервер2, когда сеть работает это удается, rabbitmqсервер2 обрабатывает сообщение и кладет результат в очередь результатов на сервере2 4) rabbitmqсервер2 пытается доставить результат на rabbitmqсервер1 , когда это удается приложение клиент получает результат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2019, 12:11
|
|||
|---|---|---|---|
вопрос про очереди когда плохая сеть |
|||
|
#18+
Wizandr, мне кажется да, но есть нюансы. - работа с очередью может быть с подтверждением обработки задания. - кто работает с очередями? если микросервисы, то они обязаны корректно отрабатывать пропадание связи с контрагентами...т.е. тогда микросервис-очередь1-очередь2-микросервис мягко говоря избыточно. должно быть микросервис-очередь2-микросервис в одну сторону и микросервис-очередь1-микросервис в другую...имхо... (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2019, 13:31
|
|||
|---|---|---|---|
вопрос про очереди когда плохая сеть |
|||
|
#18+
kolobok0 Wizandr, мне кажется да, но есть нюансы. - работа с очередью может быть с подтверждением обработки задания. - кто работает с очередями? если микросервисы, то они обязаны корректно отрабатывать пропадание связи с контрагентами...т.е. тогда микросервис-очередь1-очередь2-микросервис мягко говоря избыточно. должно быть микросервис-очередь2-микросервис в одну сторону и микросервис-очередь1-микросервис в другую...имхо... (круглый) если мое приложение будет корректно обрабатывать отсутствие сети, то мне очередь вообще не понадобится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2019, 14:59
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Wizandr если мое приложение будет корректно обрабатывать отсутствие сети, то мне очередь вообще не понадобится Вот и ответ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2019, 15:11
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
- есть сеть? - нет - сервера ответ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.12.2019, 07:59
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Wizandr есть два сервера между которыми очень плохое соединение иногда сеть может лежать часами нужен удаленный вызов процедур В нулевые обычно такая задача решалась, через почту (smtp-протокол) :-) По идее любая очередь декларирует хотя бы единичную доставку сообщения. Так что на прикладном уровне, не нужно "заморачиваться", над разрывами. Нужно подумать, что будет если одно и то же сообщение придет более одного раза. А вот на транспортном уровне нужно уже смотреть, как должна себя вести при обрыве,восстановлении связи. ИМХО smtp вполне нормальное решение, при не стабильном соединении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2019, 01:25
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
mad_nazgul В нулевые обычно такая задача решалась, через почту (smtp-протокол) :-) Фу.... какая гадость лучше уж UUCP / UUPC, FTN и проще и надежнее ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2019, 05:36
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Leonid Kudryavtsev mad_nazgul В нулевые обычно такая задача решалась, через почту (smtp-протокол) :-) Фу.... какая гадость лучше уж UUCP / UUPC, FTN и проще и надежнее ))) Это eже 90-е. Так можно и до флопинета дойти. Было и такое решение. Репликация БД через флопинет. Бухгалтерия с районов данные собирала. БД была первасив. Инкрементальные данные передавались в формате похожем на JSON. А так, время показало, что почта не убиваемый сервис :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2019, 05:54
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Wizandr правильно ли я понимаю что схема такая? Нет, это работает не так. Есть сервер rabbitmq. Через него клиенты обмениваются сообщениями. Такой мессенждер для приложений. Короче второй сервер не нужен. Тут главное сделать нормальную обработку обрывов, при подтверждении приёма сообщения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2019, 14:56
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
crutchmaster Тут главное сделать нормальную обработку обрывов Ну он же написал, что если бы мог её сделать - не начал бы топик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.12.2019, 04:31
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Dimitry Sibiryakov, И что там делать? Подтверждение доставки с реконнектом? Отправка с таймаутом? Все достаточно банально, кмк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.12.2019, 09:10
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Dimitry Sibiryakov crutchmaster Тут главное сделать нормальную обработку обрывов Ну он же написал, что если бы мог её сделать - не начал бы топик. Э-э-э сейчас все современные брокеры сообщений декларируют, что гарантируют доставку сообщения хотя бы один раз. При этом не гарантируют, что сообщение будет доставлено ровно один раз. Опыт использования SMTP показал, что это очень устойчивый протокол, в том числе и к различным обрывам, и нестабильности сети. При этом сам протокол формально гарантию доставки сообщений не дает. По моему опыту. Если есть вопросы к надежности сети. То для стабильной работы лучше взять SMTP. С брокерами сообщений были проблемы, но это было лет 15 назад. Опыт был с MSMQ. Не справлялся с нагрузкой, плюс соединение было так себе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.12.2019, 14:37
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
mad_nazgul Опыт использования SMTP показал, что это очень устойчивый протокол, в том числе и к различным обрывам, и нестабильности сети. Вот только в отличии от UUCP не поддерживает докачку и при частых разрывах большое письмо может не отправиться вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.12.2019, 05:39
|
|||
|---|---|---|---|
|
|||
вопрос про очереди когда плохая сеть |
|||
|
#18+
Dimitry Sibiryakov mad_nazgul Опыт использования SMTP показал, что это очень устойчивый протокол, в том числе и к различным обрывам, и нестабильности сети. Вот только в отличии от UUCP не поддерживает докачку и при частых разрывах большое письмо может не отправиться вообще. Так я и говорю, что SMTP не гарантирует доставку сообщения. В тех задачах с которыми мне приходилось встречаться, он вполне нормально работал. Насчет разрывов. Видел решение, когда очереди в WebLogic работали в двух физически не соединенных сетях. Через "шлюз", который попеременно подключался то одной, то к другой сети механически (Паранойя она такая). И нормально работало. Мы туда-сюда xls-файлы гоняли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=33&mobile=1&tid=1547135]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
53ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 559ms |
| total: | 691ms |
| 0 / 0 |
