Одна сторона Ant Financial: анализ десяти классических вопросов для интервью

Java задняя часть

предисловие

Привет всем, я маленький мальчик, который собирает улиток. Недавно небольшой партнер по дискуссионной группе по программированию отправился в Ant Financial на собеседование. Ниже приведены настоящие вопросы интервью. Давайте вместе обсудим, как на них ответить.

1. Используете ли вы распределенные транзакции, почему именно это решение, есть ли другие решения?

Что такое распределенная транзакция

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

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

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

Распределенные транзакции нужно знатьтеория CAPиБАЗОВАЯ теория.

теория CAP

  • Непротиворечивость (C: Непротиворечивость): Непротиворечивость относится к характеристикам того, могут ли данные оставаться согласованными между несколькими копиями. Например, после обновления данных на узле раздела данные, считанные с других узлов раздела, также являются обновленными данными.
  • Доступность (A: Доступность): Доступность означает, что услуги, предоставляемые системой, всегда должны быть доступны, а результаты всегда могут быть возвращены в течение ограниченного времени для каждого запроса операции пользователя. Дело здесь в «за ограниченное время» и «возвращении результата».
  • Устойчивость к разделам (P: Partition Устойчивость): когда распределенная система сталкивается с каким-либо сбоем сетевого раздела, она все равно должна иметь возможность предоставлять внешние службы, которые соответствуют согласованности и доступности.

В распределенной системе теория CAP может одновременно удовлетворять только двум пунктам (непротиворечивость, доступность, отказоустойчивость разделов).

БАЗОВАЯ теория

Теория BASE является расширением AP в CAP.Для нашей бизнес-системы мы рассматриваем возможность пожертвовать согласованностью в обмен на доступность системы и отказоустойчивость разделов. BASE — это аббревиатура от фраз «Базово доступный», «Мягкое состояние» и «В конце концов непротиворечивый».

  • Базовая доступность означает, что она достигается за счет поддержки локальных сбоев, а не общесистемных сбоев;
  • Мягкое состояние указывает, что состояние может быть не синхронизировано в течение определенного периода времени;
  • В конечном итоге согласованные, окончательные данные являются согласованными, а не строго непротиворечивыми в реальном времени.

Несколько решений для распределенных транзакций

  • Схема 2PC (двухэтапная подача), фиксация транзакции делится на две фазы: фаза подготовки и план выполнения фиксации.
  • TCC (т.е. попытка, подтверждение, отмена), который принимает компенсационный механизм.Основная идея заключается в том, что для каждой операции должна быть зарегистрирована соответствующая операция подтверждения и компенсации (отзыва).
  • локальная таблица сообщений, его основная идея заключается в разделении распределенных транзакций на локальные транзакции для обработки.
  • уведомление о лучших усилиях, чтобы получить максимально возможное уведомление, вы можете использовать механизм подтверждения MQ.
  • Сага дела, его основная идея состоит в том, чтобы разделить длинную транзакцию на несколько локальных коротких транзакций, которые координируются координатором транзакций Saga. Если она завершается нормально, она будет завершена нормально. Если шаг терпит неудачу, операция компенсации вызывается один раз в обратном порядке. приказ.

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

Для отправителя сообщения:

  • Прежде всего, должна быть таблица сообщений, в которую записывается информация, связанная со статусом сообщения.
  • Бизнес-данные и таблица сообщений находятся в одной базе данных, то есть необходимо убедиться, что они находятся в одной и той же локальной транзакции.
  • После обработки бизнес-данных и записи таблицы сообщений в локальной транзакции запишите сообщение в очередь сообщений MQ.
  • Сообщение будет отправлено потребителю сообщения, и если отправка завершится ошибкой, попытка будет повторена.

Потребитель сообщения:

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

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

2. Какие новые функции предоставляют JDK6, 7 и 8

Что нового в JDK 6

  • Класс рабочего стола (который позволяет приложению Java локально запускать другое приложение для обработки запросов URI или файлов)
  • Сопоставление объектов и XML с использованием JAXB2
  • Облегченный API Http-сервера
  • Подключаемый API обработки аннотаций (на этой функции основан фреймворк ломбока)
  • STAX (это API для обработки XML-документов в JDK6)

Что нового в JDK 7

  • коммутатор поддерживает тип строки String
  • try-with-resources, ресурсы автоматически закрываются
  • Целочисленные типы, такие как (byte, short, int, long), могут быть представлены в двоичном виде.
  • Числовые константы поддерживают подчеркивание
  • Общий тип экземпляра выводится автоматически, т. е. ""
  • Перехват нескольких типов исключений за один перехват, разделенных знаком (|)
  • Усовершенствованная файловая система
  • Форк/объединение фреймворка

Что нового в JDK8

  • лямбда-выражение
  • функциональный интерфейс
  • ссылка на метод
  • метод по умолчанию
  • Stream API
  • Optional
  • API даты и времени (например, LocalDate)
  • Дублировать аннотации
  • Base64
  • Новые функции JVM (такие как Metaspace вместо постоянной генерации)

3. принцип https, рабочий процесс

  • HTTPS = HTTP + SSL/TLS, то есть данные шифруются и расшифровываются с помощью SSL/TLS, а для передачи используется Http.
  • SSL или Secure Sockets Layer — это протокол безопасности, который обеспечивает безопасность и целостность данных для сетевых коммуникаций.
  • TLS, безопасность транспортного уровня (Transport Layer Security), является последующей версией SSL 3.0.

  1. Клиент инициирует запрос HTTPS и подключается к порту 443 сервера.
  2. Сервер должен иметь набор цифровых сертификатов (содержимое сертификата включает открытый ключ, центр сертификации, дату истечения срока действия и т. д.).
  3. Сервер отправляет клиенту свой собственный цифровой сертификат (открытый ключ находится в сертификате, а закрытый ключ хранится на сервере).
  4. После того, как клиент получит цифровой сертификат, он проверит действительность сертификата. Если сертификат проверен, генерируется случайный симметричный ключ, который шифруется с помощью открытого ключа сертификата.
  5. Клиент отправляет ключ, зашифрованный открытым ключом, на сервер.
  6. После того, как сервер получает ключ зашифрованного текста, отправленный клиентом, он асимметрично расшифровывает его своим закрытым ключом, а после расшифровки получает ключ клиента, а затем использует ключ клиента для симметричного шифрования возвращенных данных.Данные, переданные Jiangzi весь зашифрованный текст.
  7. Сервер возвращает зашифрованный зашифрованный текст клиенту.
  8. После того, как клиент его получает, он симметрично расшифровывает его своим ключом, чтобы получить данные, возвращаемые сервером.

4. Расскажите о принципе реализации java jmm volatile

Ключевое слово volatile предоставляется виртуальной машиной Java.Самый легкий механизм синхронизации, который действует как модификатор для изменения переменных. Он гарантирует переменную видимость для всех потоков, запрещает переупорядочивание инструкций, но не гарантирует атомарность.

Как volatile гарантирует видимость? Давайте сначала посмотрим на модель памяти Java (jmm)

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

Java内存模型

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

Перестановка инструкций означает, что в процессе выполнения программы для повышения производительности компилятор и ЦП могут переупорядочивать инструкции. Как volatile предотвращает переупорядочивание инструкций? В языке Java существует принцип «происходит до» (происходит до)

  • правила порядка программы: В потоке, в порядке потока управления, операция, написанная впереди, выполняется до операции, написанной сзади.
  • Правила блокировки монитора: сначала выполняется операция разблокировки, а затем выполняется такая же операция блокировки.
  • правила изменяемой переменной: запись в переменную происходит перед последующим чтением переменной
  • правило начала потока: метод start() объекта Thread выполняется первым для каждого действия этого потока.
  • правила завершения потока: Все операции в потоке выполняются первыми при обнаружении завершения потока.Мы можем определить, что поток завершил выполнение, через конец метода Thread.join() и возвращаемое значение Thread.isAlive().
  • Правила прерывания потока: вызов метода прерывания потока () происходит первым, когда код прерванного потока обнаруживает возникновение события прерывания.
  • Правила завершения объекта: инициализация объекта происходит сначала в начале его метода finalize().
  • переходность: Если операция А выполняется до операции В, а операция В выполняется до операции С, можно сделать вывод, что операция А выполняется до операции С.

На самом деле volatile гарантирует видимость и запрещает переупорядочивание инструкций следующим образом.барьер памятиСвязанный. Давайте посмотрим на демонстрационный код, используемый volatile

public class Singleton {  
    private volatile static Singleton instance;  
    private Singleton (){}  
    public static Singleton getInstance() {  
    if (instance == null) {  
        synchronized (Singleton.class) {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
        }  
    }  
    return instance;  
    }  
}

После компиляции сравните ассемблерный код, сгенерированный с ключевым словом volatile и без ключевого слова volatile, и обнаружите, что при изменении ключевого слова volatile появится еще один код.lock addl $0x0,(%esp), то есть есть еще одна инструкция префикса блокировки, и инструкция блокировки эквивалентна "барьеру памяти"

Инструкция блокировки эквивалентнабарьер памяти, что гарантирует следующее:

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

Пункты 2 и 3 являются воплощением того, что volatile гарантирует видимость.Первый пункт - это воплощение запрета перестановки инструкций. Что такое барьер памяти?

Существует четыре основных категории барьеров памяти: (Загрузка представляет инструкции чтения, Сохранение представляет инструкции записи).

тип барьера памяти абстрактная сцена описывать
НагрузкаГрузовой барьер Load1; LoadLoad; Load2 Перед обращением к данным, которые должны быть прочитаны Load2, убедитесь, что данные, которые должны быть прочитаны Load1, были прочитаны.
МагазинМагазин Барьер Store1; StoreStore; Store2 Перед выполнением записи Store2 убедитесь, что операции записи Store1 видны другим процессорам.
Барьер LoadStore Load1; LoadStore; Store2 Прежде чем Store2 будет записан, убедитесь, что данные, которые должны быть прочитаны Load1, были прочитаны.
Барьер StoreLoad Store1; StoreLoad; Load2 Запись в Store1 гарантированно будет видна всем процессорам до чтения Load2.

Чтобы достичь семантики памяти volatile, модель памяти Java использует следующую консервативную стратегию.

  • Вставьте барьер StoreStore перед каждой операцией энергозависимой записи.
  • Вставляйте барьер StoreLoad после каждой операции энергозависимой записи.
  • Вставьте барьер LoadLoad после каждого чтения volatile.
  • Вставляйте барьер LoadStore после каждого чтения энергозависимых данных.

Некоторые друзья могут все еще немного смущаться по этому поводу, барьер памяти слишком абстрактен. Давайте посмотрим на код:

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

5. Расскажите о 7-уровневой модели сети, зачем TCP нужно трехстороннее рукопожатие

Архитектура компьютерной сети имеет три уровня: семиуровневая модель OSI, четырехуровневая модель TCP/IP и пятиуровневая архитектура, как показано на рисунке:

Семиуровневая модель, также известная как OSI (Open System Interconnection), представляет собой стандартную систему, разработанную Международной организацией по стандартизации для взаимосвязи между компьютерами или системами связи.

  • Прикладной уровень: интерфейс между сетевыми службами и конечными пользователями, общие протоколы: HTTP FTP SMTP SNMP DNS.
  • Уровень представления: представление данных, безопасность, сжатие. , чтобы гарантировать, что информация, отправленная прикладным уровнем одной системы, может быть прочитана прикладным уровнем другой системы.
  • Сеансовый уровень: устанавливать, управлять и завершать сеансы, соответствующие хост-процессу, ссылаясь на текущий сеанс между локальным хостом и удаленным хостом.
  • Транспортный уровень: определите номер порта протокола для передачи данных, а также управления потоком и проверки ошибок, протокол имеет TCP UDP.
  • Сетевой уровень: выполнение логической адресации, выбор пути между различными сетями, протоколы включают ICMP, IGMP IP и т. д.
  • Уровень канала передачи данных: на основе услуги потока битов, предоставляемой физическим уровнем, устанавливается канал передачи данных между соседними узлами.
  • Физический уровень: устанавливать, поддерживать и отключать физические соединения.

6. Расскажите о принципе работы пула потоков

Если интервьюер хочет, чтобы мы рассказали о принципе работы пула потоков, вы можете рассказать о следующей блок-схеме:

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

  • Основная нить уподобляется штатным сотрудникам компании.
  • Непрофильные потоки уподобляются аутсорсинговым сотрудникам
  • Очереди блокировки сравниваются с пулами запросов
  • Отправка задачи похожа на запрос

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

7. Как достигается высокая доступность вашей базы данных?

высокая доступность, т.е.High Availability, является одним из факторов, который необходимо учитывать при проектировании архитектуры распределенной системы.Обычно это относится к сокращению времени, когда система не может предоставлять услуги посредством проектирования. Развертывание на одном компьютере не отличается высокой доступностью, посколькуединая точка отказапроблема. Высокая доступность — это все несколько узлов.Когда мы рассматриваем архитектуру высокой доступности базы данных MySQL, нам необходимо учитывать следующие аспекты:

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

7.1 Полусинхронная репликация ведущий-ведомый или ведущий-ведущий

Используйте базу данных с двумя узлами для создания односторонней или двусторонней полусинхронной репликации. Архитектура выглядит следующим образом:

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

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

7.2 Оптимизация полусинхронной репликации

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

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

7.3 Оптимизация архитектуры высокой доступности

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

  • Преимущества: гарантируется высокая доступность всей системы, а также хорошая масштабируемость, которую можно распространить на крупномасштабные кластеры.
  • Недостаток: непротиворечивость данныхВсе еще полагаясь на родную полусинхронную репликацию mysql; Внедрение Zookeeper усложняет логику системы.

7.4 Общее хранилище

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

Копия диска DRBD

DRBD — это программно-реализованное решение для репликации хранилища без совместного использования, которое зеркалирует содержимое блочных устройств между серверами. Он в основном используется для зеркалирования данных дисков, разделов, логических томов и т. д. между серверами.Когда пользователь записывает данные на локальный диск, он также отправляет данные на диск другого хоста в сети.Такой локальный хост (Данные главного узла) и удаленного хоста (резервного узла) можно синхронизировать в режиме реального времени. Общая архитектура выглядит следующим образом:

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

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

7.5 Распределенные протоколы

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

  • Преимущества: высокая согласованность данных может быть достигнута без использования стороннего программного обеспечения;
  • Недостатки: сложная конфигурация, необходимость использования механизма хранения NDB, не менее трех узлов;

8. Как в сценарии с разделением чтения-записи обеспечить, чтобы последние данные считывались из базы данных?

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

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

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

  • A инициирует запрос на запись, обновляет данные основной базы данных и устанавливает метку в кеше, чтобы указать, что данные были обновлены.Формат метки: userId + бизнес-идентификатор.
  • Установите этот флаг, чтобы установить время истечения (оценивается как временная задержка между синхронизацией ведущего и ведомого)
  • B инициирует запрос на чтение и сначала определяет, имеет ли запрос метку обновления в кэше.
  • Если есть тег, перейти в основную библиотеку, если нет, запросить переход в подчиненную библиотеку.

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

9. Как сделать так, чтобы данные MySQL не были потеряны?

MySQL, реляционная база данных, является стратегией регистрации в первую очередь (Write-Ahead Logging), до тех пор, покаbinlog и журнал повторовЖурнал может быть гарантированно сохранен на диске, и мы можем гарантировать, что данные не будут потеряны после аварийного перезапуска MySQL.

бинлог журнал

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

  • заявление: каждый sql, который изменяет данные, будет записан в binlog, что не рекомендуется.
  • row: запись на основе изменения строки, будет записывать содержимое до и после изменения строки,Рекомендуемое использование.
  • смешанный: смешивание двух режимов оператора и строки не рекомендуется.

Каков механизм записи binlog?

Во время выполнения транзакции журнал сначала записывается в кэш binlog, а когда транзакция фиксируется, кэш binlog записывается в файл binlog.

.

Система выделяет по одному на клиентский потокbinlog cache, параметр управления значением размера которогоbinlog_cache_size. еслизначение кэша binlogЕсли порог превышен, он будет временно сохранен на диск. Когда транзакция зафиксирована, полная транзакция в кэше binlog сохраняется на диске, а кэш binlog очищается.

binlog写文件

binlog записывает точки в файлписать и fsyncДва процесса:

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

Время записи операций записи и fsync управляется переменной sync_binlog:

Если есть узкое место в производительности ввода-вывода, вы можетеsync_binlogУстановите большее значение. Например, установите значение (100~1000). Однако существует риск потери данных, и при аварийном перезапуске хостаПотеряно N журналов последних совершенных транзакций.

журнал повторов

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

  • Физически он находится в памяти процесса MySQL и существует в буфере журнала повторов.
  • Физически в страничном кеше файловой системы, записывается на диск (запись), но не сохраняется (fsync).
  • Есть жесткий диск, который был сохранен на диск.

журнал записи вredo log bufferбыстро;page cacheТакже быстро, но гораздо медленнее сохраняется на диск.

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

    1. Если установлено значение 0, это означает, что журнал повторов остается только в буфере журнала повторов каждый раз, когда транзакция фиксируется;
    1. Если установлено значение 1, это означает, что журнал повторов будет сохраняться непосредственно на диск каждый раз, когда транзакция фиксируется;
    1. Если установлено значение 2, это означает, что журнал повторов записывается в кэш страниц только каждый раз, когда транзакция фиксируется.

Среди трех режимов 0 имеет наилучшую производительность, но он небезопасен: при сбое процесса MySQL одна секунда данных будет потеряна. 1 обеспечивает наивысший уровень безопасности, но оказывает наибольшее влияние на производительность.В случае 2 операционная система в основном контролирует время очистки диска.Если не работает только MySQL, это не повлияет на данные.Если хост аварийно отключен, он также будут потеряны данные.

10. Как разработать систему seckill с высокой степенью параллелизма?

Чтобы спроектировать систему seckill, необходимо рассмотреть следующие вопросы:

какрешить эти проблемыШерстяная ткань?

  • статическая страница
  • кнопка для серого управления
  • Служба единоличной ответственности
  • Спайк ссылка с солью
  • Ограничение
  • Распределенная блокировка
  • Асинхронная обработка MQ
  • Ограничение тока, деградация и плавкий предохранитель

статическая страница

Большая часть содержимого страницы активности seckill фиксирована, например, название продукта, изображение продукта и т. д. Страница активности может обрабатываться статически, чтобы уменьшить запрос на доступ к серверу. Пользователи Spike будут распределены по всей стране, некоторые в Шанхае, некоторые в Шэньчжэне, географическая разница очень велика, и скорость сети также отличается. Чтобы предоставить пользователям доступ к странице события как можно быстрее, можно использовать CDN (сеть доставки контента, сеть доставки контента). CDN позволяют пользователям получать нужный им контент поблизости.

кнопка для серого управления

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

Служба единоличной ответственности

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

Например, если вход пользователя связан, будет разработана услуга пользователя, будет предоставлена ​​услуга, связанная с заказом, и будет предоставлена ​​услуга, связанная с подарком. Затем бизнес-логика, связанная с seckill, также может быть объединена, чтобы сделатьСервис Seckill, и создайте для него базу данных второго уничтожения.

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

Спайк ссылка с солью

Если ссылка отображается в виде простого текста, кто-то получит URL-адрес запроса и убьет его заранее. Поэтому вам нужно добавить соль в ссылку seckill. Вы можете сделать URL-адрес динамическим, например, зашифровав случайную строку с помощью алгоритма шифрования MD5 для создания URL-адреса.

Ограничение

Как правило, существует два способа ограничения тока: ограничение тока nginx и ограничение тока redis.

  • Чтобы пользователь не запрашивал слишком часто, мы можемТот же текущий лимит пользователя;
  • Чтобы скальперы не имитировали несколько пользовательских запросов, мы можемОпределенный IP ограничен;
  • Чтобы кто-то не мог использовать прокси и менять IP-запрос для каждого запроса, мы можеминтерфейс для ограничения тока.
  • Чтобы предотвратить переполнение системы мгновенным чрезмерным трафиком, для ограничения тока можно также использовать компоненты Ali Sentinel и Hystrix.

Распределенная блокировка

Проблема перепроданности может быть решена с помощью распределенных блокировок redis.

Использование RedisSET EX PX NX + проверить уникальное случайное значение, а затем удалите блокировку снятия.

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //释放锁
        }
    }
}

Здесь оценка того, добавлена ​​ли блокировка текущим потоком, и снятие блокировки не является атомарной операцией. Если вы вызываете jedis.del() для снятия блокировки, блокировка может больше не принадлежать текущему клиенту, и блокировка, добавленная другими, будет снята.

Чтобы быть более строгим, вместо этого обычно используются сценарии lua. Lua-скрипт выглядит следующим образом:

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;

Асинхронная обработка MQ

Если мгновенный трафик особенно велик, вы можете использовать очередь сообщений, чтобы сократить пик и обрабатывать его асинхронно. Когда пользователь запрашивает, он сначала помещается в очередь сообщений, а затем извлекается для использования.

Ограничение тока, деградация и плавкий предохранитель

  • Текущее ограничение предназначено для ограничения запросов, чтобы предотвратить перегрузку сервера чрезмерными запросами;
  • Понижение означает, что в случае возникновения проблемы со службой seckill обработка понижения не затрагивает другие службы;
  • Если есть предохранитель, если есть проблема со службой, он перегорает.Как правило, предохранитель и понижение версии происходят вместе.

Ссылка и спасибо

Категории