Руководство по собеседованию по проектированию системы

интервью Java

Дизайн системы должен быть одной из самых больших головных болей для интервьюеров во время интервью.Поскольку вопросы, связанные с проектированием систем, часто не имеют ответа, на них нет стандартных ответов. Вы постепенно оптимизируете схему проектирования своей системы в обмене идеями и столкновении с интервьюером. Теоретически собеседование по проектированию системы также представляет собой процесс пошагового улучшения исходного плана проектирования системы вместе с интервьюером.

Вопросы о дизайне системы часто позволяют проверить общие способности интервьюируемого.Если вы правильно ответите, вы легко сможете выделиться на собеседовании. Будь то небольшие партнеры, участвующие в социальном наборе или школьном наборе, необходимо обратить на это внимание.

Далее я возьму своих друзей, чтобы рассказать об этом с моей точки зрения:Как подготовиться к разделу системного дизайна интервью.

Из-за ограниченного объема статьи фактические примеры не будут перечислены, а некоторые конкретные примеры могут быть упомянуты отдельно в последующих статьях.

Личные возможности ограничены. Если в статье есть необходимость в доработке и доработке, пожалуйста, укажите это в области комментариев и продвигайтесь вперед вместе!

Каковы общие вопросы на собеседовании по системному проектированию?

Я кратко резюмирую, как задавать вопросы, связанные с собеседованием по проектированию системы:

  1. Разработайте определенную систему, такую ​​как система шипов, система микроблогов, система захвата красных конвертов и система коротких URL.
  2. Разработайте функцию в определенной системе, например, подобную функцию Bilibili.
  3. Разработайте инфраструктуру, такую ​​как инфраструктура RPC, очередь сообщений, инфраструктура кэширования, распределенная файловая система и т. д.
  4. Технический выбор определенной системы, например кэшированиеRedisвсе ещеMemcached, для шлюзаSpring Cloud Gatewayвсе еще Netflix Zuul2.

Как сделать дизайн системы?

Мы суммируем шаги в следующие 4 шага.

Шаг 1: Спросите о конкретных требованиях системы

Когда интервьюер задает вопрос о проектировании системы, не начинайте сразу же разрабатывать решение.Сначала вам нужно понять требования к дизайну системы: функциональные требования и нефункциональные требования.

Чтобы избежать неправильного толкования вопроса, который вы хотите решить, вы можете сначала кратко объяснить свое понимание интервьюеру.

Зачем спрашивать о функциональных требованиях к системе, то есть о том, какие функции содержит система?

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

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

Можете ли вы спроектировать систему Weibo, используемую людьми с мощностью 1 Вт, и систему Weibo, используемую людьми с мощностью 100 Вт? Схемы проектирования систем, соответствующие разным удерживающим системам, безусловно, отличаются.

Шаг 2: Абстрактный дизайн системы

Нам нужно спроектировать систему на высоком уровне.

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

Шаг 3: Рассмотрите моменты, которые система в настоящее время нуждается в оптимизации

После абстрактного проектирования системы необходимо подумать о тех моментах, которые необходимо оптимизировать в текущем абстрактном проектировании системы, например:

  1. Достаточно ли текущей системы, развернутой на одной машине? Нужно ли развертывать его на нескольких машинах, а затем балансировать нагрузку?
  2. Может ли скорость обработки базы данных удовлетворять потребности бизнеса? Нужно ли добавлять индекс к указанному полю? Требуется ли разделение чтения-записи? Вам нужно кешировать?
  3. Достаточно ли велик объем данных, чтобы потребовать подбазу данных и подтаблицу?
  4. Есть ли риски безопасности?
  5. Требуется ли системе распределенная файловая система?
  6. ......

Шаг 4: Оптимизируйте дизайн абстракции вашей системы

Далее улучшите абстрактный дизайн системы в соответствии с «точками, которые система должна быть оптимизирована» на шаге 3.

Как подготовиться к проектированию системы?

Запас знаний

Интервью по проектированию системы очень важно для проверки вашего запаса знаний, а улучшение способностей к проектированию системы требует большого запаса теоретических знаний. Например, вам нужно знать три оси, необходимые для крупномасштабного проектирования архитектуры веб-сайта:

  1. Высокопроизводительный архитектурный дизайн: Знаком с распространенными методами оптимизации производительности системы, такими как внедрениеразделение чтения-записи,тайник, Балансировка нагрузки,асинхронныйи Т. Д.
  2. Архитектура высокой доступности: Теория CAP и теория BASE улучшают общую стабильность системы за счет кластеризации, механизмов тайм-аута и повторных попыток, а также устраняют сбои на уровне интерфейса:понижение рейтинга,предохранитель,Ограничение, очередь.
  3. Архитектура с высокой степенью расширения: Грубо говоря, это значит уметь разделять систему. Когда вы разделяете программные системы по-разному, вы получаете разные архитектуры.

настоящий бой

Хоть я и понимаю теорию, но если сам не буду практиковать, многие вещи не реализуются!

Поэтому вы такжеПродолжайте тренировать свои способности к проектированию систем с помощью практических проектов.

оставайся любопытным

Подумайте больше о том, как часто работают веб-сайты, которые вы посещаете. Например:

  1. Когда вы проводите Weibo, вы можете подумать о том, как Weibo записывает количество лайков?
  2. Когда вы смотрите Bilibili, вы можете подумать о том, как работает система напоминания о сообщениях?
  3. Когда вы используете систему с короткой цепью, вы можете подумать, как это делает система с короткой цепью?
  4. ......

Технический отбор

Для достижения одной и той же функции, как правило, существует множество технических опций, таких как кэширование.Redisвсе ещеMemcached, для шлюзаSpring Cloud Gatewayвсе еще Netflix Zuul2. Во многих случаях интервьюер будет конкретен в выборе технологий в процессе проектирования системы, поэтому вам необходимо различать преимущества и недостатки различных технологий.

Собеседование по проектированию системы должно знать

Проект системы должен быть неотделим от описания показателей, связанных с производительностью, таких как QPS.

метрики, связанные с производительностью

Время отклика

Время отклика RT (время отклика) — это время, необходимое от пользователя, отправляющего запрос, до пользователя, получающего результат обработки системы.

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

параллелизм

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

Количество параллелизма отражает грузоподъемность системы.

QPS и TPS

  • QPS (запросов в секунду): количество запросов, которые сервер может выполнять в секунду;
  • TPS (транзакций в секунду): количество транзакций, обрабатываемых сервером в секунду (под транзакцией здесь можно понимать процесс от клиента, отправляющего запрос на принимающий сервер);

Вот как в книге описывается разница между QPS и TPS.

QPS vs TPS: QPS в принципе похож на TPS, но разница в том, что за одно посещение страницы формируется TPS, но запрос страницы может генерировать несколько запросов к серверу, и сервер может считать эти запросы как "" QPS". Например, при доступе к странице сервер будет запрашиваться дважды. После доступа будет сгенерировано «T» и два «Q».

пропускная способность

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

Пропускная способность системы тесно связана с потреблением ресурсов системы запросами. Чем больше запросов потребляют системные ресурсы, тем ниже пропускная способность системы, и наоборот.

Как TPS, так и QPS обычно используются для количественных показателей пропускной способности.

  • Число запросов в секунду (TPS)= параллелизм / среднее время отклика (RT)
  • параллелизм= Количество запросов в секунду * Среднее время ответа (RT)

системная активность

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

PV(Page View)

Количество посещений, то есть количество просмотров страниц или кликов, измеряет количество веб-страниц, посещенных пользователями веб-сайта; в течение определенного статистического периода каждый раз, когда пользователь открывает или обновляет страницу, это регистрируется один раз, и просмотры страниц накапливаются, когда одна и та же страница открывается или обновляется несколько раз. UV рассчитывается с точки зрения количества открытых/обновленных веб-страниц.

UV(Unique Visitor)

Уникальные посетители, подсчитайте количество пользователей, посетивших сайт в течение 1 дня. Если один и тот же посетитель посещает веб-сайт несколько раз в течение одного дня, он будет учитываться только как один уникальный посетитель. UV подсчитываются с точки зрения отдельных пользователей.

DAU(Daily Active User)

Количество активных пользователей в день.

MAU(monthly active users)

Количество активных пользователей в месяц.

Например: DAU веб-сайта составляет 1200 Вт, среднее ежедневное время использования пользователей составляет 1 час, RT составляет 0,5 с, и рассчитываются параллелизм и число запросов в секунду.

Средний параллелизм = DAU (1200 Вт) * среднее ежедневное время использования (1 час, 3600 секунд) / количество секунд в день (86400) = 1200 Вт/24 = 50 Вт

Реальный параллелизм (учитывая, что количество пользователей относительно невелико в некоторые периоды времени) = DAU (1200w) * среднее ежедневное время использования (1 час, 3600 секунд) / количество секунд в сутках - период времени с относительно небольшим трафиком Предполагается, что 8 часов ( 57600 ) = 1200 Вт / 16 = 75 Вт

Пиковый параллелизм = средний параллелизм * 6 = 300 Вт

QPS = реальный параллелизм/RT = 75W/0.5=100W/s

Общие инструменты тестирования производительности

Обычно используется в бэкенде

Поскольку проектирование системы связано с проблемами производительности системы, во время интервью интервьюер, скорее всего, спросит:Как вы проводили тестирование производительности?

Рекомендуются четыре часто используемых инструмента тестирования производительности:

  1. Jmeter: Apache JMeter — это инструмент для тестирования производительности, разработанный JAVA.
  2. LoadRunner: коммерческий инструмент для тестирования производительности.
  3. Galtling: высокопроизводительный инструмент для тестирования производительности сервера на основе Scala.
  4. ab: Полное название Apache Bench. Инструмент для тестирования под Apache, который очень полезен.

Если я правильно помню, кромеLoadRunnerНесколько других инструментов для тестирования производительности имеют открытый исходный код и бесплатны.

Обычно используется внешний интерфейс

  1. Fiddler: Инструмент захвата пакетов, он может изменять запрошенные данные и даже данные, возвращаемые сервером.Он имеет очень мощные функции и является мощным инструментом для веб-отладки.
  2. HttpWatch: инструмент, который можно использовать для записи информации HTTP-запроса.

QPS общего программного обеспечения

QPS, приведенные здесь, приведены только для справки, и фактический проект должен быть рассчитан путем измерения давления.

  • Nginx: В нормальных условиях узким местом в производительности системы является не Nginx. Одна машина Nginx может достигать 30 Вт+.
  • Redis: Официальный отчет о тестировании производительности Redis:Redis.IO/topics/На этот раз…. Из отчета мы можем сделать вывод, что одномашинный QPS Redis может достигать 8w+ (производительность процессора связана, а также связана с выполняемой командой. Например, выполнение команды SET может достигать даже 10w+QPS).
  • MySQL: QPS одной машины MySQL составляет около 4k.
  • Tomcat: QPS автономного Tomcat составляет около 2 Вт. Это во многом связано с вашей конфигурацией Tomcat.Например, соединители, поддерживаемые Tomcat,NIO,NIO.2иAPR.AprEndpointНеблокирующий ввод-вывод реализован путем вызова локальной библиотеки APR через JNI, и производительность выше.Если Tomcat настроит APR в качестве соединителя, QPS может достигать около 3 Вт. Для получения дополнительной связанной информации вы можете самостоятельно выполнить поиск оптимизации производительности Tomcat.

Принципы проектирования системы

Fit лучше, чем расширенный > Эволюция лучше, чем один шаг > Простой лучше, чем сложный

Общие стратегии оптимизации производительности

Перед оптимизацией производительности нам необходимо проанализировать все аспекты запроса, выяснить, где могут возникнуть узкие места в производительности, и локализовать проблему.

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

  1. Есть ли проблема с оператором SQL текущей системы?
  2. Требует ли текущая система аппаратного обновления?
  3. Требует ли система кэширования?
  4. Есть ли проблема с самой архитектурой системы?
  5. Есть ли тупик в системе?
  6. Разумно ли использование индексов базы данных?
  7. Есть ли утечка памяти в системе? (Хотя автоматическое восстановление памяти в Java очень удобно, иногда код написан не очень хорошо, что действительно может вызвать утечку памяти)
  8. Обрабатывается ли трудоемкая операция системы асинхронно?
  9. ...

Обязательные правила оптимизации производительности

Оптимизация SQL, JVM, БД, настройка параметров Tomcat > оптимизация аппаратной производительности (обновление памяти, увеличение числа ядер ЦП, механический жесткий диск —> SSD и т. д.) > оптимизация бизнес-логики/кэш > разделение чтения-записи, кластеризация, и т. д. > поверхность подбиблиотеки и подбазы данных

Соображения по поводу собеседования по проектированию системы

подумай об этом

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

нет абсолютного ответа

Не существует универсального ответа на вопрос о проектировании системы. Важно то, как вы общаетесь с интервьюером.

В обычных обстоятельствах вы будете завершать проектирование системы шаг за шагом в процессе общения с интервьюером. В ходе этого процесса вы будете постоянно улучшать дизайн вашей системы под руководством интервьюера.

Таким образом, вам не нужно искать множество вопросов перед собеседованием по проектированию системы, а просто запоминать ответы на них.

Не будь абсолютным

Не существует лучшего проектного решения для проектирования системы, есть только самое подходящее проектное решение. Это аналогично архитектурному дизайну:В разработке программного обеспечения нет серебряной пули, цель проектирования архитектуры — выбрать правильное решение. Что такое серебряная пуля?В легендах об оборотнях только серебряные пули (серебряные пули) могут усмирить этих зверей. В соответствии с действиями по разработке программного обеспечения, серебряная пуля относится конкретно к «мастер-ключу», который разработчики ищут для преодоления трудного зверя разработки программного обеспечения.

Взвесьте все за и против

Знайте плюсы и минусы использования определенной технологии для системы. Например, преимущества использования очередей сообщений заключаются в развязке и сокращении пиковых нагрузок.Однако это также снижает доступность системы, увеличивает сложность, а также создает проблемы согласованности (что делать, если сообщения потеряны или сообщения не используются).

Оптимизируйте медленно

Система, разработанная в начале, не обязательно должна быть идеальной, ее можно оптимизировать постепенно.

Не гонитесь за новыми технологиями

Используйте стабильные, подходящие для бизнеса технологии, и не нужно слишком увлекаться новыми технологиями.

Стремитесь к простоте и избегайте беспорядка

Дизайн системы должен стремиться к простоте и избегать сложности. Принцип KISS (Keep It Simple, Stupid) — делайте это простым и понятным.

Суммировать

Эта статья кратко взяла друзей, чтобы проанализировать интервью по проектированию системы. Если вы хотите узнать больше, вы можете обратиться к:GitHub.com/Дон Мартин….

Ссылаться на

  1. GitHub.com/Дон Мартин…
  2. www.acecodeinterview.com/intro/
  3. gist.GitHub.com/VAТри дняHK/48…

Поиск в WeChat“JavaGuide"Отвечать"Основы компьютера», чтобы получить Основы графического компьютера + Личное оригинальное руководство по собеседованию на Java.

Категории