Youzan что это за приложение
Русские Блоги
Практика обслуживания баз данных Youzan
Ян Цилонг
(Экранное имя: Север на Юге)
Работал в Hangzhou Youzan Technology DBA.
В основном отвечает за проектирование архитектуры базы данных
И работы по развитию платформы эксплуатации и обслуживания
Хорош в настройке производительности базы данных и диагностике неисправностей.
Увидимся в четверг | Серия открытых классов Чжишутан Из
Замечательные интерактивные вопросы и ответы
1. Как реализован запрос к подтаблице? К
Промежуточное программное обеспечение направляется в конкретную таблицу в соответствии с конкретным sharding_id. Вы можете обратиться к более популярному промежуточному программному обеспечению. Фактически, их общая логика одинакова, а sharding_id модулируется в соответствии с определенным алгоритмом.
2. Г-жа Ян, какая информация в основном собирается, когда моментальный снимок быстро обнаруживает проблему? Как собрать? К
Индикаторы основных данных thread_running, загрузка процессора хоста, размер памяти, использование io (вы можете использовать модуль Python psutil для получения информации о процессоре, памяти и размере диска).
3. Я чувствую, что г-н Ян много чего там делает, в том числе 2 платформы управления, один прокси и разные вещи, например, агент. Я хотел бы спросить господина Яна, как насчет нынешних членов команды? К
Два администратора баз данных отвечают за эксплуатацию и обслуживание базы данных и разработку zandb, а два разработчика промежуточного программного обеспечения отвечают за разработку rds.
4. Как рассчитывается размер отверстий в столе? Обеспечивается ли высокая доступность двух компьютерных залов по выделенной линии или через Интернет? Спасибо! К
5. Какой режим LVS использует в кластерах с высокой доступностью и как обеспечить высокую доступность LVS? К
Режим full nat, используемый на уровне LVS, и режим keepalived, используемый в режиме ha, будут позже изменены на режим ECMP.
6. https://pan.baidu.com/s/1qs1uzdvhoU4FGhXi9sjyMg#, как показано на рисунке, как показано на рисунке. Я хотел бы спросить г-на Яна, сколько всего таких таблиц существует, где вы находитесь? Вы считаете прямо из базы данных?
Это результат поиска? Большинство из них рассчитываются из базы данных, а некоторые получаются из результатов запроса в es.
7. Есть две проблемы:
1) Как учителя защищают конфиденциальные данные? К
2) Что за процесс представляет собой стресс-тест полного соединения? Сделайте краткое введение
1) Это не решалось на уровне отображения страницы, мы контролируем это на основе разрешений разработанной линейки продуктов.
2) Полный стресс-тест ссылки, см. Https://tech.youzan.com/stress_testing/
8. Требуется ли для разработки rds технология полного стека? Мне вообще нужно самому делать интерфейс? К
В настоящее время мы выполняем как интерфейс, так и серверную часть, и интерфейсная страница также создается нами, поэтому все еще существует порог технических требований. К
Для zandb я описал стек технологий, который мы использовали на ppt, вы можете обратиться к нему.
9. Как обеспечить своевременную синхронизацию структуры таблиц разработки и тестирования продукции? К
Обзор прямой трансляции 
Увидимся в четверг | Открытый класс 
Я впервые увидела фото учителя Яна
Он выглядит как студент колледжа, но уже является элитой отрасли.
Открытый классный обмен понятен, хорошо организован и полон галантерейных товаров.
Кругом много поклонников
, Все пятизвездочные похвалы
Видео-повторы и раздаточные материалы PPT онлайн, приходите и смотрите
Напоминание: содержание PPT ограничено. Для лучших результатов рекомендуется смотреть видео в сочетании с PPT!
Конспекты лекций этого публичного класса и записанныеВидеоПерейдите в Tencent Classroom, чтобы загрузить и просмотреть, ссылка:
https://ke.qq.com/course/329196 （ Открыть страницу-просмотр задачи-видео / лекции PPT можно посмотреть)
Отсканируйте QR-код ниже, чтобы идентифицировать
Или нажмите в конце статьи “Прочтите оригинал”Прямой доступ в класс Tencent
Присоединяйтесь к группе технического обмена QQ
(Номер группы QQ:650149401）
Русские Блоги
Решение Youzan WeChat Store для Android
I. Обзор
В настоящее время основной рабочий контент мобильного терминала Youzan находится в двух основных бизнес-направлениях: Youzan WeChat Mall и Youzan Retail. С ростом бизнеса Youzan Saas клиент также подвергается повторным итерациям и поддерживает все больше и больше Функция.
В контексте быстрого роста бизнеса общая архитектура мобильных технологий также постоянно корректировалась, чтобы обеспечить эффективность разработки и быстрое повторение бизнес-процессов.
Эта статья в основном знакомит с некоторыми идеями и реализациями компонентов Android Youzanwei Mall.
1.1 Статус
Архитектура клиента, начиная с начального режима «Все В ОДНОМ» (то есть весь код находится в Приложении), постепенно превратилась в текущую многомодульную структуру Единого Проекта:
1.2 Болевые точки
Новая структура проекта также порождает новые проблемы:
1.3 Проблемы, которые необходимо решить
2. Корректировка структуры
Хотя мы и раньше занимались разработкой всей модульности проекта, текущую модульную структуру можно назвать неполной:
Для решения вышеуказанных проблем нам необходимо скорректировать существующую структуру.
2.1 Абстракция модуля
Функция модуля абстрагируется от некоторых базовых классов для формирования модульного вспомогательного компонента. Он обеспечивает следующие функции:
2.2 Децентрализация государственных услуг
Я разговаривал со многими одноклассниками на стороне клиента, после того, как многие приложения разовьются до определенной стадии, неизбежно родится так называемый общий модуль. Это как большой шкафчик, каждый кладет в него то, что могут использовать другие люди.
У такого метода есть две проблемы:
2.2.1 Что общего?
2.2.2 Решения
2.3 Обслуживание бизнес-модулей
Термин «сервис-ориентированный» часто упоминается при разработке сервера. Короче говоря, он делится на несколько модулей в соответствии с бизнесом, и взаимодействие между модулями завершается предоставлением услуг друг другу.
С увеличением количества бизнес-модулей на стороне клиента неизбежно будут существовать бизнес-зависимости между бизнес-модулями, и традиционный способ зависимости модулей на стороне Android:
2.3.1 Реализация сервисной зависимости бизнес-модуля
2.3.2 Реализация уровня API
Есть много способов предоставить услуги внешнему миру:
2.3.3 Способ реализации API
Проблема протокола: если место, где предоставляется услуга, изменено, вам нужно вручную запросить все места, которые вызываются для внесения изменений, и нет управления версиями, и анализ данных необходимо преобразовать вручную.Стоимость изменения относительно высока, и есть определенные Риск стабильности.
Проблема метода интерфейса: требуется дополнительная зависимость (уровень API упакован отдельно в пакет aar), и пользователю необходимо добавить зависимость Mave, поэтому стоимость внедрения зависимости и публикации относительно высока.
Наконец, мы выбрали метод интерфейса. Этот метод обеспечивает лучшую стабильность и контроль версий. Для изменений процесс компиляции автоматически поможет вам проверить влияние изменений, а также внести зависимости и высокие затраты на выпуск. Это можно решить с помощью инструмента сборки (Gradle Plugin).
2.3.4 Уровень бизнес-реализации
На уровне бизнес-реализации необходимо реализовать бизнес-логику своего собственного модуля и реализовать интерфейс API, который он предоставляет для предоставления внешних сервисов.
2.4 Базовая абстракция компонентов
2.4.1 Реализация существующих базовых компонентов
Многие базовые компоненты проекта теперь инкапсулированы в Common, например: библиотека учетных записей, сетевая библиотека, загрузка изображений, библиотека веб-контейнеров и т. Д. Это также создает некоторые проблемы:
2.4.2 Идеи реализации
2.4.3 Структура зависимости
2.5 Одномодульная / многомодульная упаковка
С ростом объема и сложности бизнеса, а также с появлением множества сторонних компонентов количество инженерного кода на стороне клиента становится все больше и больше.Прямая проблема: медленная упаковка! Простой сценарий: после разработки функции внутри модуля продукта вам необходимо упаковать все приложение для его тестирования, а время упаковки пакета может составлять 5–10 минут. Если вы упаковываете его 10 раз в день, это более кислотно. Круто. Наши компоненты также должны поддерживать отдельный модуль или отдельные пакеты для упаковки. Идея состоит в том, чтобы настроить подключаемый модуль Gradle для динамического изменения подключаемого модуля Android Gradle, от которого модуль фактически зависит на этапе компиляции.
2.6 Схема архитектуры
Некоторые из вышеперечисленных улучшений сведены в картинку, которая выглядит так:
Три, план реализации
В настоящее время наше решение предоставляет 3 зависимости основных компонентов и 1 подключаемый модуль Gradle:
3.1 Modular-core
3.1.1 Реализация класса модуля
Класс бизнес-модуля должен унаследовать BaseModule:
Русские Блоги
Практика оплаты микросервисов Youzan
История развития технологий Youzan
2015 С 2016 по 2016 год, когда бизнес-трафик увеличился, существующая архитектурная модель столкнулась с трудностями, и компания начала двигаться в направлении разделения бизнеса и обслуживания. Начать принимать java В качестве языка разработки в сервис-ориентированной среде используются усовершенствованные dubbo x, платформа nova (v2.0), которая поддерживает вызовы между языками обслуживания.
В 2017 году на основе сервиса мы приблизились к архитектуре микросервиса. Используйте богатые компоненты, предоставляемые сообществом (v3.0).
Проблемы, с которыми мы столкнулись
С развитием бизнеса, размер команды также растет, в это время v1.0 монолитная архитектура столкнулась с проблемами
Программные системы или архитектура, в отличие от зданий из-за время Ход времени будет естественным образом повреждать и гнить, он будет гнить только из-за изменений. Четкая и аккуратная архитектура и реализация в начале спрос Меняется и становится мутным и хаотичным. Информатика любит заимствовать физический термин «энтропия», который выражает степень хаоса в системе, и «энтропия» системы программного обеспечения может легко стать выше по мере изменения потребностей.
«Энтропия» системы программного обеспечения имеет критическое значение. Когда критическое значение достигнуто и превышено, система программного обеспечения жизнь Это в основном закончилось. В настоящее время мы должны предпринять это убедительное действие. Легенда показывает жизненный цикл «энтропийного» значения программного обеспечения системы.
Будучи разделенным по направлениям бизнеса, он смог хорошо соответствовать развитию бизнеса. Однако v2.0 слишком тяжел для разработчиков и должен проделать определенную работу, чтобы облегчить реализацию архитектуры.
Почему вы выбираете spring boot
Решать проблему
youzan pom and youzan-boot-parent
Кроме того, для нашей существующей среды O & M были стандартизированы четыре набора сред: разработка, тестирование, предварительная версия и онлайн.
Мы развернем, чтобы опубликовать api jar в maven На складе существуют строгие ограничения: файл jar должен содержать только некоторые DTO и некоторые интерфейсы, но поскольку устройства для открывания дверей часто копируют и вставляют, они также добавляют различные ненужные зависимости (такие как пружина, различные каркасы журналов и т. Д.) В API приложение, использующее jar, имеет конфликт зависимостей, и потребуется некоторое время, чтобы найти конфликт и разрешить конфликт. надежда Используйте технические средства, чтобы быть последней линией защиты, и разрешите конфликт зависимостей, вызванный использованием других системных API из источника.
youzan appli cat ion
Мы надеемся обратиться к некоторым Открытый исходный код Компоненты и компоненты, разработанные компанией, проще в использовании и снижают стоимость доступа. Для этого мы расширили автоконфигурацию весенней загрузки и добавили различные стартеры.
Например, если мы хотим использовать фреймворк nova, просто аннотация @EnableNova
Применяйте стандартизированные проверки здоровья
Дизайн для отказа (CircuitBreaker)
Распределенная система В дизайне есть очень важный принцип: дизайн на провал, и ошибки обязательно будут. Чтобы предотвратить каскадные сбои системы, нам необходимо ограничить ресурсы, которые зависимые службы могут использовать для защиты самого приложения. Обычно необходимо учитывать следующие цели:
Ниже приведено краткое введение в принцип реализации Hystrix. Подробнее см. В официальной документации.
Параметры Hystrix можно динамически контролировать через центр конфигурации
Об обновлении API документации
Как пользователь api, разработчики часто обнаруживают, что документы устарели или даже неверны. программист Не люблю писать документы, потому что им нравится писать код, поэтому лучше всего использовать код для Автоматически генерируется Документы. Использование Spring Restdocs может автоматически генерировать документацию с помощью тестового кода, также есть преимущество, если поле увеличивается или уменьшается в интерфейсе, если нет синхронный Если вы обновите тест, тест не пройдет, поэтому вы можете быть уверены, что документ всегда актуален.
Сгенерированный документ API
Проблема с провайдером API
В компании или организация Внутренне, наибольшее беспокойство для провайдеров API заключается в том, чтобы не найти точно, кто такие потребители и как потребители используют свои API. Не говоря уже о ситуации после кадровых перестановок в компании. В реальном случае разработчик исправил орфографическую ошибку слова в поле. После публикации результата проверяющая сторона использовала это поле, что делало службу проверяющей стороны недоступной. На самом деле, после того, как такие сцены и события происходят много раз, разработчики будут напуганы, и они не исправят некоторые необоснованные замыслы и ошибки и позволят этому уйти.
На самом деле, коренной причиной этой проблемы является проблема модели сотрудничества между поставщиками услуг и потребителями. Мы надеемся, что существует какой-то механизм для решения этой проблемы. Если потребитель службы может уведомить поставщика услуг о сценарии использования API и реализовать его в тестовом коде, то поставщик услуг может быть осведомлен о сценариях использования каждого API проверяющей стороны. На самом деле, это дух контракта: поставщик услуг и проверяющая сторона должны все больше и больше обмениваться информацией и внедрять результаты обмена информацией в тестовый код. Конечно, есть несколько мощных инструментов и платформ, которые поддерживают наше видение. Контрактное тестирование предназначено для достижения этих целей. Для конкретных документов использования, пожалуйста, обратитесь к Spring Cloud Contract
Непрерывная интеграция
Нет необходимости говорить о преимуществах непрерывной интеграции, ключ к реализации.
Больше дохода
ссылка
Eric Evans — Tackling Complexity in the Heart of Software
microXchg 2017 – Juven Xu: AliExpress’ Way to Microservices
Русские Блоги
Идеи дизайна прозрачного многоуровневого кэширования (TMC) Youzan
Вступление
Что такое TMC
Основываясь на общем «решении для распределенного кэширования (например, CodisProxy + Redis, если вам нравится саморазвитая система распределенного кеширования zanKV)», TMC добавила следующие функции:
Обнаружение горячих точек на прикладном уровне
Локальный кеш прикладного уровня
Статистика попаданий в кеш уровня приложения
Чтобы помочь уровню приложения решить проблему доступа к точке доступа во время использования кеша.
Почему TMC
Есть много продавцов электронной коммерции, использующих сервисы Likes, и продавцы время от времени проводят некоторую «проверку продукта» и «продвижение продукта», что приводит к связыванию приложений, таких как «маркетинговая деятельность», «сведения о продукте» и «транзакционные заказы». появитьсяДоступ к кеш-точке доступаСлучай:
Такая информация, как время события, тип события, продукты события и т. Д., Непредсказуема, что приводит к непредсказуемому доступу к горячей точке кеша;
При появлении доступа к хотспоту кеша небольшое количество слоев приложенияКлюч доступа к точке доступаСоздавать большое количество запросов доступа к кэш-памяти: влиять на систему распределенного кеширования, занимать большую часть полосы пропускания интрасети и, в конечном итоге, влиять на стабильность системы прикладного уровня;
Чтобы справиться с вышеупомянутыми проблемами, необходимо решение, которое может автоматически обнаруживать горячие точки и пересылать запросы доступа к кэш-памяти горячих точек в локальный кеш на уровне приложений.Это причина для TMC.
Болевые точки решений для многоуровневого кеширования
Основываясь на приведенном выше описании, мы резюмировали следующиеРешение для многоуровневого кешированияНеобходимо решить болевые точки:
Обнаружение горячих точек: как быстро и точно найтиКлюч доступа к точке доступа ？
Согласованность данных: как обеспечить согласованность данных с системой распределенного кэша в локальном кэше на уровне приложения?
Проверка эффекта: как разрешить прикладному уровню просматривать частоту попаданий в локальный кеш, горячие клавиши и другие данные, чтобы проверить эффект многоуровневого кэширования?
Прозрачный доступ: как общее решение снижает вторжение в систему приложений и обеспечивает быстрый и плавный доступ?
Компания TMC сосредоточила внимание на вышеупомянутых проблемных точках, разработала и реализовала общее решение. Для поддержки «обнаружения горячих точек» и «локального кеша», уменьшения воздействия на нисходящие службы распределенного кэша при доступе к горячим точкам и избежания влияния на производительность и стабильность служб приложений.
Общая архитектура TMC
Общая структура TMC показана на рисунке выше, который разделен на три уровня:
Уровень хранения: предоставление базовых возможностей хранения данных квантового напряжения и выбор различных служб хранения (codis / zankv / aerospike) для различных бизнес-сценариев;
Уровень агента: Обеспечивает унифицированную запись кэша и протокол связи для прикладного уровня, а также выполняет работу по пересылке функций маршрутизации после разделения уровня распределенных данных;
Уровень приложений: предоставление унифицированного клиента для служб приложений, встроенного «обнаружения горячих точек», «локального кеша» и других функций, прозрачных для бизнеса;
Эта статья посвящена функциям «обнаружения горячих точек» и «локального кеширования» клиента прикладного уровня.
Локальный кеш TMC
Как быть прозрачным
Как TMC снижает проникновение в системы бизнес-приложений и обеспечивает прозрачный доступ?
Для сервисов Java-приложений компании существует два типа использования клиента кеширования:
на основе youzan.framework.redis Пакет, используйте RedisClient Напишите бизнес-код;
Независимо от того, какой метод используется, в конечном итоге он проходит JedisPool Создано Jedis Объект взаимодействует с прокси-уровнем кэш-сервера.
TMC для родного пакета jedis JedisPool с Jedis Класс был изменен в JedisPool Интегрированная функция TMC «обнаружение горячих точек» + «локальный кеш» во время инициализации Hermes-SDK Логика инициализации пакета позволяет клиенту Jedis сначала взаимодействовать с прокси-уровнем кеш-сервера. Hermes-SDK Взаимодействие для завершения прозрачного доступа к функциям «обнаружение горячих точек» + «локальный кеш».
Для служб приложений Java вам нужно использовать только определенную версию пакета jedis-jar, без изменения кода вы можете получить доступ к TMC. Используйте функцию «обнаружение горячих точек» + «локальный кеш», чтобы минимизировать вторжение в систему приложений.
весь кадр
Модульное деление
Общая структура локального кеша TMC разделена на следующие модули:
Jedis-Client: Прямая запись для взаимодействия между Java-приложениями и кеш-сервером, а определение интерфейса такое же, как и для собственного Jedis-Client;
Hermes-SDK: Пакет SDK собственной разработки с функцией «обнаружение горячих точек + локальный кеш», Jedis-Client интегрирует соответствующие возможности, взаимодействуя с ним;
Серверный кластер Hermes: Получать данные доступа к кешу, сообщаемые Hermes-SDK, выполнять обнаружение горячих точек и нажимать горячую клавишу в Hermes-SDK для локального кеширования;
Кэш-кластер: Состоит из уровня агента и уровня хранения, обеспечивая запись службы унифицированного распределенного кэша для клиентов приложений;
Основные компоненты: Кластер Etcd, центр конфигурации Apollo, предоставляющий TMC возможности «кластерного проталкивания» и «унифицированной конфигурации»;
Основной процесс
приобретение ключевой ценности
срок действия ключа истек
Открытие горячей точки
стабильность
Стабильность локального кеша TMC проявляется в следующих аспектах:
Отчетность по данным является асинхронной: Hermes-SDK использует технологию rsyslog для асинхронного создания отчетов о «ключевых событиях доступа», не блокируя бизнес;
Изоляция потока коммуникационного модуля: коммуникационный модуль Hermes-SDK использует независимый пул потоков + ограниченную очередь, чтобы гарантировать, что отчеты о событиях \ u0026amp; мониторинг операций ввода-вывода изолированы от потока выполнения бизнес-процессов, даже если возникают непредвиденные исключения, они не повлияют на основной бизнес. Особенности;
Управление кешем и контроль: модуль точки доступа Hermes-SDK контролирует верхний предел размера локального кеша, чтобы он занимал не более 64 МБ (LRU) памяти, предотвращая возможность переполнения кучи JVM;
последовательность
Согласованность локального кэша TMC проявляется в следующих аспектах:
Модуль точки доступа Hermes-SDK кэширует только данные горячих клавиш, а большая часть данных, не относящихся к горячим клавишам, хранится в кластере кеша;
Когда изменение горячей клавиши приводит к тому, что значение становится недействительным, Hermes-SDK синхронно аннулирует локальный кеш, чтобы гарантировать сильную локальную согласованность;
Когда изменение горячей клавиши приводит к тому, что значение становится недействительным, Hermes-SDK транслирует событие через кластер etcd и асинхронно аннулирует локальный кеш других узлов в кластере бизнес-приложений, чтобы гарантировать, что кластер в конечном итоге согласован;
Обнаружение горячей точки TMC
Общий процесс
Процесс обнаружения горячей точки TMC делится на четыре этапа:
Сбор данных: сбор данных о ключевых событиях доступа, о которых сообщает Hermes-SDK;
Скользящее окно тепла: поддерживайте колесо времени для каждого ключа приложения и записывайте количество посещений на основе скользящего окна текущего времени;
Сходимость по популярности: все ключи приложения отсортированы и суммированы в форме «ключ, популярность»;
Обнаружение горячих точек: для приложения выберите TopN Hot Key из сводных результатов сортировки горячих клавиш и отправьте его в Hermes-SDK;
сбор информации
Hermes-SDK помещает ключевые события доступа в Kafka в формате протокола через локальный rsyslog.Каждый узел кластера серверов Hermes использует сообщения Kafka и получает ключевые события доступа в режиме реального времени.
Формат протокола событий доступа следующий:
appName: бизнес-приложение, которому принадлежит узел кластера
uniqueKey: ключ события доступа к ключу бизнес-приложения.
sendTime: время, когда произошло событие доступа к ключу бизнес-приложения.
вес: значение веса доступа для события доступа к ключу бизнес-приложения
Узел кластера серверов Hermes хранит собранные ключевые события доступа в локальной памяти. Структура данных памяти: Map \ u0026lt; String, Map \ u0026lt; String, LongAdder \ u0026gt; \ u0026gt ;, а соответствующее бизнес-значение отображается на Map \ u0026lt ; appName, Map \ u0026lt; uniqueKey, популярность \ u0026gt; \ u0026gt ;.
Тепловое раздвижное окно
Скользящее окно времени
Узел кластера серверов Hermes поддерживает колесо времени для каждого ключа каждого приложения:
Картографическая задача
Узел кластера серверов Hermes каждые 3 секунды генерирует задачу сопоставления для каждого приложения, которая выполняется «пулом потоков сопоставления кэша» в узле. Задача сопоставления выглядит следующим образом:
Сбор тепла
После завершения второго шага «скользящего окна нагрева» задача сопоставления продолжает «сбор тепла» для текущего приложения:
Обнаружение горячей точки
Общий процесс обнаружения горячей точки TMC выглядит следующим образом:
Резюме функций
в реальном времени
Hermes-SDK сообщает о ключевых событиях доступа в реальном времени на основе rsyslog + kafka. Задача сопоставления завершает работу «скользящее окно нагрева» + «конвергенция тепла» за цикл в 3 секунды. Когда появляется сцена доступа к точке доступа, соответствующая горячая клавиша может быть обнаружена в течение 3 секунд.
точность
Результат схождения ключей достигается с помощью «скользящего окна на основе колеса времени», которое относительно точно отражает текущее и недавнее распределение доступа.
Масштабируемость
Узлы кластера серверов Hermes не имеют состояния, и количество узлов может масштабироваться по горизонтали в зависимости от количества разделов в Kafka.
Процесс «скользящее окно тепла» + «сбор тепла» основан на количестве приложений и многопоточном расширении в пределах одного узла.
Маркетинговая деятельность продавцов быстрого обслуживания
Продавцы Youzan участвуют в деятельности по продаже продукта через платформу прямой трансляции Kuaishou, что приводит к тому, что продукт посещается за короткий период времени для создания точек доступа. Фактические данные об эффекте посещения точки доступа, зарегистрированные TMC во время мероприятия, следующие:
Запрос кеширования основного приложения & amp; Кривая скорости попадания
На рисунке выше показана кривая скорости попадания в локальный кеш.
Можно видеть, что количество запросов кеша и попаданий в локальный кеш значительно увеличилось во время события, а частота попаданий в локальный кеш достигла почти 80% (то есть 80% запросов запросов к кешу в кластере приложений перехватываются локальным кешем TMC).
Влияние ускорения кеширования точек доступа на доступ к приложениям
На картинке выше показана кривая QPS интерфейса приложения.
На рисунке выше показана кривая RT интерфейса приложения.
Можно видеть, что количество запросов интерфейса приложения значительно увеличилось во время события, но RT интерфейса приложения уменьшилось из-за эффекта локального кэша TMC.
Частичное применение отображения эффекта TMC во время Double Eleven
Эффект основного приложения в предметной области
Эффект основного приложения области деятельности
Внешний вид функции TMC
В Юзан TMC в настоящее время предоставляет услуги для нескольких основных прикладных модулей, таких как товарные центры, логистические центры, складские центры, маркетинговые мероприятия, центры пользователей, шлюзы и сообщения, а также доступ к последующим приложениям.
Несмотря на то, что TMC предоставляет основные возможности «обнаружение горячих точек» + «локальный кэш», он также предоставляет гибкие параметры конфигурации для служб приложений. Службы приложений можно комбинировать с фактическими бизнес-условиями в «пороге горячей точки», «номере обнаружения горячей клавиши», «горячей точке». Параметр «черный и белый список» можно свободно настраивать для достижения лучшего эффекта использования.