Объясните шаблон "Лидер / Последователь"

Question

Я не могу найти хорошее и доступное объяснение паттерна "Лидер / Последователь". Все объяснения либо просто относятся к нему в контексте некоторой проблемы , либо совершенно бессмысленны .

Может ли кто-нибудь объяснить механике , как работает этот шаблон, и почему и как он улучшает производительность по сравнению с более традиционными моделями асинхронного ввода-вывода? Также приветствуются примеры и ссылки на диаграммы.

Answer 1

Как вы, возможно, уже читали, шаблон состоит из 4 компонентов: ThreadPool, HandleSet, Handle, ConcreteEventHandler (реализует интерфейс EventHandler).

Вы можете думать о нем как о станции такси ночью, где всеводители спят, кроме одного, лидера.ThreadPool - это станция, управляющая многими потоками - кабинами.

Лидер ожидает события ввода-вывода в HandleSet, например, как драйвер ожидает клиента.

Когда клиент приходит (вв форме дескриптора, идентифицирующего событие ввода-вывода), водитель-лидер пробуждает другого водителя, который будет следующим лидером, и обрабатывает запрос от своего пассажира.

Пока он доставляет клиента по указанному адресу (вызывает ConcreteEventHandler)и передавая ему ручку) следующий руководитель может одновременно обслуживать другого пассажира.

Когда водитель заканчивает, он берет свое такси обратно на станцию ​​и засыпает, если станция не пуста.В противном случае он станет лидером.

Плюсы для этого шаблона:

• нет необходимости в обмене данными между потоками, не требуется синхронизация или общая память (без блокировок, мьютексов).
• больше ConcreteEventHandlers можно добавлять, не затрагивая другие EventHandler
• минимизирует задержку из-за нескольких потоков

Минусы:

• комплекс
• сетевой ввод-вывод может быть узким местом

Answer 2

Я хочу добавить к ответу Джейка, связав другой PDF-документ того же автора, в котором подробно описан случай использования, в котором они выбрали шаблон «Лидер / Подписчик» среди других альтернатив: http://www.dre.vanderbilt.edu/~schmidt/PDF/OM-01.pdf

Answer 3

Я думаю, что самый «практический» пример - фузианский пассажир и рельсовое приложение. (Вид вводящего в заблуждение пассажира на самом деле является процессом apache mod_rails, который управляет многими приложениями ruby, которые спят / припаркованы).

Итак, вы разрабатываете приложение rails или приложение sinatra. Затем разверните его на веб-сервере с установленным пассажиром.

Лидером на самом деле является балансировщик нагрузки пассажиров. Пассажир - это кто-то, посещающий веб-страницу. Такси - это спящие экземпляры вашего приложения для рельсов в пуле устройств для пассажиров.

При установке этого пула на 45 (database.yml в приложении rails). Ваше высказывание, я хочу 45 такси, готовых обслуживать веб-страницы. Когда кто-то посещает виртуальный хост, пассажир передает запрос одному из 45 приложений ожидающих рельсов. Приложениям не нужно взаимодействовать друг с другом, потому что все они подключены к одному и тому же бэкэнду базы данных (или несколько тоже возможно, если вы выполняете репликацию ваших данных).

http://www.modrails.com/.

Круто то, что хотя отдельным процессам может потребоваться некоторое время для обработки запроса, общая система действительно эффективна / быстра, потому что у вас есть 45 из них, готовых для обработки запросов. Таким образом, даже если первое такси (приложение rails) не вернулось с пути (обслуживает запрошенную страницу), второй ожидающий экземпляр в очереди можно использовать для следующего запроса. Как только первый завершается, он также возвращается в очередь, и таким образом вы можете быть отзывчивыми и легко получить 4000+ страниц / сек, даже если одно приложение rails может обрабатывать только 400 рег / сек. Конечно, существуют ограничения (объем памяти и т. Д. Для размера пула, в противном случае вы можете взять пул размером 200000 приложений rails), но на практике это работает очень хорошо ...

Answer 4

http://www.kircher -schwanninger.de / michael / публикации / lf.pdf Лучшее, что я могу сделать для тебя.