Спасибо за статью. Скажите, а в какую сторону Вы бы смотрели, решая вот такую задачу, подойдёт ли тут ZooKeeper?
В сети на разных серверах есть N совершенно одинаковых исполнителей (сейчас N около 150). Во всякий момент времени есть список задач (коих всегда разное количество, но меньше, чем N). Надо, чтобы исполнители «разобрали на себя» задачи из списка, т. е. каждой из задач соответствовал бы свой исполнитель. Исполнитель не может взять больше одной задачи. Одну задачу потенциально могут взять два исполнителя, но это нежелательно. Исполнители могут как «отваливаться» по той или иной причине, так и приходить новые в пул, и надо чтобы как можно быстрее задачу у «отвалившегося» исполнителя перехватывал другой исполнитель, т. е. ни одной задачи без исполнителя оставлять нельзя.
Вот сейчас на ключах с TTL в Redis-е у меня реализован самодельный алгоритм. Но (на то он и самодельный) по нему случается, что за задачу «хватается» больше одного исполнителя.
Насколько подобная задача стандартна, чем её лучше всего решать?
Несколько лет назад я решал подобную задачу, реализуя алгоритм FastMatch, описанный здесь: http://ilpubs.stanford.edu:8090/115/1/1995-46.pdf На выходе получался скрипт с перечислением команд, которые нужно произвести с деревом в начальном состоянии, чтобы получить дерево в конечном состоянии, и причём авторы алгоритма стремились к тому, чтобы этот скрипт был близок к минимально возможному по длине.
У вас ноды идентифицируются своими номерами, все номера разные. А разве двух нерализичимых нод не может оказаться в двух местах дерева?
На той версии тренинга, где я был, упор был на фронт, про юнит- и интеграционные тесты говорилось меньше — но это, как мне кажется, как раз из-за того, что тренинг был однодневный и всего не уместить. Но там рассматривалось и много общих вопросов: преимущества и область применимости автотестирования, выбор testing strategy, организация командной работы и т. п.
По поводу тренинга Николая Алименкова: полгода назад мы были на этом тренинге в составе трёх человек от маленькой компании (~10 разработчиков). Целью было понять, что мы делаем не так и «как нам обустроить процесс автотестирования». Польза вышла очень большая, постановка тестирования у нас сегодня по сравнению с тем, что было полгода назад — небо и земля. Так что — зело рекомендую.
Ну и как человек, ходивший на этот тренинг в однодневном формате, завидую тем, кто сразу пойдёт на двухдневный: там явно материала на два дня!
Да, я знаю, что D/D/1 не вылетает в бесконечность при $\lambda=\mu$, но в статье про это не написал: мне кажется, что детерминированный источник это скорее абстракция) И это точно не наш случай: я, к сожалению, не могу тут рассказать конкретику, но источник событий у нас — самый что ни на есть классический пуассоновский. Мы должны улавливать внешние по отношению к системе события, и на их частоту мы влиять никак не можем.
Да вот и я так же думал, а оказалось, что ошибался! Про то и статья. Видимо, всё-таки недостаточно ясно изложил.
Оказывается, что на заданном интервале времени количество обрабатываемых заданий должно быть существенно больше количества генерируемых. Тогда будет хорошо.
Если же, как Вы пишете, имеет место «одинаковое количество обработанных и сгенерированных, или несколько больше» — то будет иметь место близость к точке насыщения и система пойдёт вразнос, что мы и наблюдали. Это простое, но контринтуитивное следствие теории очередей. Вот чего я хотел бы знать раньше!
Что вы, я в этой заметке, можно сказать, вообще без математики обошёлся — если посмотреть, сколько её в теории очередей. В чём помогла: помогла тем, что стало абсолютно ясно происходящее в системе. Вот, вроде бы, быстрый сервер, вроде его пропускная способность адекватна поступающему потоку. Но ожидание в очереди велико. Можем ли мы что-то сделать? Оказалось — ещё как можем, т. к. мы находимся около точки насыщения.
Выше высказывали эту мысль. Как в кассах супермаркета. Я согласен, это имеет смысл, когда воркер обходится небесплатно. В нашем случае — надо найти оптимальное количество воркеров, дающее максимальную пропускную способность (ограниченную вышеупомянутым universal scalability law).
Вопрос №1: За счёт кэширования срезал ненужные обращения к БД (там не только Redis, но и реляционка у нас и было что подоптимизировать).
Вопрос №2: Даа, всё это можно, но там потоки начнут лочить друг у друга запись в БД и их увеличение не приводит к увеличению пропускной способности сервиса. В своё время решили остановиться на трёх, хотя эксперименты с увеличением обработчиков ещё можно было бы провести. Идея с «балансировщиком» хороша лишь до некоторой степени: вы про закон Амдала и его обощение — Universal Scalability Law слышали? Распараллеливание обработчиков нельзя делать бесконечно: начиная с какого-то момента оно становится бесполезным, а потом в какой-то момент и вредным, т. е. есть оптимальное число распараллеливания, за которое переступать нельзя.
Нет-нет! В нашем случае именно что задания долго ждали в очереди (красный цвет на круговых диаграммах), как раз из-за того, что пропускная способность сервера была лишь немного выше частоты поступления заданий. Поэтому оптимизация алгоритма работы сервера поменяла картину кардинально.
Да, у нас Redis и для очереди мы как раз используем Redis list. Впрочем, к смыслу статьи это отношения не имеет, т. к. это могло быть что угодно: ApacheMQ, Rabbit, Kafka или самописный linked list — всё это подчиняется общим законам ))
Мысль с LIFO я вообще не понял. LIFO — это не очередь, а стек всё-таки. И я не понял, при чём тут LIFO.
Возможно, в данном случае всё не так или не совсем так, но по своему опыту я знаю, почему это зачастую бывает.
Служба безопасности Заказчика, Которого К Сожалению Нельзя Называть, ещё не одобрила использование Java8. А ещё они держат огромный штат машин на Windows XP с IE7, и требуют от поставщиков ПО совместимости с устаревшими ОС и браузерами. В данной ситуации хорошо и сотрудникам СБ Заказчика, занятым «полезной деятельностью», и Исполнителю — «любой каприз за ваши деньги». AndyKy, у вас не так?
Всё это шапито продолжается бесконечно, а потом все удивляются, как это WannaCry и Petya могут наводить такой шорох в серьёзных конторах. Да вот так.
И действительно забавно в 2017 году читать на Хабре про Java6.
Ну и любой отчёт о Гейзенбаге-2 будет неполным без упоминания доклада Леонида Руденко «Java → Kotlin: пишите тесты проще», который собрал такой аншлаг в малом зале, что людям приходилось на полу в проходах сидеть! Тема, действительно, интересная, и возможно что для многих Котлин зайдёт в команду сначала как язык написания тестов.
Ну а вообще — спасибо за Гейзенбаг! Новая версия по контенту для меня как разработчика и тимлида стала ещё лучше и полезнее, так держать!
Прочитал вашу статью, приступил к работе. Приходит письмо с предложением созвониться «tomorrow at 2pm MLT».
Захожу на этот ваш EveryTimeZone: Гонолулу, Сан-Франциско… пытаюсь понять, как же мне выставить пояса MSK и MLT… но ничего не выходит. Буллшит, господа! пришлось вернуться на старый добрый time.yandex.ru!
Да много их, много. И главное, уже очень много таких, которые действительно красиво решают задачу раскладки графа на плоскости.
Однако довольно часто на практике сделать своё маленькое, но идеально решающее твою задачу решение бывает лучше, чем использовать готовый большой фреймворк, который всё равно тебе подойдёт неидеально. Я пару раз встречался с таким, когда деньги тратились, чтобы купить лицензии на готовые граф-библиотеки, потом писался монструозный код-обвеска, а потом оказывалось, что нужного поведения всё равно не получается )) да плюс чужие баги))
Ещё при решении этой задачи красиво применяются паттерны ООП: композиция и делегирование.
Спасибо за статью! Мы как раз сейчас в development-е работаем с single instance Redis-а, а в продакшн придётся, по-видимому, поднимать кластер.
Несколько вопросов:
1) О какой нагрузке в вашем случае идёт речь (например, в одновременных подключениях / в запросах в секунду)? (интересует граница, за которой сингл-инстанс с записью на диск становится неприменим)
2) Итак, я правильно понимаю, что минимальная осмысленная конфигурация кластера — 6 нод: 3 мастера/3 слейва и при сбое мастера он автоматом переконфигурируется для использования соответствующего слейва в качестве мастера?
3) А как выглядит подключение к кластеру в Java-коде, допустим? (Какой драйвер используете, кстати?) В качестве параметра подключения указывается массив IP-адресов?
Присоединяюсь к благодарностям за конференцию! Было полезно!
Смотрели с коллегой по трансляции. Мои пожелания (как разработчика, а не специалиста по тестированию): хочется слышать ещё меньше теоретизирования, ещё больше практики, практики и практики с реальными инструментами.
И по всем вашим конференциям с позиции онлайн-зрителя: 1) ещё надёжнее трансляции — финальный кейноут да, оказался испорчен ))) 2) и ещё — было бы круто, если бы у интернет-аудитории была возможность «передавать записки» спикеру через твиттер какой-нибудь или как-нибудь.
(Впрочем, если в следующем году будет в Москве Гейзенбаг — мы, скорее всего, уже придём «в оффлайне».)
В сети на разных серверах есть N совершенно одинаковых исполнителей (сейчас N около 150). Во всякий момент времени есть список задач (коих всегда разное количество, но меньше, чем N). Надо, чтобы исполнители «разобрали на себя» задачи из списка, т. е. каждой из задач соответствовал бы свой исполнитель. Исполнитель не может взять больше одной задачи. Одну задачу потенциально могут взять два исполнителя, но это нежелательно. Исполнители могут как «отваливаться» по той или иной причине, так и приходить новые в пул, и надо чтобы как можно быстрее задачу у «отвалившегося» исполнителя перехватывал другой исполнитель, т. е. ни одной задачи без исполнителя оставлять нельзя.
Вот сейчас на ключах с TTL в Redis-е у меня реализован самодельный алгоритм. Но (на то он и самодельный) по нему случается, что за задачу «хватается» больше одного исполнителя.
Насколько подобная задача стандартна, чем её лучше всего решать?
У вас ноды идентифицируются своими номерами, все номера разные. А разве двух нерализичимых нод не может оказаться в двух местах дерева?
Ну и как человек, ходивший на этот тренинг в однодневном формате, завидую тем, кто сразу пойдёт на двухдневный: там явно материала на два дня!
Да, я знаю, что D/D/1 не вылетает в бесконечность при $\lambda=\mu$, но в статье про это не написал: мне кажется, что детерминированный источник это скорее абстракция) И это точно не наш случай: я, к сожалению, не могу тут рассказать конкретику, но источник событий у нас — самый что ни на есть классический пуассоновский. Мы должны улавливать внешние по отношению к системе события, и на их частоту мы влиять никак не можем.
Оказывается, что на заданном интервале времени количество обрабатываемых заданий должно быть существенно больше количества генерируемых. Тогда будет хорошо.
Если же, как Вы пишете, имеет место «одинаковое количество обработанных и сгенерированных, или несколько больше» — то будет иметь место близость к точке насыщения и система пойдёт вразнос, что мы и наблюдали. Это простое, но контринтуитивное следствие теории очередей. Вот чего я хотел бы знать раньше!
Вопрос №2: Даа, всё это можно, но там потоки начнут лочить друг у друга запись в БД и их увеличение не приводит к увеличению пропускной способности сервиса. В своё время решили остановиться на трёх, хотя эксперименты с увеличением обработчиков ещё можно было бы провести. Идея с «балансировщиком» хороша лишь до некоторой степени: вы про закон Амдала и его обощение — Universal Scalability Law слышали? Распараллеливание обработчиков нельзя делать бесконечно: начиная с какого-то момента оно становится бесполезным, а потом в какой-то момент и вредным, т. е. есть оптимальное число распараллеливания, за которое переступать нельзя.
Да, у нас Redis и для очереди мы как раз используем Redis list. Впрочем, к смыслу статьи это отношения не имеет, т. к. это могло быть что угодно: ApacheMQ, Rabbit, Kafka или самописный linked list — всё это подчиняется общим законам ))
Мысль с LIFO я вообще не понял. LIFO — это не очередь, а стек всё-таки. И я не понял, при чём тут LIFO.
Служба безопасности Заказчика, Которого К Сожалению Нельзя Называть, ещё не одобрила использование Java8. А ещё они держат огромный штат машин на Windows XP с IE7, и требуют от поставщиков ПО совместимости с устаревшими ОС и браузерами. В данной ситуации хорошо и сотрудникам СБ Заказчика, занятым «полезной деятельностью», и Исполнителю — «любой каприз за ваши деньги». AndyKy, у вас не так?
Всё это шапито продолжается бесконечно, а потом все удивляются, как это WannaCry и Petya могут наводить такой шорох в серьёзных конторах. Да вот так.
И действительно забавно в 2017 году читать на Хабре про Java6.
Ну а вообще — спасибо за Гейзенбаг! Новая версия по контенту для меня как разработчика и тимлида стала ещё лучше и полезнее, так держать!
Захожу на этот ваш EveryTimeZone: Гонолулу, Сан-Франциско… пытаюсь понять, как же мне выставить пояса MSK и MLT… но ничего не выходит. Буллшит, господа! пришлось вернуться на старый добрый time.yandex.ru!
Однако довольно часто на практике сделать своё маленькое, но идеально решающее твою задачу решение бывает лучше, чем использовать готовый большой фреймворк, который всё равно тебе подойдёт неидеально. Я пару раз встречался с таким, когда деньги тратились, чтобы купить лицензии на готовые граф-библиотеки, потом писался монструозный код-обвеска, а потом оказывалось, что нужного поведения всё равно не получается )) да плюс чужие баги))
Ещё при решении этой задачи красиво применяются паттерны ООП: композиция и делегирование.
Несколько вопросов:
1) О какой нагрузке в вашем случае идёт речь (например, в одновременных подключениях / в запросах в секунду)? (интересует граница, за которой сингл-инстанс с записью на диск становится неприменим)
2) Итак, я правильно понимаю, что минимальная осмысленная конфигурация кластера — 6 нод: 3 мастера/3 слейва и при сбое мастера он автоматом переконфигурируется для использования соответствующего слейва в качестве мастера?
3) А как выглядит подключение к кластеру в Java-коде, допустим? (Какой драйвер используете, кстати?) В качестве параметра подключения указывается массив IP-адресов?
Смотрели с коллегой по трансляции. Мои пожелания (как разработчика, а не специалиста по тестированию): хочется слышать ещё меньше теоретизирования, ещё больше практики, практики и практики с реальными инструментами.
И по всем вашим конференциям с позиции онлайн-зрителя: 1) ещё надёжнее трансляции — финальный кейноут да, оказался испорчен ))) 2) и ещё — было бы круто, если бы у интернет-аудитории была возможность «передавать записки» спикеру через твиттер какой-нибудь или как-нибудь.
(Впрочем, если в следующем году будет в Москве Гейзенбаг — мы, скорее всего, уже придём «в оффлайне».)