1. Один из традиционных тайников (404)
Этот метод заключается в том, чтобы направить ошибку 404 nginx на серверную часть, а затем использовать proxy_store для сохранения страницы, возвращенной серверной частью.
Конфигурация:
расположение/{
root /home/html/;#Домашний каталог
expires 1d;#Срок действия веб-страницы
error_page 404 =200 /fetch$request_uri;#404 направлен в каталог /fetch
}
location /fetch/ {#404Прямо сюда
Internal;#Указывает, что к этому каталогу нельзя получить прямой доступ извне
expires 1d;#Срок действия веб-страницы
alias /home/html/;#Адрес файловой системы виртуального каталога должен соответствовать местоположению/, proxy_store сохранит файл в этом каталоге
proxy_pass http://www.sudone.com/;#Верхний адрес восходящего потока, /fetch также является прокси
proxy_set_header Accept-Encoding '';# Пусть серверная часть не возвращает сжатый контент ( gzip или deflate). Сохранение сжатого контента вызовет проблемы.
proxy_store on;#Укажите nginx для сохранения файла, возвращаемого прокси
proxy_temp_path /home/tmp;#Временный каталог, этот каталог должен находиться в том же разделе жесткого диска, что и /home/html
}
При его использовании обратите внимание, что у nginx должно быть разрешение на запись файлов в /home/tmp и /home/html. В Linux nginx обычно настроен для работы от имени пользователя none, поэтому для этих двух каталогов необходимо указать none. это будет эксклюзивно для пользователя none, конечно, вы также можете использовать chmod 777, но все опытные системные администраторы советуют не использовать 777 случайно.
2. Традиционный кэш 2 (!-e)
Принцип в основном такой же, как и при прыжке 404, но более краткий:
расположение/{
корень /home/html/;
proxy_store включен;
proxy_set_header Accept-Encoding '';
proxy_temp_path /home/tmp;
если (!-f $request_filename)
{
proxy_pass http://www.sudone.com/;
}
}
Вы можете видеть, что эта конфигурация экономит много кода по сравнению с 404. Она использует !-f, чтобы определить, существует ли запрошенный файл в файловой системе. Если он не существует, передается proxy_pass на серверную часть, а возврат также сохраняется с помощью. proxy_store.
Оба традиционных кеша имеют в основном одинаковые преимущества и недостатки:
Недостаток 1: динамические ссылки с параметрами, такими как read.php?id=1, не поддерживаются. Поскольку nginx сохраняет только имя файла, эта ссылка сохраняется только как read.php в файловой системе, чтобы пользователи могли получить доступ к чтению. php?id= 2 вернет неправильные результаты. В то же время он не поддерживает домашнюю страницу в виде http://www.sudone.com/ и дополнительный каталог http://www.sudone.com/download/, потому что nginx очень честен и напишет такой запрос в файл по системе ссылок, а эта ссылка явно каталог, поэтому сохранение не получается. В этих случаях для правильного сохранения требуется перезапись.
Недостаток 2: внутри nginx нет механизма истечения срока действия и очистки кэша. Эти кэшированные файлы будут постоянно храниться на компьютере. Если нужно кэшировать много вещей, они заполнят все пространство жесткого диска. Для этой цели вы можете использовать сценарий оболочки для его регулярной очистки, а также написать динамические программы, такие как php, для выполнения обновлений в реальном времени.
Недостаток 3: можно кэшировать только 200 кодов состояния, поэтому коды состояния, такие как 301/302/404, возвращаемые серверной частью, не будут кэшироваться. Если псевдостатическая ссылка с большим количеством посещений будет удалена, она продолжится. проникать и вызывать. Задняя часть испытывает большое давление.
Недостаток 4: nginx не будет автоматически выбирать память или жесткий диск в качестве носителя информации. Конечно, в текущей операционной системе будет механизм кэширования файлов, поэтому в этом нет необходимости. слишком беспокойтесь о больших одновременных чтениях, если они хранятся на жестком диске, что вызывает проблемы с производительностью.
Недостатками традиционного кеша nginx также являются его особенности, отличающиеся от программного обеспечения для кэширования, такого как Squid, поэтому это также можно рассматривать как его преимущество. В производственных приложениях он часто используется в качестве партнера Squid. Squid часто не может блокировать ссылки с помощью ?, но nginx может блокировать их доступ, например: http://sudone.com/ и http://sudone? com/ будет рассматриваться как две ссылки в Squid, поэтому это приведет к двум проникновениям, тогда как nginx сохранит его только один раз, независимо от того, будет ли ссылка http://sudone.com/?1 или http://sudone.com/; ? 123, не может быть кэширован nginx, что эффективно защищает внутренний хост.
nginx очень точно сохраняет форму ссылки в файловой системе, так что для ссылки вы можете легко проверить состояние ее кэша и содержимое на кэш-машине, а также легко взаимодействовать с другими файловыми менеджерами, такими как rsync. полностью представляет собой структуру файловой системы.
Оба этих традиционных кеша могут сохранять файлы в /dev/shm в Linux. Обычно я делаю это для того, чтобы можно было использовать системную память для кэширования. Если память используется, содержимое с истекшим сроком действия будет очищено намного быстрее. При использовании /dev/shm/, помимо указания каталога tmp на раздел /dev/shm, если имеется большое количество небольших файлов и каталогов, необходимо также изменить количество индексных дескрипторов и максимальную емкость этой памяти. раздел:
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o перемонтировать /dev/shm
Приведенная выше команда используется на машине с памятью 3G. Поскольку максимальный объем памяти /dev/shm по умолчанию составляет половину системной памяти, то есть 1500 МБ, эта команда увеличит ее до 2500 МБ. системных индексных дескрипторов по умолчанию может быть недостаточно. Но интересно то, что их можно настроить по своему усмотрению. Корректировка здесь составляет 480000, что немного консервативно, но в принципе достаточно.
3. Кэш на основе mem- кеша d
В nginx есть некоторая поддержка memcached , но эта функция не особенно сильна, а производительность по-прежнему очень хороша.
местоположение /мем/ {
if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
установите $memcached_key «$1»;
memcached_pass 192.168.1.2:11211;
}
истекает 70;
}
Эта конфигурация укажет http://sudone.com/mem/abc на ключ abc memcached для получения данных.
В настоящее время в nginx нет механизма записи в memcached, поэтому запись данных в memcached должна выполняться с использованием динамического языка в фоновом режиме. Вы можете использовать 404 для направления на серверную часть для записи данных.
4. На основе стороннего плагина ncache
ncache — хороший проект, разработанный Sina Brothers. Он использует nginx и memcached для реализации некоторых функций, аналогичных кэшированию Squid. У меня нет опыта использования этого плагина.
http://code.google.com/p/ncache/
5. Недавно разработанная функция proxy_cache nginx.
Начиная с версии nginx-0.7.44, nginx поддерживает более формальную функцию кэширования, аналогичную Squid. Она все еще находится на стадии разработки, и поддержка этого кэша весьма ограничена, поэтому ссылка сохраняется после хеширования с кодировкой md5, поэтому она может поддерживаться. любая ссылка. В то же время поддерживаются и статусы Non-200, такие как 404/301/302.
Конфигурация:
Сначала настройте пространство кэша:
proxy_cache_path /путь/к/уровням кэша=1:2 key_zone=NAME:10m неактивно=5m max_size=2m clean_time=1m;
Обратите внимание, что эта конфигурация находится за пределами тега сервера. Уровни указывают, что пространство кэша имеет два уровня хеш-каталогов. Каталог первого уровня состоит из 1 буквы, а второй уровень — из 2 букв. Имя сохраненного файла будет похоже на /path/. to/cache /c/29/b7f54b2df7773722d382f4809d65029c;keys_zone дает этому пространству имя, 10m означает, что размер пространства составляет 10 МБ; значение inactive 5m означает, что время кэширования по умолчанию составляет 5 минут; значение max_size 2m означает, что один файл, превышающий 2m, не будет кэшироваться; clean_time указывает одну минуту. Очистите кэш один раз.
расположение/{
proxy_pass http://www.sudone.com/;
proxy_cache NAME;#Использовать NAME key_zone
proxy_cache_valid 200 302 1h; коды состояния #200 и 302 сохраняются в течение 1 часа
proxy_cache_valid 301 1d;код состояния #301 сохраняется в течение одного дня
proxy_cache_valid Any 1m;#Остальные сохраняются в течение одной минуты
}