2016-11-22 6 views
1

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

Выполнение завитка дает ответ с двумя тайниками и разным возрастом.

Есть ли какие-либо факторы, такие как нагрузка или что-то еще для поведения липкости? Использовал Jmeter и тест apache с нагрузкой, но все же получил такое же поведение.

Является ли мой vcl_hash хорошим? Хотите сохранить объект с хэш-комбинацией url и ip бэкэнд-сервера.

По крайней мере, в моем случае, после ttl объекта кэша, лак кэшируется со второго сервера и возвращает его до тех пор, пока ttl не будет выполнен. Но это не то, что мы ожидаем от этого?

Я ничего не пропустил?

с использованием круглых robin и hash_data. Ниже мой config.vcl

backend s1{ 
    .host = "190.120.90.1"; 
} 

backend s2{ 
    .host = "190.120.90.2"; 
} 

sub vcl_init { 
    new vms = directors.round_robin(); 
    vms.add_backend(s1); 
    vms.add_backend(s2); 
} 

sub vcl_recv { 
    set req.backend_hint = vms.backend(); 
} 

sub vcl_hash { 
    hash_data(req.url); 
    if (req.http.host) { 
     hash_data(req.http.host); 
    } else { 
     hash_data(server.ip); 
    } 
    return(lookup); 
} 

ответ

3

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

Второй - это круговой поворот. Это происходит только тогда, когда Varnish извлекает объекты, поэтому это не произойдет, когда объект уже был кеширован.

Чтобы ответить на ваш вопрос точно, необходимо знать, почему ваше приложение предоставляет различный контент для одного и того же запроса. Как вы указываете, какой сервер запрашивается, если запрос всегда один и тот же? Должно быть что-то вроде файла cookie, заголовка или источника IP запроса, который должен диктовать тот, который должен ответить на этот запрос.

Зная, что можно установить конкретный сервер и использовать его в vcl_hash. Для целей примера, давайте предположим, что вы хотите установить свои движки на основе наличия заголовка с именем backend_choice:

sub vcl_recv { 
    if (req.http.backends_choice == "s1") { 
    set req.backend_hint = s1; 
    # If the header is not "s1" or does not exist 
    } else { 
    set req.backend_hint = s2; 
    } 
    ... 
} 

sub vcl_hash { 
    hash_data(req.url); 
    if (req.http.host) { 
    hash_data(req.http.host); 
    } else { 
    hash_data(server.ip); 
    } 
    # We use the selected backend to hash the object 
    hash_data(req.backend_hint); 
    return(lookup); 
} 

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

+0

Perfect..I думал неправильно. Ваш ответ должен работать на меня ... по другому контенту, ответ кэшируется и доставляет кэшированный объект и в среднем, если пользователь обновляет свой контент в социальной сети, кешированный объект должен быть invalidated и вернуть новые res (мне нужно подумать об архитектуре, которая, как мне кажется) – user1609085

+1

Я бы рекомендовал вам реализовать Purge в вашей конфигурации Varnish и использовать ее всякий раз, когда вам нужно сделать недействительным объект. Вот ссылка на него: http://book.varnish-software.com/4.0/chapters/Cache_Invalidation.html#http-purge – alejdg