ДК
два разных полла в итоге?
Size: a a a
2020 September 03
ДК
Ну, ладно, в принципе ситуация прояснилась более или менее.
Спасибо.
Почитаю доку.
Спасибо.
Почитаю доку.
N
Есть ли гарантия того что в такой имплементации в кафку будет отправлен месседж раньше чем коммит транзакции на базе ?
@Transactional
@StreamListener(TradingChannels.USERS_IN)
@SendTo(ProviderChannels.ACCOUNTS_OUT)
fun handle(user: UserEvent) .......
AL
N
Есть ли гарантия того что в такой имплементации в кафку будет отправлен месседж раньше чем коммит транзакции на базе ?
@Transactional
@StreamListener(TradingChannels.USERS_IN)
@SendTo(ProviderChannels.ACCOUNTS_OUT)
fun handle(user: UserEvent) .......
Речь о порядке вызовов: dbCommitTx -> kafkaCommitTx или kafkaCommitTx -> dbCommitTx?
N
Речь о порядке вызовов: dbCommitTx -> kafkaCommitTx или kafkaCommitTx -> dbCommitTx?
+
AL
N
+
Порядок, в котором будут выполнены коммиты, может быть определен самостоятельно (ChainedTransactionManager). Зависит от бизнес-логики.
N
Порядок, в котором будут выполнены коммиты, может быть определен самостоятельно (ChainedTransactionManager). Зависит от бизнес-логики.
в данном кейсе какой порядок ?
OK
Привет, вопрос по такому искдючению
<topicname> not present in metadata after 500 ms
гуглится только 60к мс (дефолт), у нас меньше, при этом на части топиков все ок, на части нет, есть догадки что не так?
мы на 2.2.х, на 2.х было ок
<topicname> not present in metadata after 500 ms
гуглится только 60к мс (дефолт), у нас меньше, при этом на части топиков все ок, на части нет, есть догадки что не так?
мы на 2.2.х, на 2.х было ок
AS
N
Есть ли гарантия того что в такой имплементации в кафку будет отправлен месседж раньше чем коммит транзакции на базе ?
@Transactional
@StreamListener(TradingChannels.USERS_IN)
@SendTo(ProviderChannels.ACCOUNTS_OUT)
fun handle(user: UserEvent) .......
введи не валидный аут ченел и посмотри по стектрейу в каком порядке аспекты накручиваются
N
Почему вы так делаете?
Часть информации нужно сохранить в базу, рассчитать новую и пробросить обогащенный ивент для обработки другим компонентам системы, и важно что бы в текущей базе сохранился снепшот данных иначе же ролбэк и не отправлять ивент в кафку, так как их подхватят последующие микросервисы и начнут свой процессинг
N
N
Часть информации нужно сохранить в базу, рассчитать новую и пробросить обогащенный ивент для обработки другим компонентам системы, и важно что бы в текущей базе сохранился снепшот данных иначе же ролбэк и не отправлять ивент в кафку, так как их подхватят последующие микросервисы и начнут свой процессинг
Правильным ответом будет такой порядок: dbCommitTx -> kafkaCommitTx
VG
N
Часть информации нужно сохранить в базу, рассчитать новую и пробросить обогащенный ивент для обработки другим компонентам системы, и важно что бы в текущей базе сохранился снепшот данных иначе же ролбэк и не отправлять ивент в кафку, так как их подхватят последующие микросервисы и начнут свой процессинг
Ьак
N
Я бы не стал так делать
Можно более детально, почему и как лучше ?
Мы получаем ивенты со сторонней системы и в рамках нашей системы база является источником достоверных данных, но есть задача процесить эти же ивенты с доп информацией в третью систему, которая по факту живёт своей жизнью, но юзер в итоге может открыть два окна и увидеть те же данные в разном формате в двух системах, т.е. важно что бы он и там и там увидел данные с идишками 1,2,3 ... Могут быть небольшие задержки, лаг, не страшно, важно что бы в итоге соблюдалась консистентность двух систем
Мы получаем ивенты со сторонней системы и в рамках нашей системы база является источником достоверных данных, но есть задача процесить эти же ивенты с доп информацией в третью систему, которая по факту живёт своей жизнью, но юзер в итоге может открыть два окна и увидеть те же данные в разном формате в двух системах, т.е. важно что бы он и там и там увидел данные с идишками 1,2,3 ... Могут быть небольшие задержки, лаг, не страшно, важно что бы в итоге соблюдалась консистентность двух систем
S
N
Можно более детально, почему и как лучше ?
Мы получаем ивенты со сторонней системы и в рамках нашей системы база является источником достоверных данных, но есть задача процесить эти же ивенты с доп информацией в третью систему, которая по факту живёт своей жизнью, но юзер в итоге может открыть два окна и увидеть те же данные в разном формате в двух системах, т.е. важно что бы он и там и там увидел данные с идишками 1,2,3 ... Могут быть небольшие задержки, лаг, не страшно, важно что бы в итоге соблюдалась консистентность двух систем
Мы получаем ивенты со сторонней системы и в рамках нашей системы база является источником достоверных данных, но есть задача процесить эти же ивенты с доп информацией в третью систему, которая по факту живёт своей жизнью, но юзер в итоге может открыть два окна и увидеть те же данные в разном формате в двух системах, т.е. важно что бы он и там и там увидел данные с идишками 1,2,3 ... Могут быть небольшие задержки, лаг, не страшно, важно что бы в итоге соблюдалась консистентность двух систем
Думаю каноничным ответом микросервис архитектуры основанной на стримах из презентаций конфлюента будет - не используйте данные из базы как источник правды в нескольких сервисах. Идеально будет подписаться на стрим изменения этих данных в обоих сервисах и материализовать необходимый сабсет этой базы в ktable.
В реальности я могу представить десятки причин почему это не возможно в конкретном случае, потому могу понять почему вы пошли таким путем.
В реальности я могу представить десятки причин почему это не возможно в конкретном случае, потому могу понять почему вы пошли таким путем.
VG
Думаю каноничным ответом микросервис архитектуры основанной на стримах из презентаций конфлюента будет - не используйте данные из базы как источник правды в нескольких сервисах. Идеально будет подписаться на стрим изменения этих данных в обоих сервисах и материализовать необходимый сабсет этой базы в ktable.
В реальности я могу представить десятки причин почему это не возможно в конкретном случае, потому могу понять почему вы пошли таким путем.
В реальности я могу представить десятки причин почему это не возможно в конкретном случае, потому могу понять почему вы пошли таким путем.
Хочется обнять за этот ответ, но не буду - вирус не дремлет
VG
N
Можно более детально, почему и как лучше ?
Мы получаем ивенты со сторонней системы и в рамках нашей системы база является источником достоверных данных, но есть задача процесить эти же ивенты с доп информацией в третью систему, которая по факту живёт своей жизнью, но юзер в итоге может открыть два окна и увидеть те же данные в разном формате в двух системах, т.е. важно что бы он и там и там увидел данные с идишками 1,2,3 ... Могут быть небольшие задержки, лаг, не страшно, важно что бы в итоге соблюдалась консистентность двух систем
Мы получаем ивенты со сторонней системы и в рамках нашей системы база является источником достоверных данных, но есть задача процесить эти же ивенты с доп информацией в третью систему, которая по факту живёт своей жизнью, но юзер в итоге может открыть два окна и увидеть те же данные в разном формате в двух системах, т.е. важно что бы он и там и там увидел данные с идишками 1,2,3 ... Могут быть небольшие задержки, лаг, не страшно, важно что бы в итоге соблюдалась консистентность двух систем
Я бы предложил писать либо только в базу (и потом коннектором выгребать в кафку а дальше все полетит в ваши микросервисы), либо сначала писать в кафку а потом коннектором обновлять локальную базу(ы) сервисов которые не знают ничего про кафку.
