Базовая архитектура системы заказа:На стойке регистрации есть страница расчетов для пользователей. Когда серверная часть получает щелчок внешнего пользователя по операции расчета, он начинает обрабатывать службу заказа. Сначала заказ записывается в базу данных в бэкэнд, а затем разнородные данные сохраняются в кеше, чтобы предоставить пользователям запрос заказа выполняется в моей системе заказов.Когда платеж пользователя завершен, кассир отправляет сообщение в службу заказов, чтобы изменить статус заказа в базе данных и смешанное хранение.Эта простая система заказов завершена, но реальная система заказов имеет более сложный бизнес, что делает систему более сложной.
Далее смотрим по каким ссылкам в системе будет проблема с потерянными заказами
Заказ потерян: запись в базу данных, принятие и отправка сообщений о заказе
1. Ключевая логика не может использовать метод запроса разделения чтения-записи, чтобы избежать исключения запроса порядка, вызванного задержкой синхронизации подчиненной базы данных.2. Ключевая логика заключается в том, чтобы не использовать кеш для запроса ордера, из-за задержки кеша обратный запрос ордера не работает.
3. Компенсация заказа не должна использовать метод очереди сообщений просто и грубо, чтобы избежать потери заказа, вызванной промежуточным программным обеспечением.Например, при изменении статуса заказа, если обработка не удалась, информация о заказе будет вставлена в очередь сообщений для повторного потребление, тем самым выполняя компенсацию за заказы, этот метод может иметь возможность потери сообщений при отправке и получении сообщений
4. Если обработка полученного сообщения не удалась, обязательно дайте сообщению повторить попытку, чтобы избежать потери.Обратите особое внимание на такие ключевые слова, как return и continue.Например, потребляйте несколько записей одновременно и обрабатывайте их одну за другой.Если модификация статус успешен, продолжайте обработку следующего. Если модификация не удалась, остальные сообщения могут быть потеряны из-за ключевых слов, таких как return или continue
Как спроектировать систему, поддерживающую 10 000 заказов в день, с учетом проблемы возможных потерянных заказов, а также стабильности и доступности системы, как проводить систематическую реконструкцию и оптимизацию. Предыдущая система на самом деле очень легко обрабатывала ежедневные заказы на 10 000, поэтому вам просто нужно обратить внимание на несколько ключевых моментов: 1. При написании БД гранулярность транзакций БД не должна быть слишком большой, избегайте блокировок таблиц, ориентируйтесь на медленные запросы.Например, самая главная ошибка - обновлять другие источники данных или отправлять сообщения сообщениям одновременно в транзакциях базы данных.Это не только невозможно.Обеспечение непротиворечивости данных также исчерпывает соединения с базой данных.
Еще одна вещь, на которую следует обратить внимание, — это производительность и стабильность неоднородности данных, особенно в случае сетевого дрожания, которое может повлиять на работу пользователя.
Наконец, обратите внимание на идемпотентность заказа, чтобы избежать ошибок при выставлении счетов и повлиять на последующий рабочий процесс.
Хорошая работа в предыдущем архитектурном плане может в основном удовлетворить ежедневную систему заказов на 10 000 уровней.
Как спроектировать систему заказов, поддерживающую десятки миллионов заказов в день?Отличие от системы заказов на 10 000 заказов в день заключается в сумме.Из-за увеличения суммы система перегружается и сервис в итоге закрывается Затем проанализируйте, какая из предыдущих системных архитектур является узким местом системы?
Во-первых, предыдущая архитектура слишком сильно зависит от базы данных, а база данных также является базой данных заказов. Непрерывные запросы на чтение и запись сильно нагружают базу данных. Например, при изменении статуса заказа она необходимо проверить базу данных и обновить статус заказа.Когда операция выполняется с большим количеством одновременных запросов, это приведет к вытеснению ресурсов базы данных, что повлияет на стабильность системы.Во-вторых, чтобы избежать несогласованности данных, доступ к запросу в основном сосредоточен на основной базе данных, поэтому нагрузка на основную базу данных относительно велика.
Поэтому, когда используется структура подбазы данных и подтаблицы, служба заказа также должна быть преобразована для поддержки структуры подбазы данных и подтаблицы.Однако из-за наличия горячих данных это может привести к к проблеме перекоса данных в базе данных, что приводит к раннему расширению базы данных.
Кроме того, из-за чрезмерной связанности службы заказов сложно быстро обрабатывать бизнес-ответы даже в многокластерной архитектуре развертывания.Более того, процессы обработки заказов разных предприятий по-прежнему различаются, что делает систему все более и более Плохо, например: при создании заказа из-за разной деловой, цифровой, 3с, книжной и другой системы заказов информация отличается, что требует специальной обработки, эта специальная обработка связана с созданием заказа, который будет система будет обрабатывать очень быстро.В конце концов, из-за увеличения объема данных, хранящихся в базе данных, производительность неоднородности данных резко упадет, а объем кэш-памяти будет продолжать увеличиваться, что сильно повлияет на производительность запросов, и может вызвать проблемы, такие как взаимное влияние между службами.
В целом с предыдущей системой есть проблемы: система заказов медленно обрабатывает заказы, база данных находится под большой нагрузкой, высокая задержка разнородных данных, низкое качество кэшированных данных.
Чтобы справиться с ежедневным объемом заказов в десятки миллионов, мы разделили службу заказов, используя отдельную службу заказов для обработки заказов, используя механизм заказов и конвейер заказов для обработки бизнес-логики заказа, а также переключившись на двойное написание и компенсация транзакций.Обработка кеша, использование метода истечения срока действия кеша для обработки объема данных,
Далее мы подробно проанализируем план реализации: когда пользователь нажимает, чтобы отправить заказ, служба приема заказов в той же транзакции вставит заказ в библиотеку приема заказов, вставит первую задачу в библиотеку задач, а затем Механизм заказа выполнит планирование задач Что такое задача? Задачи — это шаги для выполнения операций с заказами, таких как запись кешей заказов, сокращение запасов, отправка уведомлений о заказах и т. д., а также различные специальные бизнес-процессы, упомянутые выше. процесс в один за другим Задачи обрабатываются индивидуально, одна за другой, чтобы справиться с ежедневным давлением обработки десятков миллионов заказов.
Среди них база данных, принимающая заказы, представляет собой несколько баз данных, которые записываются в базу случайным образом.Причина, по которой не используются такие алгоритмы, как хеширование, заключается в том, что возможность расширения является более гибкой.Когда наступает пик трафика, несколько новых базы данных добавляются для записи в базу данных Логика ввода нечувствительна Библиотека приема заказов принимает архитектуру развертывания одного ведущего и нескольких ведомых Когда машина выходит из строя, ее можно восстановить с помощью быстрого чтения, переключения ведущего и ведомого или удаление неисправной машины.
Библиотека задач управляется и выполняется механизмом заказа.Задача генерируется с помощью возможности планирования службы механизма заказа для создания очереди задач.После успешного выполнения первой задачи будет вставлена вторая задача или третья и четвертые задачи будут вставлены одновременно. Если задача Если вставка не удалась, механизм заказа повторно выполнит текущую задачу. После успешного выполнения он продолжит выполнение операции вставки. Здесь бизнес-обработка каждая задача должна обеспечивать идемпотентность.
Далее, давайте поговорим о методе планирования потока задачи. Задача планируется многопоточным асинхронным способом, и выберите, выполнять ли ее последовательно или параллельно в соответствии с конфигурацией. Следует отметить одну вещь: планирование потока задачи. выполнение, упомянутое выше, то, если задача Если выполнение завершается неудачно, как механизм заказа повторно выполняет неудачную задачу? Это достигается с помощью конечного автомата задачи, который подобен потоку демона системы.
Конечный автомат задачи распознает, завершена ли каждая задача или нет, определяя состояние задачи, и планирует задачи в соответствии с состоянием, а частота планирования повторных попыток для задач, которые не выполняются несколько раз, будет постепенно уменьшаться. определенное количество раз. После этого будет выдан сигнал тревоги для ручного вмешательства.На самом деле, это не механизм заказов, который фактически выполняет удаленное планирование удаленных услуг, а механизм заказов, который планирует конвейер заказов, который планирует выполнение удаленной реальной услуги Причина в том, что сам механизм задач многопоточная архитектура проектирования. , занятость потоков относительно высока, и удаленное планирование будет регистрировать множество служб, а планирование служб также запускает выполнение многих многопоточных потоков. Если они развернуты вместе в одной системе, будет будет слишком много потоков и ЦП будет парить.
Далее поговорим о стратегии реализации кэширования заказов: после того, как служба приема заказов отработала некоторую бизнес-логику, она, наконец, вызывает службу заказов для отправки заказа в центр заказов, а перед этим, чтобы обеспечить своевременность заказа , заказ и задача вставлены После этого служба приема заказов теперь запишет заказ в кеш центра заказов через интерфейс, чтобы пользователь мог сразу запросить мой заказ в списке моих заказов после оплаты. службы, заказ будет размещен на складе, а затем синхронизирован с кешем.После того, как последующий центр заказов получит сообщение из леджера, база данных и кеш будут обновлены одновременно, а статус заказа будет обновлен до заказ выполнен.
Наконец, давайте поговорим о структуре системы ежедневных заказов на десятки миллионов. Пользователь нажимает расчет на странице расчета, и страница расчета вызывает службу приема заказов в фоновом режиме. После того, как служба приема заказов получает запрос на заказ , он будет отвечать за прием заказа и вставку заказа в заказ. Перейдите в библиотеку приема заказов, вставьте первую задачу в библиотеку задач в транзакции и уведомите механизм планирования заказов, чтобы начать выполнение задачи. Заказ механизм выполняет планирование задач и обновляет статус задачи в последовательности в соответствии с номером задачи, а конечный автомат выполняет проверку и компенсацию задачи.Обрабатывая, механизм заказов реализует реальное удаленное планирование через конвейер заказов планирования.После того, как конвейер заказов запрашивает услугу, он возвращает результат обработки в механизм задач.Наконец, центр заказов будет асинхронно записывать кеш заказов в центр заказов, когда служба приема заказов создает заказ, а затем снова записывает копию данных в кеш заказов с помощью неоднородность данных,
После понимания процесса обработки заказов мы обсудим, как обеспечить высокую доступность и высокую производительность процесса размещения заказов во всем процессе.Основной процесс всей системы заказов, принимающий заказы, выполняется почти синхронно, и есть только несколько задачи, такие как отправка уведомлений о заказе нижестоящим. , система использует асинхронное выполнение сообщений, чтобы обеспечить высокую производительность процесса заказа, и весь процесс обработки, основанный на планировании механизма заказа, определяет этапы выполнения заказа через хореографию процесса обслуживания и эффективно обеспечивает правильность каждой ссылки Выполнение, чтобы избежать потери заказа, заказов карт и других нештатных проблем, тем самым обеспечивая высокую доступность процесса заказа,