@Tishka17

Tishka17

Tishka17
Tishka17
22 я читаю 78 меня читают
1362 постов
4623 комментариев
Tishka17 Tishka17
04 Oct 2019

работа

У нас есть очень стандартный процесс связи нескольких сервисов:

  1. Сервис А кладёт данные в таблицу БД (у нас своя бд с таблицами по папочкам)
  2. Сервис Б раз в 15 минут ищет новую таблицу и читает из нее данные и что-то делает с ними
  3. Сервис А раз в 15 минут смотрит в другую папку на предмет появления таблицы с результатами

В результате у нас задержка получается полчаса за нефиг делать.

Это вообще нормально?

#zmsoc 38
skobkin-ru
04 Oct 2019

Расскажи им про очереди и воркеры, например.

#zmsoc/2
igelko
04 Oct 2019

мы так тоже делаем. только раз в пять минут и интеграция идёт со сторонней системой.

#zmsoc/3
cauf
04 Oct 2019

Для газпрома - да. Только период синхронизации не 15 минут, а час... В итоге имеем задержку в 2 часа

#zmsoc/6
hirthwork
04 Oct 2019

Вангую, что не в БД, а в тормозную хуйню. Это нормально. Можете попробовать pgaas, если влезете по размеру

Комментарий был отредактирован в 18:52:16 04.10.2019
#zmsoc/8
igelko
18 Oct 2019

но там же вроде есть "быстрые" таблицы?

#zmsoc/34 в ответ на /33
hirthwork
18 Oct 2019

То что у них время доступа меньше минуты не делает их «быстрыми»

#zmsoc/35 в ответ на /34
igelko
18 Oct 2019

я про динамические таблицы? они же вроде не так фатально тормозят?

#zmsoc/36 в ответ на /35
hirthwork
18 Oct 2019

Но использовать их для менеджмента задач — это пиздец. Нужно обработать данные — залей их на сторадж и через зукипер передай ссылку на данные, а не клади в медленную стстему чтобы обработчик их оттуда медленно вычитывал

#zmsoc/37 в ответ на /36
Tishka17
18 Oct 2019

Спасибо. А то у меня за время работы тут сложилось ощущение, что это норма

#zmsoc/38 в ответ на /37
rayslava
04 Oct 2019

Зато надёжно. А данных много? Ну и если ваша база какое-то древнее медленное легаси, то это может быть и нормой.

#zmsoc/9
igelko
07 Oct 2019

а что не фублядь?
// но вообще согласен, пока в очередь не пишешь - она не переполнится.

#zmsoc/14 в ответ на /13
fgntfg
07 Oct 2019

Tishka17, у нас примерно так:

Сервис А кладёт в MQ-A
MQ-A кладёт в приклад который пишет в БД ( там ещё маршрутизация осуществляется, кому что читать, но это опущу)
приклад вокруг БД кладёт в MQ-Б
Сервис Б читает из MQ-Б

Все занимает меньше секунды.

#zmsoc/15
igelko
07 Oct 2019

а сколько данных за раз просасываются? какие требования к транзакционности одной такой посылки? как решаются дубликаты/потеряшки (в зависимости от 0-1 или 1+)?

#zmsoc/21 в ответ на /15
skobkin-ru
07 Oct 2019

а сколько данных за раз просасываются?

Вопрос не очень понятен.

какие требования к транзакционности одной такой посылки?

Зависит от имплементации воркера и продюсера задач.

как решаются дубликаты/потеряшки (в зависимости от 0-1 или 1+)?

Дубликаты проще всего фиксить на воркере. Потеряшек быть не должно, если воркер релизит джоб после того как реально сохранил его в БД, а не просто от души.

#zmsoc/24 в ответ на /21
igelko
08 Oct 2019

Вопрос не очень понятен.
Зависит от имплементации воркера и продюсера задач.

вопрос был не к тебе, а к fgntfg мне интересно, как у них.

Потеряшки могут возникать, если у тебя очередь обеспечивает семантику at least once.
(ну допустим у тебя очередь - это шардированный нереплицированный неперсистентный кластер rabbitmq из 2х нод и одна упала - будут потеряшки).

#zmsoc/28 в ответ на /24
fgntfg
08 Oct 2019

Одно сообщение до, кажется 8мб, не это все настройками решалось. Сообщений сотни тысяч в час. Я не считал.
У каждого сообщения уникальный ID. Дубликаты решаются на стороне приемника, потеряшки - смотря где потеря. Обычно это переотправка из источника.

#zmsoc/31 в ответ на /21
igelko
07 Oct 2019

кстати, у нас тут почему-то тимлид захотел, чтоб у нас вместо специализированного адаптера для импорта с инкапсулированным кроном, обменные файлики внешних систем проходили через общий сервис-шлюз интеграций в котором все расписания и логики по общению со сторонней системой, а в адаптере была только логика импорта/экспорта.
Из этого возникла задача прокидывать между сервисами в качестве таска на импорт где-то гигабайт за раз. это как кузявее делать? файликом на люстре? smb-сервак держать для шаринга, s3? или на похер пропихивать через http телом?

#zmsoc/16
hirthwork
07 Oct 2019

Имхо, кузявее всего будет DHT

#zmsoc/17 в ответ на /16
igelko
07 Oct 2019

в смысле торрент-клиент-сервер демон на обоих машинах поднять? а с секьюрити как быть?

Комментарий был отредактирован в 12:15:22 07.10.2019
#zmsoc/18 в ответ на /17
hirthwork
07 Oct 2019

Не только на обоих, но и на нескольких резервных, чтобы отказоустойчивость была. А секурность обеспечивать iptables, которые не позволят с внешних сетей к этой таблице подключиться

#zmsoc/19 в ответ на /18
igelko
07 Oct 2019

понял, спасибо за идею, подумаю.

#zmsoc/20 в ответ на /19
fgntfg
07 Oct 2019

igelko, файлики, 2019, у меня ажно мурашки по спине бегают.

#zmsoc/22 в ответ на /16
igelko
07 Oct 2019

на самом деле это дёшево, просто и сердито.
позволяет на этапе пилота чуть ли не из экселя зафигачить к нам пользователей, техпроцессы и станки.
в идеале позже надо переходить на что-то другое, но как потом полный дамп техпроцессов импортировать, который жрёт гигабайт? всегда только дельты лить - потенциально ненадёжно (мы же не знаем, могут они их строить всегда без ошибок).

#zmsoc/23 в ответ на /22
skobkin-ru
07 Oct 2019

Думать надо от задачи. Озвучивать тут все детали - явно некорректно.

Дельты можно и локально считать. Написать имплементацию UnitOfWork и всё такое.

Ещё вариантом бедного человека может быть передача ответственности на БД за принятие решения о записи и формировать такие запросы, чтобы при изменении данных UPDATE был, а без них - нет. Это тоже можно сделать двумя вариантами:

  • Просто длинный WHERE (который тем хуже, чем больше полей нужно проверять)
  • Добавление, например, поля, которое содержит хэш от данных и если хэш в базе не сходится с хэшем, который у тебя на руках - обновлять запись. Это тоже можно сделать как на уровне запроса, так и на уровне того же UnitOfWork - имплементация в твоих руках.
#zmsoc/26 в ответ на /23
skobkin-ru
07 Oct 2019

smb-сервак держать для шаринга

NFS. Или там прямо на винду какую-то старую надо?

Хотя если подумать, гигабайт - это не так много. Можно по-разному просунуть. Тут главный вопрос в том насколько часто и другие побочные моменты.

#zmsoc/25 в ответ на /16
igelko
08 Oct 2019

ну вот смотри. в сторонней системе люди как-то работают, изменяя данные. этот выхлоп может попадать к нам или полными дампами состояния под гигабайт каждый, или дельтами (по сути лог изменений - add,modify,delete).
Желаемая задержка появления и применения данных в нашей системе - 10 минут.
Стороннюю систему разрабатываем и пишем не мы, так что у нас нет 100% уверенности, что дельты будут формироваться корректно или какая-то из дельт может быть потеряна (мало ли что - место, допустим, кончилось).
Каждый раз отдавать полный стейт - порнография, забивание жёстких дисков и лишнее нагревание воздуха.|
Потому раз в сутки они нам шлют полный дамп, чтобы уж точно не обосраться.

В свою очередь или базу мы их не имеем права пустить, и вместо веб-сервисов используем файлики через шару, потому что это относительно просто отлаживать и просматривать ad-hoc.

#zmsoc/29 в ответ на /25
postman
07 Oct 2019

ceph, только проверь, что хотя бы один патрон в барабане есть

#zmsoc/27 в ответ на /16
⬆

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.