Волшебный молниеносный тайник с системным полетом

Java Архитектура

Не завидуйте мандаринкам или бессмертным, а корректируйте строчку кода долго. Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.

Кэш в приложениях с высоким параллелизмом используется довольно часто. Зачем? просто такI/OЭто очень медленно! Чтобы устранить разницу в скорости между различными компонентами, все надеются добавить промежуточный слой, ожидая, что получится что-то волшебное.

Возьмем, к примеру, Redis, огонь — это беспорядок, но в середине будет много проблем с синхронизацией данных и согласованностью данных. Некоторые быдло-компании слишком назойливые и при этом имеют деньги, поэтому просто убивают БД за кешем и кладут все данные прямо в кеш. О нет, в настоящее время кэш больше не называется кэшем, его следует называть快存, потому что в конечном итоге он попадет через rdb.

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

Сценарий Lightning Cache

Тот闪电缓存Где свято? Мне очень жаль, этот термин был создан xjjdog.

Он используется в следующем сценарии.

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

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

srping-data-jpaЗа кэшем первого уровня Hibernate автоматически кэшируются данные того же сеанса, что можно рассматривать как замаскированный闪电缓存реализация . Однако он называется кешем первого уровня, который все больше и больше, а применение все более ограничено.

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

Метод реализации

На самом деле в Java существует множество способов кэширования молнии, и у них есть свои преимущества и недостатки.

ThreadLocal

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

Я могу использовать метод set, чтобы установить значение для данных при первом их извлечении. Затем используйте его в последней операции, удалите и внедрите замаскированный кеш молнии на уровне запроса. (Зачем удалять? Потому что могут быть проблемы с повторным использованием в пуле потоков)

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

Невозможно добиться прозрачной передачи потока. Вы можете обратиться к предыдущей статье xjjdog.

"Прозрачная передача локальной переменной ThreadLocal"

Это определяет ограниченные сценарии приложений ThreadLocal. Но у него есть еще два недостатка:

  1. Жизненный цикл ThreadLocal непрост в управлении, когда он генерируется и когда уничтожается, это проблема.
  2. ThreadLocal использует пользовательскийThreadLocalMap. Хотя он и называется Map, он не реализует интерфейс Map.открытая адресация(В случае конфликта ищите по очереди до свободной позиции), этот метод очень неэффективен

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

Обычный кэш плюс время истечения

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

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

LoadingCache<String, String> lc = CacheBuilder
            .newBuilder()
            .expireAfterWrite(3,TimeUnit.SECONDS)
            .build(new CacheLoader<String, String>() {
                @Override
                public String load(String key) throws Exception {
                    return slowMethod(key);
                }
});

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

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

End

Технология обычно является инструментом, и она имеет свою ценность только тогда, когда она действительно используется в бизнес-сценариях.闪电缓存В самой этой концепции нет ничего волшебного, лучший способ ее реализации — использовать обычный Кэш с очень коротким сроком действия.

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

Теперь xjjdog сказал вам, держите это в секрете.

Об авторе:Мисс сестра вкус(xjjdog), публичная учетная запись, которая не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус. Мой личный WeChat xjjdog0, добро пожаловать в друзья для дальнейшего общения.​

Категории