Поэтому скептицизм абсолютно оправдан. Отсутствие человеческого участия в процессе проверки и обратной связи снижает образовательную ценность курса, превращая его в формальность. Настоящее обучение всегда требует диалога, а не просто передачи информации, даже если она генерируется самой современной нейросетью.
На самом деле таких преподавателей еще поискать, которые выше уровня ллм могут что-то хотя бы дополнить. И на всех таких преподаватетей не хватит, поэтому основной массе обучающихся ллм впору, с другой стороны стало лучше-проще знания получать, чем без ллм было до этого. Главное сохранять любознательность, стремиться научиться, а не отсидеть время.
Приветствую. Нагрузка на CPU будет у вас высокая из-за мультиплр-я и grpc, на полезную работу может проца не хватать, по памяти тоже с запасом всегда будете потреблять (но на таких объемах rpc может и ладно). Спросил у гугл-ии.
если посмотреть загрузку cpu и выделение памяти, что увидим?
Если мы запустим профилировщик (например, perf для CPU и je_prof / valgrind massif для памяти) под максимальной нагрузкой в 85 000+ RPS, то увидим очень специфическую картину. Она наглядно покажет, какую «цену» HurriCache платит за мультиплексирование gRPC.
Вот детальный расклад того, что отобразится на графиках и в FlameGraph.
1. Профиль загрузки CPU (Куда уходят такты процессора)
В отличие от классического Redis, где 80-90% CPU уходит на логику базы данных и простую обработку TCP-сокетов, в HurriCache картина разделится примерно 50/50 или даже 60/40 в пользу сетевого оверхеда.
Что покажет FlameGraph (топ горячих функций):
~45–55% CPU — Экосистема gRPC и HTTP/2:
grpc_core::HeaderTable и функции парсинга HPACK (сжатие/декомпрессия заголовков HTTP/2).
grpc_core::chttp2::ParsingState — нарезка потока на фреймы, разбор 9-байтовых заголовков и валидация Stream ID.
grpc::protobuf::Parser — десериализация бинарного потока Protobuf в C++ структуры сообщений.
Функции управления окнами (Flow Control) и отправки WINDOW_UPDATE.
~30–35% CPU — Кастомная хэш-таблица (Бизнес-логика):
Вычисление хэш-функций (например, MurmurHash или CityHash).
Сравнение ключей в памяти.
Примечание: Строки, связанные с ожиданием памяти (инструкции prefetch), будут занимать минимум времени процессора, так как CPU не уходит в Stall (простой), а молотит полезную работу.
~10–15% CPU — Системные вызовы ядра Linux:
epoll_wait, recvmsg, sendmsg — чтение и запись в сетевые сокеты.
Общий вывод по CPU: Процессор будет загружен «под полку» (близко к 100% на задействованных ядрах). При этом gRPC будет буквально пожирать такты на обслуживание структуры стримов и демультиплексирование, подтверждая ваши опасения.
2. Выделение и освобождение памяти (Аллокации)
Если бы автор HurriCache использовал стандартный gRPC и стандартный std::allocator «из коробки», база данных захлебнулась бы в аллокациях (Memory Churn). На каждый из 85 000 запросов в секунду выделялись бы десятки объектов.
Но поскольку это MVP высоконагруженной системы, профилировщик памяти покажет работу арен памяти (Memory Arenas), о которых автор вскользь упомянул в статье.
Что покажет профиль аллокаций (malloc / free в секунду):
Почти нуль (0) реальных системных вызовов malloc / free во время работы. Если база делает malloc на каждый запрос при 85K RPS — она ложится. Вместо этого мы увидим, что память выделяется крупными блоками (например, по 64 МБ) при старте, а затем переиспользуется.
Поведение на уровне gRPC: gRPC под капотом использует механизм grpc_slice. Память под входящие фреймы берется из внутреннего пула буферов и туда же возвращается. Мы увидим интенсивный инкремент/декремент счетчиков ссылок (Reference Counting) на куски памяти, но не реальное выделение у ОС.
Поведение на уровне Protobuf: Современный gRPC использует google::protobuf::Arena. Объект запроса создается внутри заранее выделенного куска памяти (арены). После отправки ответа вся арена сбрасывается одной инструкцией (сдвигом указателя) без вызова деструкторов для каждого поля.
Кастомная хэш-таблица: На графике Live Memory мы увидим стабильную ровную линию. Так как это flat_hashmap, данные лежат плотно в больших массивах. Перевыделение памяти (rehash) будет происходить только при скачкообразном росте количества ключей.
Резюме: Что мы увидим в итоге?
Мы увидим классический паттерн CPU-bound системы.
По памяти: Идеальная «пила» или ровная полка благодаря аренам. Никакого фрагментирования RAM, минимум работы с кучей (Heap).
По процессору: Жуткий оверхед на «сериализацию/демультиплексирование» gRPC, который база может себе позволить только благодаря тому, что сама хэш-таблица за счет prefetch практически не тратит процессорное время на ожидание RAM.
Если бы мы убрали gRPC и заменили его на простой бинарный протокол поверх TCP без мультиплексирования (но с пайплайном), производительность этой же базы на чтение легко улетела бы за 200 000–300 000+ RPS на одном ядре, так как освободилось бы больше половины CPU.
gRPC предлагает заменить на свой бинарный протокол, но тогда и мультиплексир самому придется делать, хотя может быть есть уже готовые инструменты для упаковки-распаковки пакетов (но вам надо не просто их рядом друг за другом, а с прореживанием).
Рефлексия делает язык намного гибче и приятнее в использовании для обычных разработчиков. Сериализация, десериализация, логирование и вообще вся обработка объектов значительно упрощаются, и главное — реализуются средствами самого языка. Рефлексия — очень мощный инструмент, и я уверен, что разработчики еще много лет будут придумывать неожиданные применения для нее. Ее синтаксис вначале может показаться сложным. Но после работы над этим проектом для меня он весьма очевиден и логичен.
ну да, ну да. Будет вам за 35, так настоеб-ин это дмо, что... только go.
ответ (скопирую текст просто, чтобы картинку не вставлять):
Вы абсолютно правы и заметили важную неточность в логике описанного текстового примера.
Эмбеддинг (вектор признаков) считать второй раз обязательно нужно.
Чтобы понять, почему автор статьи выразился некорректно, и как алгоритм работает на самом деле, разберем процесс по шагам:
Что происходит при повторном въезде автомобиля:
Детекция: YOLO находит машину на видео и вырезает номерной знак (или силуэт).
Распознавание номера (OCR): Алгоритм считывает текст номера (например, «А123БТ777»).
Запрос в Redis: Система проверяет, есть ли в базе этот номер. Находит старый лог и сохраненный ранее «эталонный» вектор машины.
⚠️ Расчет нового эмбеддинга (Ваш вопрос): Нейросеть (например, CLIP) обязана заново обработать текущий кадр и получить вектор машины прямо сейчас. Без этого системе просто не с чем будет сравнивать вектор из базы.
Сравнение: Новый вектор сравнивается со старым из Redis по косинусному расстоянию. Если они похожи (например, совпадение > 80%), шлагбаум открывается.
Почему автор написал, что «модель не вызывается»?
Это некорректная формулировка в тексте статьи. Автор перепутал или объединил два разных понятия:
Модель извлечения эмбеддингов (CLIP/ResNet) — ВЫЗЫВАЕТСЯ. Она работает при каждом кадре/въезде, чтобы получить вектор для сравнения.
Модель классификации / Сложнейшая аналитика — НЕ ВЫЗЫВАЕТСЯ. Скорее всего, имелось в виду, что тяжелой нейросети не нужно заново определять марку, точный цвет, год выпуска, искать царапины или сверять авто по огромной внешней базе данных. Все эти метаданные уже привязаны к ID в Redis и мгновенно подтягиваются по ключу.
В чем тогда экономия?
Экономия ресурсов происходит не в момент работы CLIP, а в архитектуре:
Вы экономите на тяжелых классификаторах (не нужно запускать модели классификации марок/цветов).
Если бы номера не было (кейс с медведем в лесу), то расчет эмбеддинга CLIP (условно 10 мс) + поиск в Redis (1 мс) работает в разы быстрее, чем полноценный повторный трекинг и CV-анализ объекта с нуля.
Если вам интересно, мы можем детальнее разобрать оптимизацию кода из статьи или обсудить, как правильно настроить поиск по векторам в Redis. Что именно из этого стоит рассмотреть подробнее?
Приветствую. Сначала выбрать модель получения данных push - инициатива отправителя передать данные, или pull - сервер (ваше приложение) само опрашивает все контроллеры и прочее. Выбрать надо только одну модель, обе не стоит брать (по-крайней мере сразу). Я бы выбрал push модель. А для тех контроллеров, которые ждут чтобы к ним обращались за данными, сделал бы отдельные прокси-программы, которые занимаются их опросом. И здеь важно, что не классы внутри сервера, а именно отдельные исполняемые модули, можно их на скриптовом языке написать для удобства, у них задачка не большая - обращаться к контроллеру периодич-ки и на сервер пересылать.
Дальше, прием данных на сервере. Предлагаю делать через промежуточный циклический буфер, размер расчитывать по времени и объема, пусть на 10 мин, например. Соотвественно, контроллеры присылают данные в разных потоках пусть, пишут каждый в свою позицию в буфере. В другом потоке вы идете по тому же буферу и данные дальше как-то используете - показывайте на экране, сохр в БД и прочее.
не может человек с типом личности как у Миронова играть человека с предпринимательской жилкой.
причем здесь может- не может. Это же кино. Есть такая вещь называется "нравится". Мне вот кино с Мироновым больше нравится, еще нравится когда там текст мигает "это ему кажется", нравится именно своим наличием.
Господа, это вооще - кринж! (слабонервным не открывать)
ну справедливоси ради, дело-то ведь не в руби и не качестве кода, видно по рассказу, что торопились и писали быстро.
что просто пожмотничали покупать готовые данные!
да, в этом все дело. Пожмотил заказчик, а исполнители в лице автора рады бы были спокойно читать файлы готовые xml, а не идти "путем пирата" и вот это все. если б по-нормальному вытаскивали данные с биржи, то было бы время о качестве кода думать и прочем.
Подписывайтесь на канал Технолог Петухов там без цензуры
Подписываемся!
PS: ну нельзя же так. следите немного за языком. у вас не прогеры разве пишут Nordwin и тд. считайте, что вы своих прогеров вот так вот обесценили всех, соотв-но можно подумать и о том, что там они написали, с таким отношением сверху.
упираюсь иногда и так, в этот момент у коллег можно совета спросить, или где-то почерпнуть инфу, не важно. llm сейчас - она про скорость разработки, а не про качество. Как только писание станет никому не нужно, я это замечу, наверно, посыплю голову пеплом и возьму с полки пачку ваших агентов (или что там будет уже на тот момент), или думаете не разберусь потом, я не вижу там ниче сложного.
Еще дополню. Мебель ручной работы посмотрите сколько стоит. Вот с разработкой также будет.
Все просто. Мы с вами ставим на разные "лошади", так сказать. Я ставлю на то, что от ваших услуг рано или поздно (лучше позднее конечно, дороже будет) откажутся, тк вы обоср-сь упретесь в возможности своих агентов, и кусок грязи код ваших агентов придется кому-то править, поддерживать и в итоге переписывать подчистую, - и тут найдут меня, который еще может руками написать, сам.
ллм тоже пользуюсь к слову, но не в таком режиме, а как so продвинутым. бойлерплейт пишется и так не включая головы и достаточно быстро - в теч дня, ну да, не минуты, ну и ладно, некуда торопиться.
на фрилансе и раньше писали достаточно быстро простые вещи, сам заказывал когда-то (давно было, точно до всяких кодопомогаек) сайт магазина, за неделю мне сделали помню.
Приветствую. Делал похожее (пока забросил), напишу свои отличия, может пригодится кому:
- у меня воркеры не лазили в БД, а получали задачи от шедулера. Шедулеров могло быть несколько, у каждого свои воркеры. Воркер не имел доступа к БД, все обновления статусов задач - через шедулер.
- шедулеры занимались пуллингом задач из БД, но с помощью триггеров (на таблице задач висел триггер на появление новых записей).
- задача представляла из себя скрипт (на python либо bash), хранились скрипты задач тоже в БД, в таблице шаблонов
- воркер запускал для каждой задачи дочерний процесс, соотв-но все свои задачи выполнял параллельно.
- воркер ничего не знал конкретно о задаче, кроме скрипта и параметров, и не был как-то специализирован на конкретный вид задач. Соответственно любой воркер мог взять любую задачу. Результат и прогресс выполнения задачи воркер отправлял своему шедулеру.
- если воркер не отвечает, все задачи этого воркера будут перекинуты шедулером на другой воркер, без какого-либо участия БД в этом процессе.
.
На самом деле таких преподавателей еще поискать, которые выше уровня ллм могут что-то хотя бы дополнить. И на всех таких преподаватетей не хватит, поэтому основной массе обучающихся ллм впору, с другой стороны стало лучше-проще знания получать, чем без ллм было до этого.
Главное сохранять любознательность, стремиться научиться, а не отсидеть время.
ну дай бог. лень самому проверять. а кстати, ссылки не вижу на ваш проект, или код не хотите открывать?
Приветствую.
Нагрузка на CPU будет у вас высокая из-за мультиплр-я и grpc, на полезную работу может проца не хватать, по памяти тоже с запасом всегда будете потреблять (но на таких объемах rpc может и ладно).
Спросил у гугл-ии.
если посмотреть загрузку cpu и выделение памяти, что увидим?
Если мы запустим профилировщик (например, perf для CPU и je_prof / valgrind massif для памяти) под максимальной нагрузкой в 85 000+ RPS, то увидим очень специфическую картину. Она наглядно покажет, какую «цену» HurriCache платит за мультиплексирование gRPC.
Вот детальный расклад того, что отобразится на графиках и в FlameGraph.
1. Профиль загрузки CPU (Куда уходят такты процессора)
В отличие от классического Redis, где 80-90% CPU уходит на логику базы данных и простую обработку TCP-сокетов, в HurriCache картина разделится примерно 50/50 или даже 60/40 в пользу сетевого оверхеда.
Что покажет FlameGraph (топ горячих функций):
~45–55% CPU — Экосистема gRPC и HTTP/2:
grpc_core::HeaderTableи функции парсингаHPACK(сжатие/декомпрессия заголовков HTTP/2).grpc_core::chttp2::ParsingState— нарезка потока на фреймы, разбор 9-байтовых заголовков и валидация Stream ID.grpc::protobuf::Parser— десериализация бинарного потока Protobuf в C++ структуры сообщений.Функции управления окнами (
Flow Control) и отправкиWINDOW_UPDATE.~30–35% CPU — Кастомная хэш-таблица (Бизнес-логика):
Вычисление хэш-функций (например, MurmurHash или CityHash).
Сравнение ключей в памяти.
Примечание: Строки, связанные с ожиданием памяти (инструкции
prefetch), будут занимать минимум времени процессора, так как CPU не уходит в Stall (простой), а молотит полезную работу.~10–15% CPU — Системные вызовы ядра Linux:
epoll_wait,recvmsg,sendmsg— чтение и запись в сетевые сокеты.Общий вывод по CPU: Процессор будет загружен «под полку» (близко к 100% на задействованных ядрах). При этом gRPC будет буквально пожирать такты на обслуживание структуры стримов и демультиплексирование, подтверждая ваши опасения.
2. Выделение и освобождение памяти (Аллокации)
Если бы автор HurriCache использовал стандартный gRPC и стандартный
std::allocator«из коробки», база данных захлебнулась бы в аллокациях (Memory Churn). На каждый из 85 000 запросов в секунду выделялись бы десятки объектов.Но поскольку это MVP высоконагруженной системы, профилировщик памяти покажет работу арен памяти (Memory Arenas), о которых автор вскользь упомянул в статье.
Что покажет профиль аллокаций (
malloc/freeв секунду):Почти нуль (0) реальных системных вызовов
malloc/freeво время работы. Если база делаетmallocна каждый запрос при 85K RPS — она ложится. Вместо этого мы увидим, что память выделяется крупными блоками (например, по 64 МБ) при старте, а затем переиспользуется.Поведение на уровне gRPC: gRPC под капотом использует механизм
grpc_slice. Память под входящие фреймы берется из внутреннего пула буферов и туда же возвращается. Мы увидим интенсивный инкремент/декремент счетчиков ссылок (Reference Counting) на куски памяти, но не реальное выделение у ОС.Поведение на уровне Protobuf: Современный gRPC использует
google::protobuf::Arena. Объект запроса создается внутри заранее выделенного куска памяти (арены). После отправки ответа вся арена сбрасывается одной инструкцией (сдвигом указателя) без вызова деструкторов для каждого поля.Кастомная хэш-таблица: На графике
Live Memoryмы увидим стабильную ровную линию. Так как этоflat_hashmap, данные лежат плотно в больших массивах. Перевыделение памяти (rehash) будет происходить только при скачкообразном росте количества ключей.Резюме: Что мы увидим в итоге?
Мы увидим классический паттерн CPU-bound системы.
По памяти: Идеальная «пила» или ровная полка благодаря аренам. Никакого фрагментирования RAM, минимум работы с кучей (Heap).
По процессору: Жуткий оверхед на «сериализацию/демультиплексирование» gRPC, который база может себе позволить только благодаря тому, что сама хэш-таблица за счет
prefetchпрактически не тратит процессорное время на ожидание RAM.Если бы мы убрали gRPC и заменили его на простой бинарный протокол поверх TCP без мультиплексирования (но с пайплайном), производительность этой же базы на чтение легко улетела бы за 200 000–300 000+ RPS на одном ядре, так как освободилось бы больше половины CPU.
gRPC предлагает заменить на свой бинарный протокол, но тогда и мультиплексир самому придется делать, хотя может быть есть уже готовые инструменты для упаковки-распаковки пакетов (но вам надо не просто их рядом друг за другом, а с прореживанием).
ну да, ну да. Будет вам за 35, так настоеб-ин это дмо, что... только go.
боты или сотрудники плюсуют, не иначе.
и минусуют неугодных.
ruvds, наставьте плюсиков лучше комменту выше, что вам жалко чтоли)
Приветствую.
Отвечу вам той же монетой:
мой вопрос в гугл ии :
https://habr.com/ru/companies/ruvds/articles/1033870/прочитай эту статью. Я здесь не понял, почему не надо второй раз расчитывать эмбединг для машины со слакбаумом.Всеранвно ведь надо второй раз посчитать?
ответ (скопирую текст просто, чтобы картинку не вставлять):
Вы абсолютно правы и заметили важную неточность в логике описанного текстового примера.
Эмбеддинг (вектор признаков) считать второй раз обязательно нужно.
Чтобы понять, почему автор статьи выразился некорректно, и как алгоритм работает на самом деле, разберем процесс по шагам:
Что происходит при повторном въезде автомобиля:
Детекция: YOLO находит машину на видео и вырезает номерной знак (или силуэт).
Распознавание номера (OCR): Алгоритм считывает текст номера (например, «А123БТ777»).
Запрос в Redis: Система проверяет, есть ли в базе этот номер. Находит старый лог и сохраненный ранее «эталонный» вектор машины.
⚠️ Расчет нового эмбеддинга (Ваш вопрос): Нейросеть (например, CLIP) обязана заново обработать текущий кадр и получить вектор машины прямо сейчас. Без этого системе просто не с чем будет сравнивать вектор из базы.
Сравнение: Новый вектор сравнивается со старым из Redis по косинусному расстоянию. Если они похожи (например, совпадение > 80%), шлагбаум открывается.
Почему автор написал, что «модель не вызывается»?
Это некорректная формулировка в тексте статьи. Автор перепутал или объединил два разных понятия:
Модель извлечения эмбеддингов (CLIP/ResNet) — ВЫЗЫВАЕТСЯ. Она работает при каждом кадре/въезде, чтобы получить вектор для сравнения.
Модель классификации / Сложнейшая аналитика — НЕ ВЫЗЫВАЕТСЯ. Скорее всего, имелось в виду, что тяжелой нейросети не нужно заново определять марку, точный цвет, год выпуска, искать царапины или сверять авто по огромной внешней базе данных. Все эти метаданные уже привязаны к ID в Redis и мгновенно подтягиваются по ключу.
В чем тогда экономия?
Экономия ресурсов происходит не в момент работы CLIP, а в архитектуре:
Вы экономите на тяжелых классификаторах (не нужно запускать модели классификации марок/цветов).
Если бы номера не было (кейс с медведем в лесу), то расчет эмбеддинга CLIP (условно 10 мс) + поиск в Redis (1 мс) работает в разы быстрее, чем полноценный повторный трекинг и CV-анализ объекта с нуля.
Если вам интересно, мы можем детальнее разобрать оптимизацию кода из статьи или обсудить, как правильно настроить поиск по векторам в Redis. Что именно из этого стоит рассмотреть подробнее?
вот и надо было про внутр кухню больше написать, а не скрины делать где какой флажек нажать, чтобы собрать в clion.
про память на жест диске. не на то вы внимание обращаете совсем, важнее сколько опер памяти берет, а брать будет как и электрон, скорее всего.
Смотрим код
Смотрим что такое WebView2
В общем, в статье речь не о том, что надо бы осветить.
Приветствую.
Сначала выбрать модель получения данных push - инициатива отправителя передать данные, или pull - сервер (ваше приложение) само опрашивает все контроллеры и прочее.
Выбрать надо только одну модель, обе не стоит брать (по-крайней мере сразу).
Я бы выбрал push модель.
А для тех контроллеров, которые ждут чтобы к ним обращались за данными, сделал бы отдельные прокси-программы, которые занимаются их опросом. И здеь важно, что не классы внутри сервера, а именно отдельные исполняемые модули, можно их на скриптовом языке написать для удобства, у них задачка не большая - обращаться к контроллеру периодич-ки и на сервер пересылать.
Дальше, прием данных на сервере. Предлагаю делать через промежуточный циклический буфер, размер расчитывать по времени и объема, пусть на 10 мин, например.
Соотвественно, контроллеры присылают данные в разных потоках пусть, пишут каждый в свою позицию в буфере.
В другом потоке вы идете по тому же буферу и данные дальше как-то используете - показывайте на экране, сохр в БД и прочее.
вот пример буфера вам
https://github.com/Tyill/SVisual/blob/master/src/SVServer/src/buffer_data.cpp
причем здесь может- не может. Это же кино.
Есть такая вещь называется "нравится".
Мне вот кино с Мироновым больше нравится, еще нравится когда там текст мигает "это ему кажется", нравится именно своим наличием.
ну справедливоси ради, дело-то ведь не в руби и не качестве кода, видно по рассказу, что торопились и писали быстро.
да, в этом все дело. Пожмотил заказчик, а исполнители в лице автора рады бы были спокойно читать файлы готовые xml, а не идти "путем пирата" и вот это все.
если б по-нормальному вытаскивали данные с биржи, то было бы время о качестве кода думать и прочем.
Зашел и почитал. Дальше будут скрины:
смотрим исходники
общая картина - активности за год не много, наверно, все уже готово и налажено
смотрим проект 4diac-force. Видим 1 инит комит 9мес назад
несколько файлов потыкал - во всех Profactor GmbH, ACIN, fortiss GmbH
кто такие эти Profactor GmbH, ACIN, fortiss GmbH
Вопрос. Где здесь Северсталь собственно?
Недоработка однако
Шучу. Похоже на чудо блин, если реально так моделит двигатель.
Подписываемся!
PS: ну нельзя же так. следите немного за языком. у вас не прогеры разве пишут Nordwin и тд. считайте, что вы своих прогеров вот так вот обесценили всех, соотв-но можно подумать и о том, что там они написали, с таким отношением сверху.
упираюсь иногда и так, в этот момент у коллег можно совета спросить, или где-то почерпнуть инфу, не важно.
llm сейчас - она про скорость разработки, а не про качество.
Как только писание станет никому не нужно, я это замечу, наверно, посыплю голову пеплом и возьму с полки пачку ваших агентов (или что там будет уже на тот момент), или думаете не разберусь потом, я не вижу там ниче сложного.
Еще дополню. Мебель ручной работы посмотрите сколько стоит. Вот с разработкой также будет.
Все просто. Мы с вами ставим на разные "лошади", так сказать.
Я ставлю на то, что от ваших услуг рано или поздно (лучше позднее конечно, дороже будет) откажутся, тк вы
обоср-сьупретесь в возможности своих агентов, икусок грязикод ваших агентов придется кому-то править, поддерживать и в итоге переписывать подчистую, - и тут найдут меня, который еще может руками написать, сам.ллм тоже пользуюсь к слову, но не в таком режиме, а как so продвинутым.
бойлерплейт пишется и так не включая головы и достаточно быстро - в теч дня, ну да, не минуты, ну и ладно, некуда торопиться.
на фрилансе и раньше писали достаточно быстро простые вещи, сам заказывал когда-то (давно было, точно до всяких кодопомогаек) сайт магазина, за неделю мне сделали помню.
Электронной версии книги не увидел на вашем сайте, а если б была - купил бы. (уже давно не читаю бумажные учебники, думаю, не я один такой).
Приветствую.
Делал похожее (пока забросил), напишу свои отличия, может пригодится кому:
- у меня воркеры не лазили в БД, а получали задачи от шедулера.
Шедулеров могло быть несколько, у каждого свои воркеры.
Воркер не имел доступа к БД, все обновления статусов задач - через шедулер.
- шедулеры занимались пуллингом задач из БД, но с помощью триггеров (на таблице задач висел триггер на появление новых записей).
- задача представляла из себя скрипт (на python либо bash), хранились скрипты задач тоже в БД, в таблице шаблонов
- воркер запускал для каждой задачи дочерний процесс, соотв-но все свои задачи выполнял параллельно.
- воркер ничего не знал конкретно о задаче, кроме скрипта и параметров, и не был как-то специализирован на конкретный вид задач.
Соответственно любой воркер мог взять любую задачу.
Результат и прогресс выполнения задачи воркер отправлял своему шедулеру.
- если воркер не отвечает, все задачи этого воркера будут перекинуты шедулером на другой воркер, без какого-либо участия БД в этом процессе.
Вот основные вроде отличия.
Скрытый текст
Все работает без впн. Браузер для новостей не плохо заменяет.