Кэши для «чайников»29.11.2016 10:35

    {{ get_current_rate("USD","EUR")|format(".2f") }} USD/EUR

Наивная имплементация делает самое простое, что можно придумать: на каждый запрос от пользователя спрашивает удалённую систему и использует ответ напрямую. Это означает, что теперь каждые 1000 просмотров пользователями нашей страницы стоят для нас на копейку больше. Казалось бы — гроши. Но вот проект растёт, у нас уже 1000 постоянных пользователей, которые каждый день заходят на сайт и просматривают по 20 страниц, а это уже 6 евро в месяц, что превращает сайт из бесплатного во вполне уже сопоставимый с платой за самые дешевые выделенные виртуальные серверы.

Вот тут на сцену выходит его величество Кэш.

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

Сказано — сделано! Добавляем несколько строчек:

addServer("localhost", 11211);
  $rate = $memcache->get($cache_key);
  if ($rate) {
    return $rate;
  } else {
    $api_host = "http://rates.example.com/";
    $args = ["currency1=".urlencode($currency1), "currency2=".urlencode($currency2)];
    $rate = @file_get_contents($api_host."?".join("&", $args));
    if ($rate === FALSE) {
      return $rate;
    } else {
      $memcache->set($cache_key, (float) $rate, 0, 5);
      return (float) $rate;
    }
  }
}

И вуаля! Сайт снова становится для нас почти бесплатным… До конца месяца, когда мы обнаруживаем от внешней системы счет на 4 евро. Конечно, не 6, но мы ожидали намного большей экономии!

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

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

В случае с memcache это можно реализовать, например, так:

addServer("localhost", 11211);
  while (true) {
    $rate = $memcache->get($cache_key);
    if ($rate == "?") {
      sleep(0.05);
    } else if ($rate) {
      return $rate;
    } else {
      // Создаём запись, только один сможет это сделать, остальные уйдут спать
      if ($memcache->add($cache_key, "?", 0, 5)) {
        $api_host = "http://rates.example.com/";
        $args = ["currency1=".urlencode($currency1), "currency2=".urlencode($currency2)];
        $rate = @file_get_contents($api_host."?".join("&", $args));
        if ($rate === FALSE) {
          return $rate;
        } else {
          $memcache->set($cache_key, (float) $rate, 0, 5);
          return (float) $rate;
        }
      }
    }
  }
}

Почему 2? Было 6 без кэширования для тысячи человек, мы же всё закэшировали, а сократилось всего в 3 раза? Да, стоило просчитать пораньше… 1 раз в 5 секунд = 12 в минуту = 72 в час = 576 за рабочий день = 17 тысяч в месяц, а ещё не все ходят по расписанию, есть странные личности заглядывающие поздней ночью… Вот и получается, в пике вместо сотни обращений одно, а в тихое время — по-прежнему запрос почти на каждое обращение проходит. Но всё равно, даже в худшем случае счёт должен быть 31×86400÷5 = 5.36 евро.

Так мы познакомились с еще одной гранью: кэш помогает, но не устраняет нагрузку.

Впрочем, в нашем случае люди приходят в проект и уходят и в какой-то момент начинают жаловаться на тормоза: страницы замирают на несколько секунд. А еще бывает под утро сайт не отвечает вообще… Просмотр консоли сайта показывает, что иногда днём запускаются дополнительные инстансы. В это же время скорость выполнения запросов падает до 5–15 секунд на запрос — из-за чего это и происходит.

Упражнение для читателя: посмотреть внимательно предыдущий код и найти причину.

Да-да-да. Конечно же, это в ветке if ($rate === FALSE). Если внешний сервис вернул ошибку, мы не освободили блокировку… В том смысле, что »?» так и остался записан, и все ждут когда он устареет. Что ж, это легко исправить:

        if ($rate === FALSE) {
          $memcache->delete($cache_key);
          return $rate;
        } else {

Итак, мы исправили проблему, вот только ничего не изменилось: всё равно изредка начинались тормоза. Что примечательно, они совпадали по времени с информационным бюллетенем от внешней системы о технических работах…

Ну-ка ну-ка… Давайте сделаем краткую передышку и пересчитаем, что мы насобирали уже сейчас, что должен уметь кэш:

1. помнить последний известный результат;
2. дедуплицировать запросы, когда результат еще или уже не известен;
3. обеспечивать корректную разблокировку в случае ошибки.

Заметили? Кэш должен обеспечивать пункты 1–2 и для случая ошибки! Изначально это кажется очевидным: мало ли что случилось, отвалился один запрос, следующий обновит. Вот только что произойдёт, если и следующий тоже вернет ошибку? И следующий? Вот у нас пришло 10 запросов, первый захватил блокировку, попробовал получить результат, отвалился, вышел. Следующий проверяет — так, блокировки нет, значения нет, идём за результатом. Обломался, вышел. И так для каждого. Ну глупость же! По хорошему 10 пришло, один попробовал — все отвалились. А уже следующий пусть попробует заново!

Отсюда: кэш обязан уметь какое-то время хранить отрицательный результат. Наше наивное исходное предположение по сути подразумевает хранение отрицательного результата 0 секунд (но передачу этого самого отрицания всем, кто уже ждёт его). К сожалению, в случае с Memcache реализация нулевого времени ожидания весьма проблематична (оставлю как домашнее задание въедливому читателю; cовет: используйте механизм CAS; и да, в AppEngine можно использовать и Memcache и Memcached).

Мы же просто добавим сохранение отрицательного значения с 1 секундой жизни:

addServer("localhost", 11211);
  while (true) {
    $flags = FALSE;
    $rate = $memcache->get($cache_key, $flags);
    if ($rate == "?") {
      sleep(0.05);
    } else if ($flags !== FALSE) {
      // Если ключа нет, тип не меняется, иначе будет число,
      // и мы вернём любое значение из кэша, даже false.
      return $rate;
    } else {
      if ($memcache->add($cache_key, "?", 0, 5)) {
        $api_host = "http://rates.example.com/";
        $args = ["currency1=".urlencode($currency1), "currency2=".urlencode($currency2)];
        $rate = @file_get_contents($api_host."?".join("&", $args));
        if ($rate === FALSE) {
          // Здесь мы можем задать отдельный срок жизни отрицательного значения
          $memcache->set($cache_key, $rate, 0, 1);
          return $rate;
        } else {
          $memcache->set($cache_key, (float) $rate, 0, 5);
          return (float) $rate;
        }
      }
    }
  }
}

…А вот и нет. Внимательно посмотрим на код еще раз: запрос ко внешней системе будет исполняться столько, сколько позволит file_get_contents(). На время исполнения запроса все остальные ждут, поэтому каждый раз, когда кэш устаревает, все потоки ждут исполнения главного, и получат новые данные только, когда они поступят.

Что ж, мы можем вместо ожидания, добавить ветку else{} у условия вокруг memcache->add… Правда, стоит, наверное, вернуть последнее известное значение, да? Ведь мы кэшируем ровно затем, что мы согласны получить устаревшие сведения, если нет свежих; итак, еще одно требование к кэшу: пусть подтормаживает не более одного запроса.

Сказано — сделано:

addServer("localhost", 11211);
  while (true) {
    $flags = FALSE;
    $rate = $memcache->get($cache_key, $flags);
    if ($rate == "?") {
      sleep(0.05);
    } else if ($flags !== FALSE) {
      return $rate;
    } else {
      if ($memcache->add($cache_key, "?", 0, 5)) {
        $api_host = "http://rates.example.com/";
        $args = ["currency1=".urlencode($currency1), "currency2=".urlencode($currency2)];
        $rate = @file_get_contents($api_host."?".join("&", $args));
        if ($rate === FALSE) {
          // Мы не меняем последнее успешное значение, пусть смотрят на
          // устарелые сведения. При желании, поведение можно изменить.
          $memcache->set($cache_key, $rate, 0, 1);
          return $rate;
        } else {
          // Ставим срок жизни бесконечным для _stale_ ключа, но можем и задать
          // какой-нибудь большой: например, минуту, тем самым ограничив
          // срок жизни устаревших сведений.
          $memcache->set("_stale_".$cache_key, (float) $rate);
          $memcache->set($cache_key, (float) $rate, 0, 5);
          return (float) $rate;
        }
      } else {
        // Если нет актуальных данных, и не мы их обновляем —
        // вернём значение из копии данных, для которых не указан срок жизни.
        // Если и их нет, то вернём false, что соответствует обычному поведению.
        return $memcache->get("_stale_".$cache_key);
      }
    }
  }
}

Примечание: обычный PHP по умолчанию пишет сессии в файлы, блокируя параллельные запросы. Чтобы избежать этого поведения, можно передать в session_start параметр read_and_close либо принудительно закрывать через session_close сессию после совершения всех необходимых изменений, иначе тормозить будет не одна страница, а один пользователь: так как скрипт, обновляющий значение, будет блокировать открытие сессии другим запросом от того же пользователя. При исполнении на AppEngine по умолчанию включено хранение сессий в memcache, то есть без блокировок, поэтому будет проблема не так заметна.

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

Что же мы можем сделать в такой постановке вопроса? Мы можем:

1. Попытаться исполнить трюки «исполнение после ответа», то есть если мы должны обновить значение — регистрируем хендлер, который это сделает после исполнения всего остального скрипта. Вот только это сильно зависит от приложения и окружения исполнения; самый надёжный способ — использование fastcgi_finish_request(), требующий настройку сервера через php-fpm (соответственно, недоступен для AppEngine).
2. Сделать обновление в отдельном потоке (то есть выполнить pcntl_fork() или запустить скрипт через system() или ещё как-то) — опять же, может сработать для своего сервера, иногда даже работает на некоторых shared-хостингах, где не сильно озаботились безопасностью, но, разумеется, не сработает на сервисах с параноидальной безопасностью, то есть AppEngine не подходит.
3. Иметь постоянно работающий фоновый процесс для обновления кэша: процесс должен с заданной периодичностью проверять, не устаревает ли значение в кэше, и если срок жизни подходит к концу, а значение требовалось за время жизни кэша — обновляет его. Мы обсудим этот момент чуть позднее, когда устанем уже от нашего бедного сайта с курсом валюты и перейдём к более весёлым материям.

По сути поддержание данных во всегда горячем состоянии — задача чуть более сложная, чем просто несколько строчек PHP-кода, поэтому для нашего простого случая нам придётся смириться с тем, что какой-то запрос будет регулярно «задумываться» (важно: не случайный, а какой-то; то есть не random, а arbitrary). Применимость этого подхода всегда важно примерять к задаче!

Итак, наш поставщик данных растёт, но не все его клиенты читают хабр, а потому они не используют правильного кэширования (если используют его вообще) и в какой-то момент начинают выдавать огромное количество запросов, из-за чего сервису становится плохо, и эпизодически он начинает отвечать не просто медленно, а очень медленно. До десятков секунд и более. Пользователи, конечно, быстро обнаружили, что можно нажать F5 или иначе перезагрузить страницу, и она появляется моментально — вот только страница снова начала упираться в бесплатные пределы, так как постоянно начали висеть процессы, просто ожидающие внешний ответ, но потребляющие наши ресурсы.

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

1. Пришел запрос 1, данных в кэше нет, так что добавили маркер '?' на 5 секунд и пошли за курсом.
2. Спустя 1 секунду пришел запрос номер 2, увидел маркер '?', вернул данные из stale записи.
3. Спустя 3 секунды пришел запрос номер 3, увидел маркер '?', вернул stale.
4. Спустя 1 секунду маркер '?' устарел, несмотря на то, что запрос 1 всё еще ждет ответа.
5. Спустя еще 2 секунды пришел запрос номер 4, маркера нет, добавляет новый маркер и отправляется за курсом.
6. …
7. Запрос 1 получил ответ, сохранил результат.
8. Пришел запрос X, получил актуальный ответ из кэша 1-го вопроса (а когда пришел тот ответ? На момент запроса, или момент ответа? –, этого никто не знает…).
9. Запрос номер 4 получил ответ, сохранил результат — причем снова непонятно, был ли этот ответ более новый или более старый…

Разумеется, тут мы должны задать нужный нам таймаут через ini_set("default_socket_timeout") или воспользоваться stream_context_create… Так мы приходим к еще одному важному аспекту: кэш должен учитывать время получения значений. Общего решения для поведения нет, но, как правило, время кэширования должно быть больше чем время вычисления. В случае если время вычисления превышает время жизни кэша, кэш неприменим. Это уже не кэш, а предвычисления, которые следует хранить в надежном хранилище.

Итак, давайте подведём промежуточный итог. В бытовом понимании кэш:

1. заменяет большинство запросов на получение уже известного ответа;
2. ограничивает число запросов к получению дорогих данных;
3. делает время запросов невидимыми для пользователя.

В реальности же:

1. заменяет некоторые запросы из окна жизни кэша на запомненные значения (кэш может потеряться в любой момент, например, из-за нехватки памяти либо экстравагантных запросов);
2. пытается ограничить число запросов (но без специальной имплементации ограничения частоты исходящих запросов, реально можно обеспечить только характеристики типа «максимум 1 исходящий запрос в один момент времени»);
3. время исполнения запроса видимо только некоторым пользователям (причем распределены «счастливчики» отнюдь не равномерно).

Кэш предполагает «эфемерность» хранящихся данных, в связи с чем системы кэширования вольны обращаться со временем жизни вообще и с самим фактом запроса на сохранение данных:

• кэш может быть потерян в любой момент времени. Даже наши маркеры блокировки исполнения '?' могут быть потеряны, если параллельно еще 10 тысяч пользователей гуляет по сайту, все сохраняя что-то (зачастую время последнего обращения на сайт) в сессию, которая лежит на том же кэш-сервере; после того как маркер потерян («кэш отравлен»), следующий запрос опять начнёт процедуру обновления значения в кэше;
• чем быстрее исполняется запрос в удалённой системе, тем меньше запросов будет дедуплицировано в случае отравления кэша.

Таким образом, просто применяя кэш, мы зачастую закладываем мину отложенного действия, которая обязательно взорвется —, но не сейчас, а в будущем, когда решение обойдётся значительно дороже. Рассчитывая производительность системы, важно считать без учета сокращения времени исполнения от кэширования положительных ответов, иначе мы улучшаем поведение системы в спокойное время (когда сache hit ratio максимален), а не во время пиковой нагрузки / перегруженности зависимостей (когда обычно и случается отравления кэша).

Рассмотрим простейший случай:

• Мы смотрим на систему в спокойном состоянии, и видим среднее время исполнения 0.05 сек.
• Вывод: 1 процесс может обслужить 20 запросов в секунду, значит, для 100 запросов в секунду достаточно 5 процессов.
• Вот только если время обновления запроса возрастает до 2 секунд, то получается:
• 1 процесс занят обновлением (в течение 2 секунд);
• в течение этих 2 секунд у нас доступно только 4 процесса = 80 запросов в секунду.

И вот под большой нагрузкой наш кэш отравлен, и запросы кэшируются не на 5 секунд, а на 1 секунду только, а это означает, что у нас постоянно заняты 2 запроса (один исполняет первый запрос, второй начинает обновлять кэш через секунду, пока первый еще работает), и остаточная ёмкость для обслуживания сокращается до 60 запросов в секунду. То есть эффективная ёмкость от (исходя из среднего) 6000 запросов в минуту резко проседает до ~3600. Что означает, что если отравление наступило на 5000 запросах в минуту, до тех пор, пока нагрузка не упадёт с 5000 до 3000 система нестабильна. То есть любой (даже пиковый!) всплеск трафика потенциально может вызвать длительную нестабильность системы.

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

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