Mise en cache 2R2L

La mise en cache est un sujet bien connu et médiatisé. Mais de nouvelles solutions peuvent également y apparaître. En particulier - dans le domaine des produits de haut niveau (par exemple, dans le développement Web). Face aux lacunes de l'approche classique, j'ai essayé de dériver un schéma de mise en cache idéal pour le cas où la pertinence des données n'est pas critique. Ensuite, j'ai essayé de trouver une description d'un schéma similaire, ou mieux - des solutions toutes faites. N'ont pas trouvé. Par conséquent, je l'ai nommé moi-même - 2R2L (2 Range 2 Location) - mise en cache "spatiale" à deux plages. Bien qu'il soit probablement déjà utilisé quelque part.



Tout a commencé par une tâche simple: présenter de nouveaux produits à l'utilisateur, en tenant compte de ses préférences individuelles. Et s'il n'y avait aucun problème pour obtenir de nouveaux produits, la corrélation des nouveaux produits avec les préférences (analyse des statistiques) créait déjà une charge tangible (par exemple, définissons-la à 4 secondes). La particularité de la tâche était que des organisations entières pouvaient agir en tant qu'utilisateurs. Et il n'est pas rare que 200 à 300 requêtes concernant un utilisateur arrivent sur le serveur en même temps (dans les 2-3 secondes). Ceux. le même bloc est généré pour plusieurs utilisateurs à la fois.



La solution évidente est de le mettre en cache dans la RAM (nous n'exposerons pas le SGBD à la violence, le forçant à traiter un grand flux d'appels). Schéma classique:

1. La demande est venue
2. Vérification du cache. S'il contient des données et qu'elles ne sont pas obsolètes, nous les restituons simplement.
3. Pas de données => générer un problème
4. Nous envoyons à l'utilisateur
5. De plus, nous l'ajoutons au cache, indiquant le TTL

L'inconvénient de cette solution: s'il n'y a pas de données dans le cache, toutes les requêtes qui sont arrivées lors de la première génération vont les générer, dépensant des ressources serveur sur cela (pics de charge). Et bien sûr, tous les utilisateurs attendront au "premier appel".



Notez également qu'avec des valeurs de cache individuelles, le nombre d'entrées peut augmenter tellement que la RAM du serveur disponible n'est tout simplement pas suffisante. Ensuite, il semble logique d'utiliser un serveur HDD local comme stockage cache. Mais nous perdons immédiatement de la vitesse.



Comment être?



La première chose qui me vient à l'esprit: ce serait bien de stocker les enregistrements à 2 endroits - dans la RAM (fréquemment demandée) et le disque dur (tous ou rarement demandés). Le concept de «données chaudes et froides» dans sa forme la plus pure. Il existe de nombreuses implémentations de cette approche, nous ne nous attarderons donc pas dessus. Désignons simplement ce composant comme 2L. Dans mon cas, il est implémenté avec succès sur la base du SGBD Scylla.



Mais comment se débarrasser des tirages lorsque le cache est périmé? Et ici, nous incluons le concept de 2R, dont la signification est simple: pour un enregistrement de cache, vous devez spécifier non pas 1 valeur TTL, mais 2. TTL1 est un horodatage qui signifie "les données sont obsolètes, elles doivent être régénérées, mais vous pouvez toujours les utiliser"; TTL2 - "tout est tellement obsolète qu'il ne peut plus être utilisé."



Ainsi, nous obtenons un schéma de mise en cache légèrement différent:

1. La demande est venue
2. Nous recherchons des données dans le cache. Si les données sont là et ne sont pas obsolètes (t <TTL1) - nous les rendons à l'utilisateur, comme d'habitude et ne faisons rien d'autre.
3. Les données sont là, obsolètes, mais vous pouvez utiliser (TTL1 <t <TTL2) - donnez-les à l'utilisateur ET initialisez la procédure de mise à jour de l'enregistrement de cache
4. Il n'y a aucune donnée (tuée après l'expiration de TTL2) - nous la générons "comme d'habitude" et l'écrivons dans le cache.
5. Après avoir servi le contenu à l'utilisateur ou dans un flux parallèle, nous exécutons les procédures de mise à jour des enregistrements de cache.

En conséquence, nous avons:

• si les enregistrements de cache sont utilisés assez souvent, l'utilisateur ne se trouvera jamais dans la situation "d'attendre que le cache soit mis à jour" - il obtiendra toujours un résultat prêt à l'emploi.
• si la file des "mises à jour" est correctement organisée, alors il est possible de réaliser que dans le cas de plusieurs accès simultanés à un enregistrement avec TTL1 <t <TTL2, il n'y aura qu'une seule tâche de mise à jour dans la file, et non plusieurs identiques.

A titre d'exemple: pour un nouveau flux de produits, vous pouvez spécifier TTL1 = 1 heure (néanmoins, le nouveau contenu n'apparaît pas de manière très intensive), et TTL2 - 1 semaine.



Dans le cas le plus simple, le code PHP pour implémenter 2R pourrait être:

$tmp = cache_get($key);
If (!$tmp){
	$items = generate_items();
	cache_set($items, 60*60, 60*60*24*7);
}else{
	$items = $tmp[‘items’];
	If (time()-$tmp[‘tm’] > 60*60){
		$need_rebuild[] = [‘to’=>$key, ‘method’=>’generate_items’];
}
}
…
//   
echo json_encode($items);
…
//     ,   
If (isset($need_rebuild) && count($need_rebuild)>0){
	foreach($need_rebuild as $k=>$v){
		$tmp = ['tm'=>time(), 'items'=>$$v[‘method’]];
		cache_set($tmp, 60*60, 60*60*24*7);
}
}

Dans la pratique, bien entendu, la mise en œuvre sera probablement plus difficile. Par exemple, un générateur d'enregistrements de cache est un script distinct lancé en tant que service; file d'attente - via Rabbit, le signe "une telle clé est déjà dans la file d'attente pour la régénération" - via Redis ou Scylla.



Donc, si nous combinons l'approche «deux bandes» et le concept de données «chaudes / froides», nous obtenons 2R2L.



Merci!