|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
Опять таки не знаю к чему относится вопрос, запостил здесь. У нас планируется разработка асинхронного АПИ. Суть в том что каждый запрос сперва сохраняется в БД как запрос, а потом по мере возможности посылается в очередь на реальную обработку. Тем самым создается асинхронность запросов. Я в недоумении, зачем городить лишний элемент (сохранение в БД самих запросов) если можно воспользоваться возможностями очередей (которые и так затем используются). Да персистентные очереди очень проседают в производительности, но есди посадить их на SSD проседание будет не более 20% (сам на оленке проверял), тем более для нас скорости не критичны. Критично не потерять запрос. Меньше элементов - меньше возможностей для сбоя Может я чего то не знаю про очереди? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 08:10 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
recvezitorКритично не потерять запрос. Меньше элементов - меньше возможностей для сбоя А СУБД разве менее надежна, чем очередь? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 12:03 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
не менее, но зачем? Т.е. предлагается такой вариант: клиент - временная БД - очередь - БД вместо того, чтобы исползовать: клиент - персистентная очередь - БД По прежнему можем потерять запрос, когда посылаем запрос в очередь, т.е. все равно надо делать очередь с какой то гарантией что сообщения не потеряются. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 16:53 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
recvezitorне менее, но зачем? Т.е. предлагается такой вариант: клиент - временная БД - очередь - БД вместо того, чтобы исползовать: клиент - персистентная очередь - БД Этот вопрос лучше задать тому парню, который у вас архитектуру разрабатывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 16:59 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
> Может я чего то не знаю про очереди? http://en.wikipedia.org/wiki/Message_Queue Вам настолько необходимо самим делать реализацию? Ведь уже давно существуют готовые реализации.. Но в любом случае, сначала лучше хотя бы по быстрому ознакомится с теорией, чем начинать собственную нетленку.. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 16:48 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
особенно если учесть, что в БД есть Jobs (асинхронно) - это дважды велосипед ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2012, 13:14 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
Petro123особенно если учесть, что в БД есть Jobs (асинхронно) - это дважды велосипед Джобс мертв ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2012, 18:33 |
|
Асинхронный API VS персистентные очереди
|
|||
---|---|---|---|
#18+
recvezitor, Ну, во-первых, запрос может отвалиться по тайм ауту. Как это обработается Вашей бизнес-логикой? Второе, если БД распределённая, то запрос на другой сервер может уйти в никуда либо просто остановить работу всего приложения. Так что без очередей не обойтись. Другое дело, что способ их реализации - дело вкуса. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2013, 15:29 |
|
|
start [/forum/topic.php?fid=33&fpage=18&tid=1547737]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 9ms |
total: | 124ms |
0 / 0 |