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

Расширение

Вертикальное расширение (увеличение)

Улучшить возможности отдельного сервиса (сервера, базы данных)

Однако он увеличит зависимость и управление другими программными средствами в едином сервисе, а также внутреннюю сложность услуг.

Горизонтальное расширение (горизонтальное расширение)

Добавить больше участников службы

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

План расширения базы данных

Определить тип бизнеса

• Много операций чтения: принята схема вертикального расширения (redis, CDN). Горизонтальное расширение не имеет особого смысла, поскольку узким местом в производительности является не операция записи, поэтому ее не нужно выполнять в режиме реального времени, а рентабельность использования большего количества серверов для распределения нагрузки слишком низка. Так что достаточно усилить его производительность чтения для одной системы.
• Операций записи много: принята схема горизонтального расширения (HBase, добавление серверов, баз данных). Вы также можете подумать о вертикальном расширении для повышения производительности одной базы данных, но вы обнаружите, что пропускная способность средств и жестких дисков ограничена, поэтому вам нужно добавить больше баз данных, чтобы разделить давление записи.

тайник

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

особенность

• Частота попаданий = попаданий / (попаданий + отсутствие попаданий)
• Максимальное пространство: максимальное место для кеша
• Пустая стратегия: FIFO/LFU/LRU/срок действия/случайная

FIFO: данные, которые первыми попадают в кеш, очищаются, когда места в кеше недостаточно, чтобы обеспечить доступность самых последних данных.
LFU (наименее часто используемый): наименее часто используемый в последнее время, в зависимости от количества посещений, удалите элемент с наименьшим количеством обращений LRU (наименее недавно используемый): наименее часто используемый, в зависимости от времени доступа, удалите из посещаемые элементы

Локальный кеш Guava Cache

Фактически, время программирования для записи переменных-членов, статических переменных всегда рассматривалось как кеш.

Распределенный кэш Redis

Проблема с высоким параллелизмом кэша

когерентность кэша

Полная и инкрементальная синхронизация

Определение распределенных блокировок на основе потребностей бизнеса

Параллелизм кэширования

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

Взлом/проникновение кэша

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

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

инвалидация кеша

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

решение:

1. Равномерно распределите время аннулирования кеша ключей в системе
2. Когда мы запрашиваем данные через ключ, мы сначала запрашиваем кеш, Если запрос не может быть найден в кеше в это время, мы заблокируем его через распределенную блокировку.

горячая клавиша

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

решение:

1. Кэш ключа точки доступа клиента: ключ точки доступа соответствует значению и кэшируется локально на клиенте, а также устанавливается время истечения срока действия.
2. Ключ точки доступа делится на несколько подразделов, а затем сохраняется на разных машинах в кластере кеша.Значения, соответствующие этим подразделам, такие же, как у ключа точки доступа.

очередь сообщений

Очередь сообщений должна решитьСкорость производства и потребления несовместимаПолученные проблемы имеют следующие преимущества:

1. Сокращение времени ответа на запрос. Например, функция регистрации должна вызывать сторонний интерфейс для отправки текстовых сообщений, ожидание стороннего ответа может занять много времени.
2. Развязка между услугами. Основной сервис занимается только основным процессом, вам не нужно знать, как обрабатывать другие неважные и трудоемкие процессы, вам нужно только уведомлять.
3. Отключение трафика. Для запросов, не требующих обработки в реальном времени, когда объем параллелизма особенно велик, его можно сначала кэшировать в очереди сообщений, а затем отправлять в соответствующую службу для обработки.

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

Применить разделение

Ограничение

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

Чтобы контролировать количество выполнений определенного фрагмента кода в течение определенного периода времени, вы можете передатьGuavaили реализация семафора

Понижение и предохранитель

База данных Ceku, субботиблические библиотеки, подсуди

Чеку

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

Когда производительность чтения и записи одной базы данных становится узким местом, соотношение операций чтения и записи можно оценить в соответствии с бизнесом, а затем разделение чтения и записи завершается установкой базы данных в режим Master-Slave, а чтение — права на запись всех баз настроены.
Когда бизнес запросов превышает бизнес чтения, операция запроса распределяется между различными подчиненными библиотеками посредством балансировки нагрузки, тем самым снижая нагрузку на основную библиотеку.

Конфигурацию можно выполнить с помощью аннотаций Spring.

Подбиблиотека и подтаблица

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

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

проблема:

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

вне никнейма

Недавно обобщил некоторые изJavaОчки знаний, связанные с интервью, заинтересованные друзья могут поддерживать их вместе ~
адрес:GitHub.com/Xbox1994/20…