задний план

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

1. Подтвердите, нужно ли вам кешировать

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

Использование ЦП: если у вас есть приложения, которые требуют много ресурсов ЦП для вычислений, например, регулярные выражения, если вы часто используете регулярные выражения и они занимают много ЦП, то вам следует использовать кеш для хранения регулярных выражений. Результат кэшируется.
Использование операций ввода-вывода базы данных. Если вы обнаружите, что ваш пул соединений с базой данных относительно простаивает, вам не следует использовать кеш. Однако, если пул соединений с базой данных занят, и даже часто сообщается о недостаточном количестве соединений, то пора подумать о кэшировании. У автора когда-то была служба, которую вызывали многие другие службы, и в другое время с ней было все в порядке, но каждое утро в 10:00 всегда сообщалось о недостаточном количестве соединений с пулом соединений с базой данных. выполнил запланированное задание, и поступило большое количество запросов. Пула соединений с БД было недостаточно, поэтому было сообщено о тревоге о том, что пула соединений недостаточно. В настоящее время есть несколько вариантов, мы можем решить это, расширив машину или увеличив пул соединений с базой данных, но нет необходимости увеличивать эти затраты, потому что эта проблема возникнет только в 10 часов. Позже было внедрено кэширование, которое не только решило эту проблему, но и увеличило производительность чтения.

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

2. Выберите правильный кеш

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

2.1 Выберите подходящий кеш процесса

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

сравнение	ConcurrentHashMap	LRUMap	Ehcache	Guava Cache	Caffeine
Чтение и запись производительности	хорошо, блокировка сегмента	Как правило, глобальная блокировка	хорошо	Хорошо, нам нужно выполнить операцию исключения	очень хороший
Алгоритм исключения	никто	ЛРУ, генерал	Поддержка нескольких алгоритмов исключения, LRU, LFU, FIFO	ЛРУ, генерал	W-TinyLFU, очень хорошо
богатство функций	Функция относительно проста	Функция относительно проста	очень функциональный	Функция очень богата, поддерживает обновление и виртуальную ссылку и т. Д.	По функциям аналогичен Guava Cache.
Размер инструмента	JDK поставляется с классами, очень маленькими	На основе LinkedHashMap, меньше	Очень большой, последняя версия 1.4MB	это небольшая часть класса инструментов Guava, меньшая	Как правило, последняя версия составляет 644 КБ.
Это постоянно	нет	нет	да	нет	нет
Поддерживать ли кластер	нет	нет	да	нет	нет

Для ConcurrentHashMap больше подходит кэширование относительно фиксированных элементов, а количество кэшей невелико. Хотя он немного уступает приведенной выше таблице, потому что это класс, который поставляется с jdk, он по-прежнему широко используется в различных фреймворках, например, мы можем использовать его для кэширования нашего отраженного метода, поля и т. д., мы можем также кешируйте некоторые ссылки, чтобы предотвратить их дублирование. ConcurrentHashMap также используется в Caffeine для хранения элементов.
Для LRUMap, если вы не хотите вводить сторонние пакеты и хотите использовать алгоритм исключения для удаления данных, вы можете использовать это.
Для Ehcache, потому что его jar-пакет большой и тяжелый. Для некоторых функций, требующих сохраняемости и кластеризации, можно выбрать Ehcache. Автор мало использовал этот кеш, если хотите выбрать, то вместо Ehcache можете выбрать распределенный кеш.
Для Guava Cache пакет jar Guava был широко представлен во многих Java-приложениях, поэтому во многих случаях достаточно использовать его напрямую, он легкий и богат функциями.Если вы не знаете, Caffeine Guava Cache может быть выбран в случае .
Что касается Caffeine, я настоятельно рекомендую его: его скорость попадания и производительность чтения и записи намного лучше, чем у Guava Cache, а его API в основном такой же, как у Guava cache, или даже немного больше. Использование Caffeine в реальных условиях дало хорошие результаты.

Подводя итог: если вам не нужен алгоритм исключения, выберите ConcurrentHashMap.Если вам нужен алгоритм исключения и некоторые богатые API, мы рекомендуем выбрать Caffeine.

2.2 Выберите подходящий распределенный кеш

Здесь мы выбираем для сравнения три известных распределенных кеша: MemCache (не используется в реальном бою), Redis (также известный как Squirrel в Meituan) и Tair (также известный как Cellar в Meituan). Разные распределенные кэши имеют большие различия в функциональных характеристиках и принципах реализации, поэтому сценарии, под которые они адаптируются, также отличаются.

сравнение	MemCache	Squirrel/Redis	Cellar/Tair
структура данных	Поддерживаются только простые структуры Key-Value.	String,Hash, List, Set, Sorted Set	Строка, HashMap, Список, Набор
Упорство	не поддерживается	служба поддержки	служба поддержки
емкость	Данные - это чистая память, и места для хранения данных не должно быть слишком много.	Данные находятся в полной памяти, а стоимость ресурсов не должна превышать 100 ГБ.	Полная память или память + дисковый движок могут быть настроены, емкость данных может быть бесконечно расширена
Чтение и запись производительности	очень высоко	Очень высокий (RT0,5 мс или около того)	Строковый тип относительно высок (около RT1 мс), сложный тип относительно медленный (около RT5 мс)

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

Резюме: если служба чувствительна к задержке и имеется много данных Map/Set, больше подходит Redis. Если сервису нужно поместить в кеш большой объем данных и он не особо чувствителен к задержкам, то можно выбрать Таир. Tair используется во многих приложениях Meituan, а также используется в авторском проекте для хранения генерируемого платежного токена и платежного кода, который используется для замены хранилища базы данных. В большинстве случаев оба могут быть выбраны и заменять друг друга.

3. Многоуровневый кеш

Когда многие люди думают о кэшировании, в их голове возникает следующая картина:

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

Когда я представил локальное кэширование раньше, многие люди спрашивали меня, у меня уже есть Redis, зачем мне знать о кэшах процессов, таких как Guava и Caffeine. Я в основном отвечаю на следующие два ответа:

Если Redis зависнет или использует старую версию Redis, он выполнит полную синхронизацию.В это время Redis недоступен.В это время мы можем только получить доступ к базе данных, что может легко вызвать лавину.
Доступ к Redis будет иметь определенный сетевой ввод-вывод, а также сериализацию и десериализацию.Хотя производительность высока, это не так быстро, как локальный метод.Самые горячие данные могут храниться локально для дальнейшего ускорения скорости доступа. Эта идея не уникальна для нашей интернет-архитектуры.Мы используем многоуровневые кэши L1, L2 и L3 в компьютерных системах, чтобы сократить прямой доступ к памяти и ускорить доступ.

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

3.1 Использование кеша процессов

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

Объем данных не очень большой, и частота обновления данных низкая.Раньше у нас был сервис для запроса названия компании, который нужно вызывать при отправке короткого сообщения.Поскольку название компании меняется реже, и даже если он изменен, кеш не меняется вовремя.Клиенты со старыми названиями также приемлемы. Используя Caffeine в качестве локального кеша, размер установлен на 10 000, а время истечения установлено на 1 час, что в основном может решить проблему в пиковый период.
Если объем данных часто обновляется и вы хотите использовать кеш процесса, вы можете установить более короткое время его истечения или установить более короткое время автоматического обновления. Это готовые API для Caffeine или Guava Cache.

3.2 Использование многоуровневого кэша

Как говорится, в мире нет ничего, что не мог бы решить один кеш, если есть, то их два.

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

Используйте Caffeine для создания кеша, Redis в качестве вторичного кеша.

Сначала перейдите к Caffeine, чтобы запросить данные, если есть какой-либо прямой возврат. Если нет, перейдите к шагу 2.
Затем перейдите к Redis для запроса, если запрос возвращает данные, и заполните эти данные в Caffeine. Если не найдено, перейдите к шагу 3.
Наконец, перейдите к Mysql для запроса.Если возвращенные данные будут запрошены, они будут заполнены в Redis и Caffeine по очереди.

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

Установите, через какое время после записи истекает срок действия
Установите, сколько времени будет обновляться после записи

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

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

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

4. Обновление кеша

Вообще говоря, есть две ситуации для обновления кеша:

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

4.1 Сначала удалите кэш, затем обновите базу данных

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

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

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

4.2 Сначала обновите базу данных, затем удалите кеш (рекомендуется)

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

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

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

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

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

5. Три мушкетера копания тайника

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

5.1 Проникновение в кэш

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

Чтобы избежать этой проблемы, вы можете принять следующие две меры:

Соглашение: для возврата NULL он по-прежнему кэшируется, а возврат исключения не кэшируется.Будьте осторожны, чтобы не кэшировать выброшенное исключение. Использование этого метода увеличит стоимость обслуживания нашего кеша.Необходимо удалять пустой кеш при вставке кеша.Конечно, мы можем решить эту проблему, установив более короткий период ожидания.

2. Создайте некоторые правила для фильтрации некоторых невозможных данных, используйте BitMap для небольших данных и используйте фильтр Блума для больших данных.Например, ваш идентификатор заказа, очевидно, находится в диапазоне 1-1000, если это не данные в пределах 1-1000 На самом деле его можно отфильтровать напрямую.

5.2 Разбивка кэша

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

Чтобы избежать этой проблемы, мы можем принять следующие две меры:

Добавить распределенную блокировку: при загрузке данных вы можете использовать распределенную блокировку, чтобы заблокировать ключ этих данных, и использовать операцию setNX непосредственно в Redis.Для потока, который получил эту блокировку, запросите базу данных для обновления кеша, а другие потоки примут стратегия повторных попыток, чтобы к базе данных не обращались многие потоки одновременно.
Асинхронная загрузка: поскольку сбой кэша — это проблема, возникающая только с данными горячих точек, для этой части данных горячих точек может быть принята стратегия автоматического обновления по истечении срока действия, а не автоматическое удаление по истечении срока действия. Исключение на самом деле для своевременности данных, поэтому также можно использовать автоматическое обновление.

5.3 Лавина кэша

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

Чтобы избежать этой проблемы, мы принимаем следующие меры:

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

6. Загрязнение кэша

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

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

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

7. Сериализация

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

Объект "ключ-значение" слишком сложен, а сериализация не поддерживается: у меня была проблема раньше. В Meituan's Tair по умолчанию используется protostuff для сериализации, а коммуникационная структура, используемая Meituan, - thfift, а TO thrift автоматически сгенерировано , В этом ТО много сложных структур данных, но они хранятся в Таире. Ошибки в десериализации при запросе нет, и одиночный тест тоже проходит, но когда дело доходит до теста qa, то обнаруживается, что есть проблема с этой функцией.Обнаружено, что поле логического типа и значение по умолчанию равно false После изменения его на true сериализуйте его в tair Он по-прежнему будет ложным, если он будет десериализован в середине. Выяснилось, что protostuff не очень хорошо поддерживает объекты со сложной структурой (такие как массивы, списки и т. д.), что вызовет определенные проблемы. Позже этот TO был преобразован, и корректная сериализация и десериализация могут быть выполнены с обычными Java-объектами.
Поля добавляются или удаляются, что приводит к ошибкам десериализации или сдвигу некоторых данных при получении старого кеша после выхода в сеть.
Разные JVM имеют разную сериализацию.Если в вашем кеше есть разные сервисы, которые используются вместе (не рекомендуется), то вам нужно обратить внимание на разные JVM, которые могут по-разному сортировать поля внутри класса, что повлияет на сериализацию. Например, в следующем коде порядок объекта A отличается в Jdk7 и Jdk8, что в конечном итоге вызовет проблемы с результатом десериализации:

//jdk 7
class A{
    int a;
    int b;
}
//jdk 8
class A{
    int b;
    int a;
}

На проблему сериализации нужно обратить внимание, и решения следующие:

Тест: Для сериализации требуется комплексный тест.Если есть разные сервисы и их JVM разные, то вам также нужно сделать этот тест.В приведенном выше вопросе причина, по которой автор прошел единый тест, заключается в том, что данные по умолчанию ложны Так что настоящего теста вообще нет. К счастью, QA является мощным и протестировал его.
У разных фреймворков сериализации свои принципы.После добавления полей, если текущая фреймворк сериализации несовместима со старым, вы можете изменить фреймворк сериализации. Для protostuff он десериализуется в порядке Field, для добавления полей нам нужно ставить его в конец, то есть его нельзя вставлять в середину, иначе будет ошибка. Для удаленных полей используйте аннотацию @Deprecated, чтобы пометить их как устаревшие.Если вы удалите их поспешно, если это не последнее поле, обязательно возникнет исключение сериализации.
Чтобы избежать этого, можно использовать двойную запись. Номер версии можно добавить к каждому кэшированному значению ключа, а номер версии увеличивается на 1 каждый раз, когда он подключается к сети. Например, текущий онлайн-кеш использует Key_1, а тот, который будет онлайн это Key_2.Добавление кеша запишет Key-Value новой и старой версии (Key_1, Key_2), прочитает данные или прочитает данные старой версии Key_1, предполагая, что время истечения срока действия Предыдущий кеш - полчаса, затем подключитесь к сети на полчаса. Через час данные в старом кеше будут удалены. В это время данные в старом онлайн-кэше и новом кеше в основном одинаковы. операцию чтения в новый кэш, а затем остановить двойную запись. Использование этого метода может в основном сгладить переход между новой и старой моделями, но недостатком является то, что два набора новых и старых моделей необходимо поддерживать в течение короткого времени, а старые модели необходимо удалять в следующий раз, когда они подключаются к сети. что увеличивает затраты на обслуживание.

8. Настройка GC

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

Почаще проверяйте ГХ мониторинг, как найти аномалии, нужно найти способ его оптимизировать.
Для сборщика мусора CMS, если обнаружится, что примечание слишком длинное, если это большое количество приложений локального кэша, это должно быть нормальным, потому что на параллельном этапе в кэш легко может попасть много новых объектов, поэтому сканирование на этапе примечания занимает много времени, и примечание будет приостановлено. Вы можете включить -XX:CMSScavengeBeforeRemark для выполнения YGC перед фазой примечания, тем самым уменьшив накладные расходы на сканирование корня gc на этапе примечания.
Вы можете использовать сборщик мусора G1 и установить максимальное время паузы с помощью -XX:MaxGCPauseMillis, чтобы повысить доступность службы.

9. Мониторинг кеша

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

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

10. Хороший фреймворк

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

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

Рекомендуется использовать платформу с открытым исходным кодом JetCache, которая реализует спецификацию кэша Java JSR107 и поддерживает расширенные функции, такие как автоматическое обновление. Автор ссылается на JetCache в сочетании с Spring Cache, инфраструктурой мониторинга Cat и инфраструктурой ограничения тока автоматического выключателя Meituan Rhino для реализации набора собственной инфраструктуры кэширования, позволяющей бизнес-персоналу управлять кэшем, управлять мониторингом, автоматическим выключателем и переходом на более раннюю версию, а бизнес-персоналу делать не нужно заботиться. Приведенный выше код можно оптимизировать для:

Для некоторых данных мониторинга это также легко увидеть из рынка:

Наконец

Если вы хотите действительно использовать кеш, вы должны освоить много знаний.Вы можете использовать кеш Redis в совершенстве, не заглядывая в несколько основных анализов Redis. Для разных сценариев у кешей разное использование, и у одних и тех же разных кешей тоже свои стратегии настройки.Для внутрипроцессных кешей нужно обратить внимание на алгоритм его устранения и настройку GC, а также на избежание загрязнения кеша. На что вам нужно обратить внимание в распределенном кеше, так это на его высокую доступность, на то, как перейти на более раннюю версию, если он недоступен, и на некоторые проблемы с сериализацией. Важен и хороший фреймворк, при правильном использовании и описанном выше опыте, думаю, он позволит вам управлять этой дикой лошадкой — кешем.

Наконец, эта статья была включена в JGrowing, всеобъемлющий и отличный маршрут изучения Java, совместно созданный сообществом.Если вы хотите участвовать в обслуживании проектов с открытым исходным кодом, вы можете создать его вместе.Адрес github:GitHub.com/Java растет…Пожалуйста, дайте мне маленькую звезду.

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