Dans l'article this, il est argumenté que utilise Memcache si vous récupérez fréquemment des entités aléatoires d'une base de données, et Squid si vous utilisez une architecture REST. S'il vous plaît expliquer pourquoi (en ce qui concerne Squid).Pourquoi le squid est-il bon pour les architectures REST?
REST est tout au sujet de http et des ressources. Squid peut être utilisé comme reverse proxy, de sorte qu'il prendra charge à partir du serveur web. le côté serveur peut définir some expires http header pour indiquer le timewindow pour la mise en cache.
Cela dit, la mise en cache est effectuée principalement sur les en-têtes http standard, donc son approche est plus proche de l'architecture des styles de repos que de la mise en cache des requêtes db.
Rest utilise les verbes http pour leurs actions correctes, c'est-à-dire que GET est toujours non destructif. Les URL sont également nommés de manière cohérente. Cela signifie que la mise en cache HTTP dans Squid peut être utilisée pour améliorer les performances sans dépendre de la technologie de programmation sous-jacente (ASP MVC, Rails, CouchDB, etc.)
Memcache est un magasin d'objets distribués - à vous de placer des objets dans et hors de cela. C'est un cache généraliste pour tout usage. Squid est un serveur proxy et un cache web.
Si tout se fait via une URL (par exemple, REST), Squid fera le travail gratuitement. Donc, en résumé, memcache est général, Squid est pour la mise en cache des résultats d'une URL.
Squid (étant un proxy & cache) peut effectivement être utilisé avec les points d'extrémité REST. Dans REST, les ressources sont censées être explicitement transférées avec les en-têtes ETAG/Last-Modified afin de faciliter la mise en cache.
En outre, de nombreuses opérations dans REST sont (supposées) être idempotent (répéter sans autres effets secondaires): c'est une situation parfaite pour Squid. Il peut agir seul sur ces opérations sans gênant le serveur d'applications.