作者：张sir
来源：京东技术
Предыдущий:Если кто-то взорвет сервер хранения Alipay
В бизнес-системе центра заказов JD Daojia, будь то производство заказов внешними продавцами или зависимость от внутренних вышестоящих и нижестоящих систем, объем запросов запроса заказа очень велик, что приводит к большему чтению и меньшему количеству написания заказа. данные.
Мы храним данные о заказах в MySQL, но очевидно, что только большое количество запросов доступно только через БД. В то же время для некоторых сложных запросов поддержка MySQL не является дружественной, поэтому система центра заказов использует Elasticsearch для размещения основного давления запроса заказа.
Будучи мощной распределенной поисковой системой, Elasticsearch поддерживает хранение и поиск данных почти в реальном времени и играет огромную роль в системе заказов JD Daojia.В настоящее время объем данных, хранящихся в кластере ES центра заказов, достиг 1 миллиарда. документов, а среднесуточный объем запросов достиг 500 миллионов.
С быстрым развитием бизнеса JD Daojia в последние годы также развивалось решение по настройке ES для центра заказов.До сих пор настройка кластера ES представляла собой набор решений для взаимного резервного копирования в режиме реального времени, что хорошо гарантирует стабильность Чтение и запись кластера ES Давайте представим этот процесс и некоторые подводные камни, встречающиеся в процессе.
Эволюция кластерной архитектуры ES
1. Начальный этап
Начальный этап ES центра заказов подобен чистому листу бумаги, в основном нет планов настройки, и многие конфигурации должны сохранить конфигурацию кластера по умолчанию. Весь кластер развернут в эластичном облаке группы, а узлы и машины кластера ES хаотичны. В то же время, по размерности кластера, кластер ES будет иметь проблему с одной точкой, что явно недопустимо для бизнеса центра заказов.
2. Этап выделения кластера
Как и многие предприятия, кластеры ES используют смешанный метод распределения. Однако, поскольку ES центра заказов хранит данные онлайн-заказов, иногда смешанные кластеры будут занимать большое количество системных ресурсов, что приведет к ненормальному обслуживанию всего ES центра заказов.
Очевидно, что какое-либо влияние на стабильность запроса заказов является недопустимым, поэтому в этом случае расположен первый эластичный облачный центр заказов ES, чтобы выйти из этих системных ресурсов, чтобы захватить высокий узел кластера, состояние кластера ES немного улучшилось. Но с увеличением данных кластера эластичная облачная конфигурация стала менее способна соответствовать кластеру ES, и для полной физической изоляции последний порядок заключается в простом развертывании кластера ES в центре высокой производительности физической машины, производительности кластера ES. был улучшен.
3. Этап настройки реплики узла
Производительность ES во многом зависит от аппаратных ресурсов.Когда кластер ES развернут только на физической машине, узлы внутри кластера не монополизируют ресурсы всей физической машины.Когда кластер работает, узлы на та же самая физическая машина все равно будет выгружать ресурсы.Проблема. Поэтому в этом случае, чтобы позволить одному узлу ES использовать максимум ресурсов машины, каждый узел ES развертывается на отдельной физической машине.
Но затем снова возникает проблема: что, если в одном узле есть узкое место? Как мы должны его оптимизировать?
Принцип запроса ES, когда запрос попадает на определенное количество шардов, если не указан тип шарда (параметр Preference) запроса, запрос будет загружен на каждую ноду соответствующую номеру шарда. Конфигурация реплик кластера по умолчанию — один мастер и одна реплика.В ответ на эту ситуацию мы подумали о способе расширения реплик от одного мастера и одной реплики по умолчанию до одного мастера и двух реплик, а также добавления соответствующих физических машин в в то же время.
Принципиальная схема настройки кластера ES центра заказов
Как показано, вся настроек путем балансировки нагрузки VIP для внешних запросов:
Весь кластер имеет один набор первичных осколков и два набора дополнительных осколков (один первичный и два вторичных). Запросы, пересылаемые из узла шлюза, будут сбалансированы путем опроса перед ударом узлов данных. Способ добавления набора реплик к кластеру и расширению емкости машины увеличивает пропускную способность кластера, тем самым улучшая производительность запроса всего кластера.
На следующем рисунке представлена схематическая диаграмма производительности кластера ES центра заказов на каждом этапе, которая интуитивно показывает значительное улучшение производительности кластера ES после каждого этапа оптимизации:
Конечно, количество шардов и количество реплик шардов не в лучшую сторону, На этом этапе мы дополнительно изучили выбор подходящего количества шардов. Количество сегментов можно понимать как сегментированную базу данных и сегментированную таблицу в MySQL, а текущий запрос ES центра заказов в основном делится на две категории: запрос с одним идентификатором и запрос на пейджинг.
Чем больше количество сегментов, тем больше масштаб горизонтального расширения кластера.Пропускная способность запроса с одним идентификатором на основе маршрутизации по сегментам также может быть значительно повышена, но производительность запроса агрегированного пейджинга будет снижена; шардов, тем больше масштаб горизонтального расширения кластера, если он меньше, то производительность запроса одиночного идентификатора также снизится, но производительность пейджингового запроса улучшится.
Поэтому, как сбалансировать количество шардов и существующий бизнес запросов, мы сделали много корректировок и тестов под давлением, и, наконец, выбрали количество шардов с лучшей производительностью кластера.
4. Этап настройки кластера master-slave
Это центр заказов ES кластера начал формироваться, но из-за высоких требований к своевременности центра бизнес-заказов требования к стабильности запросов ES высоки, если есть ненормальный узел кластера, это повлияет на службы запросов, что повлияет на весь процесс заказа. Очевидно, что эта аномальная ситуация является фатальной, поэтому, чтобы справиться с этой ситуацией, наша первоначальная идея состоит в том, чтобы добавить альтернативный кластер, когда происходит аномалия основного кластера, вы можете запрашивать трафик в реальном времени, пониженный до резервного кластера.
Как должен быть построен резервный кластер? Как синхронизировать данные между активным и резервным? Какие данные должен хранить резервный кластер?
Учитывая, что в кластере ES на данный момент нет хорошего решения master-slave, и чтобы лучше контролировать запись данных ES, мы используем бизнес-метод двойной записи для построения кластера master-slave. Каждый раз, когда бизнес-операции необходимо записать данные ES, данные основного кластера записываются синхронно, а затем асинхронно записываются данные резервного кластера. В то же время большая часть трафика запросов ES приходится на заказы за последние дни, а данные базы данных центра заказов имеют механизм архивации для переноса заказов, закрытых до указанного количества дней, в базу исторических заказов.
Поэтому в механизме хранения добавлена логика удаления документов резервного кластера, чтобы данные заказа, хранящиеся во вновь построенном резервном кластере, соответствовали объему данных в онлайн-базе данных центра заказов. В то же время ZK используется для переключения управления потоком в службе запросов, чтобы гарантировать, что трафик запросов может быть понижен до резервного кластера в режиме реального времени. Здесь завершен мастер-ведомый кластер центра заказов и значительно улучшена стабильность службы запросов ES.
5. Сегодня: двухкластерный этап взаимного резервного копирования в режиме реального времени.
В течение этого периода, поскольку версия ES основного кластера была ниже 1.7, а текущая стабильная версия ES была обновлена до версии 6.x, новая версия ES не только обладает отличной оптимизацией производительности, но также предоставляет некоторые новые и полезные функции, поэтому мы. Основной кластер подвергся обновлению версии, непосредственно обновив исходную версию 1.7 до версии 6.x.
Процесс апгрейда кластера громоздкий и долгий, он нужен не только для того, чтобы онлайн-бизнес не повлиял, а апгрейд прошел плавно и незаметно, в то же время потому, что ES кластер на данный момент не поддерживает миграцию данных с 1.7 на 6. x в нескольких версиях необходимо перестроить индекс для обновления основного кластера, конкретный процесс обновления здесь повторяться не будет.
Первичный кластер при недоступности апгрейда неизбежно произойдет, но для заказов ЭП справочно-сервисного центра это не допускается. Таким образом, этап обновления, подготовленный для временной работы в качестве кластера поверх основного кластера, для поддержки всех онлайн-запросов ES, чтобы гарантировать, что процесс обновления не повлияет на обычные онлайн-сервисы. В то же время для онлайн-бизнеса мы планируем провести переопределение двух кластеров, медвежий онлайн-трафик запросов сделал перераспределение.
Коллекция кластерных магазинов является горячими данными в строке в последние дни. Данные намного меньше, чем первичный кластер, который составляет около одной десятой количества групп COP. Количество данных кластера невелико, и в той же шкале развертывания кластера производительность кластера лучше, чем основной набор.
Однако в реальном онлайн-сценарии большая часть онлайн-трафика запросов также исходит от горячих данных, поэтому резервный кластер используется для обработки запросов этих горячих данных, а резервный кластер постепенно превратился в кластер горячих данных. Предыдущий основной кластер хранил весь объем данных и использовал этот кластер для поддержки оставшейся меньшей части трафика запроса.Эта часть запроса в основном предназначена для специальных запросов сцены, которым необходимо искать полные заказы и внутренний запрос система центра заказов.Основной кластер также медленно эволюционирует в холодный кластер данных.
В то же время резервный кластер добавляет к основному кластеру функцию понижения в один клик.Статус двух кластеров одинаково важен, но каждый из них может быть понижен до другого кластера. Стратегия двойной записи также оптимизируется следующим образом: предполагается, что имеется кластер AB, ведущий (кластер A) записывается в обычном синхронном режиме, а резервный (кластер B) записывается асинхронно. Когда в кластере A возникает исключение, кластер B (главный) записывается синхронно, а кластер A (резервный) записывается асинхронно.
Схема синхронизации данных заказа ЭП
Данные MySQL синхронизируются с ES, что можно условно свести к двум схемам:
-
Вариант 1. Отслеживайте Binlog MySQL, анализируйте Binlog и синхронизируйте данные с кластером ES.
-
Схема 2: запись данных напрямую через кластер API ES ES.
Учитывая бизнес-специфику службы ES системы заказов, характер данных заказа в реальном времени относительно высок.Очевидно, что метод мониторинга Binlog эквивалентен асинхронной синхронизации, которая может вызвать большую задержку. Вариант 1 по существу аналогичен варианту 2, но вводится новая система, а также увеличивается стоимость обслуживания. Поэтому ES центра заказов принимает метод записи данных заказа напрямую через API ES.Этот метод является простым и гибким, и вполне может удовлетворить потребности синхронизации данных центра заказов с ES.
Поскольку синхронизация данных заказа ЭП прописана в бизнесе, при возникновении исключения во вновь созданном или обновленном документе повторная попытка неизбежно отразится на времени отклика нормальной работы бизнеса.
Таким образом, ЭП обновляется только один раз для бизнес-операции.Если возникает ошибка или исключение, вставьте корректирующую задачу в базу данных, а рабочая задача просканирует данные в режиме реального времени и снова обновит данные ЭП в соответствии с порядком базы данных. данные. Благодаря этому компенсационному механизму гарантируется возможная согласованность данных ES и данных заказа базы данных.
Некоторые ямы встретились
1. Запросы с высокими требованиями к реальному времени отправляются в БД
Студенты, знакомые с механизмом записи ES, могут знать, что вновь добавленные документы будут собраны в буфер индексирования, а затем записаны в кеш файловой системы.Оказавшись в кеше файловой системы, они могут быть проиндексированы, как и другие файлы.
По умолчанию документ автоматически обновляется из буфера индексации в файловую систему (т. Е. Операция обновления) автоматически обновляется в секунду, поэтому это то, что мы говорим, что ES похож на поиск в реальном времени, а не в режиме реального времени: Изменение документов не является немедленным, но он станет видимым в течение секунды.
Текущая система заказов ES принимает конфигурацию обновления по умолчанию, поэтому для тех предприятий, у которых есть большие данные о заказах в реальном времени, база данных напрямую запрашивается для обеспечения точности данных.
2. Избегайте глубоких пейджинговых запросов
Запрос пейджинга кластера ES поддерживает параметры from и size.При запросе каждый сегмент должен создать приоритетную очередь длиной from+size, а затем отправить ее обратно на узел шлюза.Затем узел шлюза сортирует эти приоритетные очереди, чтобы найти правильный документы одного размера.
Предположим, что в индексе с 6 первичными сегментами, начиная с 10000 и размером 10, каждый сегмент должен генерировать 10010 результатов, а 60060 результатов агрегируются и объединяются в узле шлюза, и, наконец, найдено 10 документов, соответствующих требованиям.
Видно, что когда from достаточно велико, даже если OOM не происходит, это повлияет на ЦП, пропускную способность и т. д., что повлияет на производительность всего кластера. Поэтому следует избегать запросов глубокого пейджинга и стараться их не использовать.
3. FieldData и значения документа
FieldData
Онлайн-запрос оказывается случайным сверхурочным, по вводу в эксплуатацию запрос, располагается отношения с сортировкой. Сортировать версию Es1.x - это структура Fielddata, FieldData занимается памятью JVM Heap, память JVM ограничена, для кэша Fielddata устанавливает пороговое значение.
Если места недостаточно, используйте алгоритм наибольшего неиспользования (LRU) для удаления FieldData и одновременной загрузки нового кэша FieldData.Процесс загрузки потребляет системные ресурсы и занимает много времени. Поэтому время ответа на этот запрос резко увеличилось, и даже пострадала производительность всего кластера. Решением этой проблемы является использование Doc Values.
Doc Values
Doc Values — это столбчатая структура хранения данных, похожая на FieldData, но место ее хранения — в файле Lucene, то есть она не занимает JVM Heap. С итерацией версии ES Doc Values более стабилен, чем FieldData, Doc Values является настройкой по умолчанию, начиная с 2.x.
Суммировать
Быстрая итерация архитектуры связана с быстрым развитием бизнеса Именно из-за быстрого развития бизнеса Daojia в последние годы архитектура центра заказов постоянно оптимизировалась и модернизировалась. Нет лучшего архитектурного решения, есть только самое подходящее.Я считаю, что через несколько лет архитектура центра заказов будет другим лицом, но с более высокой пропускной способностью, лучшей производительностью и большей стабильностью, это будет система центра заказов. вечная погоня.
Популярный контент:
1,"Список руководств по классификации исторических статей! Избранные отличные посты в блоге здесь! 》
2,Если кто-то взорвет сервер хранения Alipay
3.Разве это не просто оператор Select Count, им может злоупотреблять интервьюер!
5.Более 90% людей не знают, что такое круговая зависимость Spring.
6.За одну волну работы я увеличил эффективность выполнения SQL в 10 000 000 раз
7.В последнее время программистов часто арестовывают, как избежать тюремного программирования!
8,Насколько великолепна архитектура "12306"?
9,Прежде чем использовать Spring BeanUtils, рекомендуется сначала разобраться с этими ямами!
10.Пишите код таким образом, коллеги называют "666"