5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
для более менее вменяемой работы timestamp(если часы не логические), нужно ntp еще настроить на серверах, но тут конечно вилами по воде все, так как все равно будут разъезжаться
Читать полностью…
лучше конечно время брать из событий, т.к. оно наверянка бизнес значимо по сравнению с временем создания в базе. И на бизнес значимое время можно уже навешиват ьлогику склейки и выравнивания
Читать полностью…
просто читать все подряд и складывать в соответсвующие таблички
Читать полностью…
ну так вы ж в базу все положите, когда придет из инита првоеряете были ли из доп топиков сообещния уже в базе
Читать полностью…
ну тогда только БД плюс по крону и по пришедшему любому событию вытаскивать из бд что успело накопиться, склеивать и отгружать куда там дальше надо
Читать полностью…
а сколько может потребоваться ждать чтобы породить эвенты? и критерий склейки вообще какой, надо дождаться 3 связанных событий из оставшихся топиков или их может и не быть вообще?
Читать полностью…
Ну из топика(инициализирующего) я могу понимать нужно мне смотреть в остальные и искать там ивенты или нет.
Пока не совсем понимаю, к чему in memory? Ну условно если синк делать и в потоке врубать консумеров - то +/- оно и будет в памяти + в БД)
И вот дальше - начинаю я смотреть другие топики. Вот у меня вычитывается, я двигаю оффсет в "помойках" - и пока я ищу нужное, мне навалили ещё новых и я по ним пробегаю. А потом беру некст мессагу из инициализации, а уже те проёбаны.
Чувство есть, что нужно что то допом закинуть, на что то завязаца, но из стэка кафка/постгря. А вот как сделать красиво и без потерь, в том вопрос.
например загнать в кэш данные из топика это ок, а кэш это in memory или rocksdb(оно вроде сейчас даже нормально работает)
Читать полностью…
А повторы/дубли и т.п. возможны, нет гарантий и исходя из инициализирующего - нужно либо обновлять либо пропускать
Читать полностью…
Там просто часть первичного ключа - последовательный счётчик. Клиенты, увидевшие состояние К, пытаются сделать инсерт записи со счётчиком К + 1, инсерт не выполнится, если кто-то уже успел. Если в состоянии К state = running, то другие клиенты и не пытаются ничего сделать, в противном случае соревнуются, как в предыдущем предложении.
Читать полностью…
А смысл? Валидацию же мне надо следить до вставки в лог, потом уже поздно будет, нет?
Читать полностью…
достаточно прочитать отзывы
Будешь пахать как лошадь за 70 или скок они там предлагают, но хорошо прокачаешь харды
Уважаемые люди! Здравствуйте!
Вопрос у меня такой. Есть ли возможность создания программы многопользовательской или приложения на телефон для создания онлайн пропусков?
Есть Жилой комплекс из 3 корпусов, всего около 1500 квартир. Для того, чтобы пустили курьера, нужно дозвониться до охранника и сообщить ему номер квартиры, чтобы он пропустил курьера. Как можно оптимизировать процесс. Есть ли такие программы или может кто-то имел опыт создания подобного.
Всем заранее огромное спасибо!
Это связи ktable/ktable в терминах кафка стримов.
При получении эвента в одном из топиков, проверяется яналичие сопутствующей записи из другого. Если нет, то запись просто сохраняется и ждет своего часа X, когда оа понадобится для джоина.
Сторадж можно любой сделать, не только rocksdb -- хоть в памяти держите, если топики колоцированы, хоть во внешний постгрес сохраняйте.
Обработка кейса, когда сопутствующего эвента нет через ttl. Реализацию можно сделать на любой вкус: шедул внешними средствами, lru, window, что-то еще.
Какие-то далеты из прошлого решать через отброс подобных событий по таймстемпу (или как там у вас бизнес захочет). Таймстемпов у вас, как минимум, три:
- ingest timestamp
- business timestamp
- processed timestamp
Логично выбрать business timestamp, которая про создание эвента, но если все плохо и ее нет, тогда хотя бы ingest (хотя ничем не поможет и события тогда вообще имеют шанс перемешаться)
Флинк тут будет оверкил, кафка-стримы -- вполне могут подойти (раз хочется остаться в существующей экосистеме из кафка/постгрес и ничего более), если учесть нюансы с системными топиками, которых может нагенерировать массу (но если руками джоины организовать, то в общем-то можно уменьшить их число, а то и во все руками сделать без стримов).
Зависит от объема потоков, но подобное чудовище может заработать.
Наглядная визуализация идеи: https://www.confluent.io/blog/crossing-streams-joins-apache-kafka/ (поиск по KTable-KTable Join)
Хм...Вариант, спасибо)Можно попробовать завязаться на время создания/обновления записей
Читать полностью…
Ложу да, при первой инициализации. В дальнейшем может прийти дубль - тогда мне топики чекать не надо, может ничего не прийти - и я не должен по этому айдишнику чекать другие топики.
В случае с кроной - я иду и сверяю ток с БД, невзирая на инициализацию. Разве что попытаца на время завязаца в БД, хм. Но опять же, как читать остальные 3 топика?
С раннего оффсета? Сбрасывать? Тогда могу вычитать первые невалидные(неактуальные данные), а актуальные будут позже.
Сдвигать на текущий - могу потерять то, что было в промежутке и может там лежало.
Впервые прост такой ебанизм встречаю, вообще непродуманный
А возможна ситуация, что в другие топики что то прилетело, а инициализации не было... Не подходит)
Читать полностью…
Может и не быть, могут и быть. В большинстве случаев - ивенты загружаются в инит топик - потом последовательно в другие.
Критерий склейки условно идентификатор которые сквозной в мессаджах, чтобы было отличие - к тому ли инициализатору они относятся
Надо дождаться, да. Но пока ждём - может быть накинуто ещё мессаг и мы не найдя свою улетим по оффсетам дальше сдвигом, чем ожидалось.
кафка не предназначена для такого поиска
как я уже выше писал, проще всего писать данные в какую то еще бд и уже из нее выбирать
решением для бедных может быть - загнать снепшот данных в pgsql и ждать пока доедут все нужные данные по одной записи и процессить уже когда все есть в наличии, но в этом случае наш процессинг будет работать примерно со скоростью записи данных в pgsql, и тут уже вопрос, а нужна ли нам кафка :/ (возможно да)
Читать полностью…
kafka streams вроде и решает подобные проблемы(и flink насколько я понимаю)
но то как они решаются не всем понравится)
Накину вопросик.
Есть БП: 4 топика кафки. 1 инициирует, в 3 остальных ожидаем доп. данные по сущности, из инициирующего топика.
Есть нюансы: в некоторые топики насирают просто всё подряд и много данных, ожидается последовательная нагрузка в топики с задержкой(но не точно, возможны ивенты ранее инициирующего)
Отсюда вопрос, мож кто встречался, как это разрулить без потерь данных/времени ожидания и т.п.
4 в асинк не вкатит, т.к. может один листенер вычитать раньше, чем инициализирующий и пропустица.
В синке - если ранее инициирующего кинуты и сдвигать оффсет в конец при старте получения инициирующего - теряем данные между переключениями оффсетов по триггеру инициирующего.
Тут как будто изначально всё не так и возможны в любом разе рассинхроны данных, когда приходить будет по 3ём топикам раньше основного(инициализирующего). Что даже особо накостылить что-то анриал, либо же перечитывать каждый раз все входящие сообщения(что тоже не катит, т.к. по инициализации может быть несколько сообщений и обновлять нужно в определенных случаях)... =\
Даже нет идей, на что можно завязаться, как не проебать сдвиги оффсетов на консумерах и плюсом сохранить время обработки в ~ пару тройку секунд на всё
Изначально идейно было бы нормально их пустить в асинке, регулировать через БД (инициализирующее создаёт) - остальные обновляют.
Но если будет без инициализирующего - то обновлять не нужно =\
Сделать event sourcing на коленке, в котором хранить последнее состояние
Читать полностью…
Всем привет! Ребята, кто-нибудь работал или стажировался в Aston? Прошёл туда на стажировку, но предлагают подписать ученический договор на 18 месяцев — если не отработаю, нужно будет вернуть 600 000₽ за обучение. Кто сталкивался? Расскажите, как там работа и стоит ли соглашаться?
Читать полностью…
вопрошайте яндекс, таких готовых систем - вагон и маленькая тележка
Читать полностью…
ну для соблюдения инварианта как вам удобнее будет. я хотел предложить что-то типа таблички с одной возможной записью
create table running_lock (
process_name text primary key not null
id uuid not null
)
insert into running_lock values ("my_process", id)