Ускоряем PHP-проект с помощью кэширования

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

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

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

Какие бывают подходы?

Существует множество подходов к кэшированию. Список совместимых с PHP инструментов можно посмотреть на странице PHP-cache. Самые распространенные из них:

Apcu
Array
Memcached
Redis

Давайте разберемся, какие особенности есть у каждого из них и чем они отличаются друг от друга.

APCu

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

php -i | grep 'apc.enabled'
# Ожидаем увидеть:
# apc.enabled => On => On

Другой способ проверки: создайте файл index.php и поместите в него вызов функции phpinfo(). Убедитесь, что у вас настроен веб-сервер для используемой директории и откройте скрипт в браузере через адрес сервера. Нас интересует секция APCu: если внутри неё есть пункт APCu Support: Enabled, значит всё хорошо, мы можем идти дальше.

Если APCu у вас не установлен, сделать это можно следующим способом:

Запустите окно терминала (Linux/MacOS) или командную строку (Windows. Введите в поиске "cmd").
Выполните команду:

pecl install apcu apcu_bc

Откройте в любом текстовом редакторе файл конфигурации php.ini и убедитесь в наличии следующих строк:

# Windows
extension=php_apcu.dll
extension=php_apcu_bc.dll
 
apc.enabled=1
apc.enable_cli=1
 
#Linux / MacOS
extension="apcu.so"
extension="apc.so"
 
apc.enabled=1
apc.enable_cli=1

Если указанных строк нет, добавьте их и сохраните файл конфигурации.
Повторите проверку наличия установленного APCu.

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

$cacheKey = 'product_1';
$ttl = 600; // 10 минут.
 
// Проверка доступности APCu
$isEnabled = apcu_enabled();
 
// Проверяет, есть ли данные в кэше по ключу
$isExisted = apcu_exists($cacheKey);
 
// Сохраняет данные в кэш. В случае успеха возвращает true
// Аргумент $ttl определяет, как долго будет храниться кэш (секунды)
$isStored = apcu_store($cacheKey, ['name' => 'Demo product'], $ttl);
 
// Получает данные из кэша по ключу. В случае их отсутствия, вернет false
$data = apcu_fetch($cacheKey);
 
// Удаляет данные из кэша по ключу
$isDeleted = apcu_delete($cacheKey);
 
var_dump([
    'is_enabled'   => $isEnabled,
    'is_existed'   => $isExisted,
    'is_stored'    => $isStored,
    'is_deleted'   => $isDeleted,
    'fetched_data' => $data,
]);

Любой кэш работает по принципу key-value хранилища: это значит, что данные сохраняются со специальным ключом, по которому и происходит обращение. В данном случае ключ хранится в переменной $cacheKey.

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

Array-кэш

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

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

class CustomArrayCache
{
    /**
     * Массив приватный и статический
     * - приватный — чтобы обращаться к нему можно было только
     * из методов класса.
     * - статический — чтобы свойство было доступно во всех экземплярах
     */
    private static array $memory = [];
 
    // Метод сохранения данных в памяти
    public function store(string $key, $value): bool
    {
        self::$memory[$key] = $value;
 
        return true;
    }
 
    // Метод получения данных из памяти
    public function fetch(string $key)
    {
        return self::$memory[$key] ?? null;
    }
 
    // Метод удаления данных из памяти
    public function delete(string $key): bool
    {
        unset(self::$memory[$key]);
 
        return true;
    }
 
    // Метод проверки наличия данных по ключу
    public function exists(string $key): bool
    {
        return array_key_exists($key, self::$memory);
    }
}

Из-за своей ограниченности этот подход применяется редко, однако знать о нём полезно.

Memcached и Redis

Наиболее продвинутые подходы кэширования. Подразумевают наличие запущенного отдельно сервера Memcached или Redis. Из PHP мы подключаемся к этому серверу по адресу и порту. Конфигурация этих решений сложнее, чем настройка APCu, но метод хранения данных очень похож: оперативная память. Самыми главными их преимуществами являются

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

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

Стандарт PSR-16

В PSR есть два стандарта, посвящённых кэшированию: PSR-6 (обычный интерфейс кэширования) и PSR-16 (простой интерфейс кэширования) — мы сосредоточимся на PSR-16.

Этот стандарт предлагает специальный интерфейс (CacheInterface), которому могут удовлетворять классы, выполняющие функцию кэширования. Согласно ему, такие классы должны реализовывать следующие методы:

get($key, $default) — получение данных из кэша: вторым аргументом передаётся значение, которое будет возвращено в случае отсутствия этих данных;
set($key, $value, $ttl = null) — сохранение данных в кэш: как мы уже видели ранее, третьим параметром передаётся время хранения в секундах. Если оставить его пустым (null), значение будет подставлено по умолчанию из конфигурации кэша;
delete($key) — удаляет данные по ключу;
clear() — очищает все хранилище;
getMultiple($keys, $default) — позволяет получить данные сразу по нескольким ключам;
setMultiple($values, $ttl = null) — позволяет записать сразу несколько значений. В качестве $value мы передаем ассоциативный массив, где ключ — $key для кэша, а значение — данные для сохранения;
deleteMultiple($keys) — удаляет данные по нескольким ключам;
has($key) — проверяет наличие данных по ключу.

Как вы можете заметить, интерфейс очень прост, и даже тех функций, что мы рассмотрели в примере с APCu, достаточно для того, чтобы написать свой сервис кэша в соответствии с PSR-16. Но зачем это нужно?

Главные преимущества соблюдения стандартов PSR заключаются в том, что

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

Давайте подробнее рассмотрим последний пункт и его преимущества.

Подключение PSR-16 библиотек

Библиотеки, создающие «обертку» над существующими инструментами кэширования для соответствия интерфейсу называются адаптерами. Для примера, рассмотрим адаптеры тех методов, что мы уже обсудили:

Все они удовлетворяют PSR-16 и поэтому применяются одинаково, однако логика «под капотом» у каждого своя.

Для примера давайте загрузим APCu- и Array-адаптеры в наш проект с помощью Composer.

composer require cache/array-adapter
composer require cache/apcu-adapter
# Или
composer req cache/apcu-adapter cache/array-adapter

Давайте представим, что у нас есть специальный класс для получения продуктов из базы данных. Назовем его ProductRepository, у него есть метод find($id), который возвращает продукт по его идентификатору, а если такого продукта нет — null.

class ProductRepository
{
    /**
     * Чтобы не усложнять пример, обусловимся, что в качестве продукта
     * возвращается массив, а если его нет — null
     */
    public function find(int $id): ?array
    {
        // ...
        // Получаем данные из БД
        return $someProduct;
    }
}

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

class ProductDataProvider
{
   private ProductRepository $productRepository;
   private CacheInterface $cache;
 
   public function __construct(ProductRepository $productRepository, CacheInterface $cache)
   {
       $this->productRepository = $productRepository;
       $this->cache             = $cache;
   }
 
   public function get(int $productId): ?array
   {
       $cacheKey = sprintf('product_%d', $productId);
 
       // Пробуем получить продукт из кэша
       $product = $this->cache->get($cacheKey);
       if ($product !== null) {
           // Если продукт есть, возвращаем
           // Временно выведем echo, чтобы понять, что данные из кэша
           echo 'Данные из кэша' . PHP_EOL; // PHP_EOL - перенос строки
           return $product;
       }
       // Если продукта нет, получаем его из репозитория
       $product = $this->productRepository->find($productId);
 
       if ($product !== null) {
           // Теперь сохраним полученный продукт в кэш для будущих запросов
           // Также временно выведем echo
           echo 'Данные из БД' . PHP_EOL;
           $this->cache->set($cacheKey, $product);
       }
 
       return $product;
   }
}

Наш класс готов. Теперь давайте рассмотрим его применение в сочетании с APCu-адаптером.

use Cache\\Adapter\\Apcu\\ApcuCachePool;
 
// Подключаем автозагрузчик Composer
require_once 'vendor/autoload.php';
 
// Наш репозиторий
$productRepository = new ProductRepository();
// APCu-кэш адаптер. Не требует никаких дополнительных настроек
$cache = new ApcuCachePool();
 
// Создаем провайдер, передаем зависимости
$productDataProvider = new ProductDataProvider(
    $productRepository,
    $cache
);
 
// Если в БД есть такой продукт, он к нам вернется
$product = $productDataProvider->get(1);
var_dump($product);

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

use Cache\\Adapter\\PHPArray\\ArrayCachePool;
// ...
$productRepository = new ProductRepository();
//$cache = new ApcuCachePool();
$cache = new ArrayCachePool();
$productDataProvider = new ProductDataProvider(
    $productRepository,
    $cache
);
// ...

Состояние гонки и обновление данных

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

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

пользователь 1 получил сущность из кэша;
пользователь 1 обновил сущность в БД;
пользователь 2 получил сущность из кэша;
пользователь 1 обновил данные в кэше;
пользователь 2 обновил сущность в БД, но перезаписал её старыми данными, потому что сущность была неактуальна на момент получения и т. д.

Такая ситуация называется состоянием гонки, когда несколько процессов обращаются одновременно к одному и тому же ресурсу, и может возникнуть конфликт версий. Чтобы избежать такой проблемы, следует придерживаться одного простого правила:

Когда вы получаете любую сущность в коде с целью её обновления, всегда используйте данные из БД.

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

Вы можете либо обращаться в нужных местах к ProductRepository вместо ProductDataProvider, либо добавить аргумент к методу DataProvider. Например, такой ($fromCache):

class ProductDataProvider
{
    // ...
    public function get(int $productId, bool $fromCache = true): ?array
    {
        $cacheKey = sprintf('product_%d', $productId);
 
        $product = $fromCache ? $this->cache->get($cacheKey) : null;
        if ($product !== null) {
            return $product;
        }
        $product = $this->productRepository->find($productId);
 
        if ($product !== null) {
            $this->cache->set($cacheKey, $product);
        }
 
        return $product;
    }
}

Заключение

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

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

Подводя итог, повторим ключевые идеи статьи:

Соблюдение PSR-16 (или PSR-6) позволит вам с легкостью подключить для кэширования стороннюю библиотеку и сделает ваш код понятным другим разработчикам.
Для небольших проектов хорошим решением для кэширования станет APCu, т. к. он прост в настройке и использует оперативную память, доступ к которой очень высокий.
Для всех совместимых с PHP-инструментов кэширования есть адаптеры, которые можно посмотреть на сайте php-cache.com.
Кэширование — отдельная ответственность. Старайтесь реализовывать работу с кэшем в отдельных классах.
Если мы собираемся обновить сущность, её следует получать из БД. Если сущность нужна нам только для просмотра — мы можем запросить её из кэша.
В крупных проектах для получения возможности масштабирования применяются Memcached или Redis.

Понравился наш сайт? Присоединяйтесь или подпишитесь (на почту будут приходить уведомления о новых темах) на наш канал в МирТесен!

Ускоряем PHP-проект с помощью кэширования

Какие бывают подходы?

APCu

Array-кэш

Memcached и Redis

Стандарт PSR-16

Подключение PSR-16 библиотек

Состояние гонки и обновление данных

Заключение

Комментарии

Поиск по блогу

Люди

Категории блога

Последние комментарии

Елена Булыгина предлагает Вам запомнить сайт «Ленусик»

Ускоряем PHP-проект с помощью кэширования

Какие бывают подходы?

APCu

Array-кэш

Memcached и Redis

Стандарт PSR-16

Подключение PSR-16 библиотек

Состояние гонки и обновление данных

Заключение

Комментарии

Поиск по блогу

Люди

Категории блога

Последние комментарии