На 23:30 как-то сложно с промежуточной очередью, обычно для ускорения outbox сообщение отправляют просто после коммита транзакции (и если удалось - удаляют из outbox). Тогда фоновый процесс будет заниматься доотправкой только того, что не удалось отправить из-за ошибки, большинство сообщений будут отправляться сразу же (но точно также проходить через коммит в outbox).
@@timramone наверно имеется ввиду, что мы в транзакции выполняем полезную работу и сохраняем в аутбокс сообщение, которое нужно отправить, и комитим транзакцию. Тут все как везде) а дальше в этом же потоке пытаемся сразу отправить данное сообщение и удалить его из аутбокса, тогда демону, который разгребает аутбокс, нужно будет доотправлять только упавшие сообщения
@@AgentFire0 ответ через год конечно смешно, но тем не менее :) не всегда это можно себе позволить, например если ты находишься в критическом пути, или если то, что должно происходиить в обработке outbox'а сильно дороже обработки исходного сообщения (и соответственно должно масштабироваться по-другому как-то)
Не совсем понятен один момент. Сначала говорится что эвентов много и rdbms не подходит под такую нагрузку. При этом далее говорится что при создании клиента его данные и эвент о создании коммитятся в рамках одной транзакции (outbox). Тогда получается что если будет много клиентов система прикурить из-за проблем масштабируемости rdbms и далее видимо придётся шардить
всё так. в докладе имеется ввиду, что мы не будем делать таблицу транзакций, из которых потом вычитывать пачку и отправлять её в кафку, так как это как раз очередь на базе. вместо этого мы пишем в настояющую очередь, и читаем из базы по ключу, что гораздо лучше масштабируется (параллелится)
Прикольно -- Говорит, что хотят работать с transactional outbox быстрее, при этом предлагает уровень изоляции serializable -- У kafka если exactly-once гарантия на уровне продюсера, это упрощает всю схему -- Самое главное, exactly-once на стороне консьюмера все равно не работает :D
1. А где? Вообще не предлагаю, предлагаю снапшот)) 2. Как именно? По-моему не упрощает. 3. На стороне консьюмера единственный вариант чтобы работала, в этом весь смысл.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
На 23:30 как-то сложно с промежуточной очередью, обычно для ускорения outbox сообщение отправляют просто после коммита транзакции (и если удалось - удаляют из outbox). Тогда фоновый процесс будет заниматься доотправкой только того, что не удалось отправить из-за ошибки, большинство сообщений будут отправляться сразу же (но точно также проходить через коммит в outbox).
После коммита будут теряться сообщения
@@timramone наверно имеется ввиду, что мы в транзакции выполняем полезную работу и сохраняем в аутбокс сообщение, которое нужно отправить, и комитим транзакцию. Тут все как везде) а дальше в этом же потоке пытаемся сразу отправить данное сообщение и удалить его из аутбокса, тогда демону, который разгребает аутбокс, нужно будет доотправлять только упавшие сообщения
@@want2sleeptt понятно, тоже интересный подход!
@@timramone не просто интересный, а логичный, ведь он сильно оптимизирует happy path.
@@AgentFire0 ответ через год конечно смешно, но тем не менее :) не всегда это можно себе позволить, например если ты находишься в критическом пути, или если то, что должно происходиить в обработке outbox'а сильно дороже обработки исходного сообщения (и соответственно должно масштабироваться по-другому как-то)
Не совсем понятен один момент. Сначала говорится что эвентов много и rdbms не подходит под такую нагрузку. При этом далее говорится что при создании клиента его данные и эвент о создании коммитятся в рамках одной транзакции (outbox). Тогда получается что если будет много клиентов система прикурить из-за проблем масштабируемости rdbms и далее видимо придётся шардить
всё так. в докладе имеется ввиду, что мы не будем делать таблицу транзакций, из которых потом вычитывать пачку и отправлять её в кафку, так как это как раз очередь на базе. вместо этого мы пишем в настояющую очередь, и читаем из базы по ключу, что гораздо лучше масштабируется (параллелится)
Прикольно
-- Говорит, что хотят работать с transactional outbox быстрее, при этом предлагает уровень изоляции serializable
-- У kafka если exactly-once гарантия на уровне продюсера, это упрощает всю схему
-- Самое главное, exactly-once на стороне консьюмера все равно не работает :D
1. А где? Вообще не предлагаю, предлагаю снапшот))
2. Как именно? По-моему не упрощает.
3. На стороне консьюмера единственный вариант чтобы работала, в этом весь смысл.