Come posso implementare al meglio la cache fino a nuovo avviso con memcache in più livelli?

il termine "client" usato qui non si riferisce al browser del client, ma al server client

Prima del flusso di lavoro della cache

1. client make a HTTP request -->
2. server process -->
3. store parsed results into memcache for next use (cache indefinitely) -->
4. return results to client -->
5. client get the result, store into client's local memcache with TTL

Dopo il flusso di lavoro della cache

1. another client make a HTTP request -->
2. memcache found return memcache results to client -->
3. client get the result, store into client's local memcache with TTL

TTL = tempo di vivere

È possibile per me sapere quando sono stati aggiornati i dati,
e per scadere di conseguenza memcache (s).

Tuttavia, le insidie nella cache del sito client TTL

1. Qualsiasi aggiornamento dei dati prima che TTL non venga prelevato dal client memcache.
2. In ordine inverso, in cui non vi è alcun aggiornamento, i memcache del client scadono ancora dopo il TTL
3. Prima richiesta (o richieste simultanee) dopo la cache TTL riceve accelerazione in quanto è necessario ripetere "Prima del flusso di lavoro della cache"

Nel caso in cui il client richieda diverse richieste HTTP su una singola pagina web,
potrebbe essere molto cattivo nelle prestazioni.

La soluzione ideale dovrebbe essere il client per la cache indefinitamente fino a quando ulteriore avviso .

Ecco le tre proposte su ulteriore avviso

Proposta 1: utilizza l'intestazione HTTP (implementazione corrente)

1. client sent HTTP request last modified time header
2. server check if last data modified time=last cache time return status 304
3. client based on header to decide further processing

GOOD?
----
- save some parsing for client
- lesser data transfer

BAD?
----
- fire a HTTP request is still slow
- server end still need to process lots of requests

Proposta 2: emettere coerentemente una richiesta HTTP per controllare l'ultima volta modificata del gruppo di dati

1. client fire a HTTP request
2. server to return last modified time for all data group
3. client compare local last cache time with the result
4. if data group last cache time < server last modified time 
   then request again for that data group only

GOOD?
----
- only fetch what is no up-to-date
- less requests for server

BAD?
----
- every web page require a HTTP request

Proposta 3: comunica al cliente quando sono disponibili nuovi dati (Push)

 1. when server end notice there is a change on a data group
 2. notify clients on the changes
 3. help clients to fetch again data
 4. then reset client local memcache after data is parsed

GOOD?
----
- let the cache act/behave like a true cache

BAD?
----
- encourage race condition

La mia preferenza è sulla proposta 3,
e qualcosa come Gearman potrebbe essere l'ideale Dove c'è una modifica, il server Gearman ha inviato l'attività a più client (lavoratori).

Sono pazzo?
(Conosco il mio la prima domanda è un po 'folle)