Redondance des données dans le stockage distribué

Ce travail est concédé sous le contrat de licence international Creative Commons Attribution - Utilisation non commerciale - Partage 4.0 de la même manière .
Cette oeuvre ( Lizhao Long Bowen par Li Zhaolong création) par Li Zhaolong confirmation, veuillez indiquer le copyright.

introduction

Le même problème est compris différemment à différents stades de l'apprentissage. Au départ, il n'y avait pas assez de compréhension de ce domaine. L'angle de vue du problème est non seulement faible, mais aussi unique, ce qui permettra de regarder facilement le problème selon une certaine solution, comme celle-ci " simple "problème, c'est-à- 数据冗余dire au tout début À ce moment-là, ce problème est le même à mes yeux 一致性协议, car nous pouvons faire de la redondance des données basée sur le protocole de cohérence. Bien sûr, le plus important est qu'il s'agit d'une forte cohérence, mais il est bien connu que c'est une forte cohérence (forte cohérence du point de vue du serveur, bien sûr, nous ignorons le retard du réseau tous les jours) est extrêmement affectant les performances, donc la plupart du temps nous ne le ferons pas. Nous pouvons reculer et choisir d'autres modèles de cohérence. Cela entraînera des changements dans la stratégie de redondance des données. Ceci est le mien. Je n'ai pas remarqué dans [1] cet article. J'étais occupé à réfléchir à la cohérence et j'ai complètement oublié que le comportement consistant à montrer la cohérence est en fait la redondance des données.

Deuxièmement, cet article n'est pas une définition très générale comme [2], mais pour décrire plusieurs stratégies de redondance utilisées dans la vie réelle, en déduire la cohérence et faire correspondre les concepts de [2].

La plupart des informations contenues dans l'article proviennent des journaux de grandes entreprises, et il n'y a pas de problème en termes d'exactitude.

Dans cet article, nous ne mentionnons que la stratégie de redondance des données, sans rien mentionner d'autre.

Accord de conformité

Le protocole de consensus fort est peut-être le premier obstacle que la plupart des amis qui étudient la théorie distribuée ont rencontré depuis leur entrée dans l'industrie. Ils ont d'abord été abusés par Raft (multi), puis ravagés par Paxos, et ont finalement découvert qu'il existe des émissions atomiques comme ZAB. protocole. En plus du problème des généraux byzantins, il existe d'innombrables algorithmes utilisés pour Bitcoin tels que PBFT, Pow, PoS et DPoS; sans la limitation de la cohérence forte, il existe également des protocoles de consensus très faibles tels que Gossip (généralement utilisé Maintenir l'appartenance au cluster) ; la restriction est plus faible et il existe des protocoles de réplication tels que la réplication ViewStamped. Bien sûr, je ne sais pas grand-chose à ce sujet. Les amis intéressés peuvent le vérifier [5].

La maintenance de la redondance des données basée sur le protocole de cohérence ne veut pas dire, c'est essentiellement le processus de synchronisation des logs entre les nœuds.

ceph

La distribution des événements dans ceph se fait via des CRUSHalgorithmes, c'est-à-dire que nous pouvons en calculer un en l' obtenant du mastercluster , à travers lequel nous pouvons obtenir un ensemble d'informations, puis nous pouvons obtenir leurs informations de stockage réelles via la carte.inodepgidpgidOSD

OSDLe premier nœud de la liste est Primary, et les autres sont tous Replica. Le client termine toutes les écritures sur l'objet PG sur l'OSD principal (hôte principal). Ces objets et PG reçoivent un nouveau numéro de version, puis sont écrits dans l'OSD de réplique. Lorsque chaque copie est terminée et répond au nœud maître, le master Le nœud est mis à jour et le client a fini d'écrire. Voici une validation en deux phases. Lorsque les copies sont écrites dans la mémoire Ack, le nœud maître peut répondre lorsque tous les accusés de réception sont reçus. Lorsque les copies sont soumises au disque, il répond Commit. Le nœud maître répondra également lorsque tous les commits sont reçus, donnez Clientune réponse, ce qui réduit considérablement la vitesse de réponse du client.

Le client lit directement sur le nœud maître. Cette méthode évite la synchronisation et la sérialisation compliquées entre les répliques du client. La configuration W visible de cette méthode est tous les nœuds, ce qui signifie que la cohérence de la copie peut être maintenue de manière fiable pendant la récupération d'erreur. Bien sûr, si l'un Replicaéchoue, l'opération échouera, car il n'y a aucun moyen de recevoir toutes les réponses.

Le document ne mentionne pas ce qu'il faut faire pour le moment. Je pense qu'à ce moment (après l'expiration du délai), l'OSD peut être recalculé, puis répliqué à nouveau. Lorsque l'OSD est restauré, il sera ajouté au partenariat d'origine, et il sera également basé sur le journal des modifications récentes de PG.Pour synchroniser les journaux, cela garantit la cohérence.

GFS

La redondance des données de GFS provient de deux aspects, l'un est Masterla copie d'état du nœud et l'autre est ChunkServerla copie des données. Cela implique un autre problème, à savoir la sélection du maître. Le premier utilise Chubby pour choisir de manière fiable le maître (acquisition d'un verrou), et le second détermine le nœud maître en Masterémettant leases. Nous voyons qu'aucune des méthodes n'utilise un protocole de consensus. Cependant, le nœud maître peut être désigné de manière unique.

En fait, il mastern'y a pas beaucoup de description de l'implémentation dans le document redondant, mais il est mentionné que tous les journaux d'opérations et les fichiers de point de contrôle du serveur maître sont copiés sur plusieurs machines. En outre, la condition préalable à la soumission réussie de l'opération de modification à l'état du serveur maître est que le journal des opérations soit écrit sur le nœud de secours du serveur maître et sur le disque local. De cette manière, une fois que la sélection du maître via Chubby est réussie lorsque le serveur maître est en panne, la copie de ces données très complètes peut être rapidement basculée vers l'état de fonctionnement normal, car elle contient toutes les données du nœud maître d'origine et a été placé sur le disque.

En plus de la première fois, il existe un autre type de serveur dans GFS appelé serveurs shadow . Ces serveurs shadow fournissent un accès en lecture seule au système de fichiers lorsque le serveur maître "maître" est arrêté. Ce sont des ombres, pas des miroirs, de sorte que leurs données peuvent être mises à jour plus lentement que le serveur maître "maître", généralement moins d'une seconde. Une telle opération met le maître "maître" hors ligne, mais le service ne se déconnecte pas dans son ensemble, car l'ombre peut également fournir un accès aux données d'origine. Pour les fichiers qui ne changent pas fréquemment ou les applications qui autorisent une petite quantité de données obsolètes, le serveur miroir peut améliorer l'efficacité de la lecture et améliorer la disponibilité de l'ensemble du système .

Pourquoi les données génériques de l'ombre sont-elles plus lentes? Parce que les informations de Chunk sont conservées par l'ombre elle-même et la communication Chunk, mais la création et la modification de la copie ne peuvent être effectuées que par le maître, si la modification consiste à notifier d'abord l'ombre, puis à mettre à jour après réception de la réponse peut provoquer l'ombre les données doivent être plus récentes que le maître, Ceci est intolérable, donc l'ombre dans GFS choisit de lire une copie du journal de l'opération en cours et modifie la structure de données interne exactement dans le même ordre que le serveur maître principal, assurant la cohérence à un moment donné, mais bien sûr, il y aura une heure de synchronisation, ce qui fait que les données sont légèrement plus anciennes.

Ensuite, nous parlons de ChunkServerredondance des données, ce qui suit est le processus de mise à jour:

chaque fois que je vois cette image, je veux dire que la séparation du flux de contrôle et du flux de données ne peut être considérée que intelligente. .

GFS utilise un mécanisme de bail pour maintenir la cohérence de l'ordre des modifications entre plusieurs répliques. Le nœud maître établit un bail pour une copie de Chunk, qui est appelée Chunk maître. Le Chunk principal sérialise toutes les opérations de modification du Chunk, et toutes les copies suivent cette séquence pour les opérations de modification.

On peut voir dans la section 3.1 de l'article que la copie des données est un processus fortement cohérent, car toutes les erreurs générées par une copie seront renvoyées au client. Premièrement, les données doivent être exécutées avec succès dans le bloc principal, sinon il ne sera pas une séquence d’opérations., Donc, si une Replicaséquence d’opérations d’exécution échoue, ce message sera transmis au bloc principal. À ce stade, la demande du client est considérée comme un échec et les données sont dans un état incohérent à cette fois, et le client gère cela en répétant l'opération qui a échoué.

Quant à savoir pourquoi les baux sont utilisés pour assurer la cohérence entre les copies multiples et les baux sont utilisés, l'explication donnée dans le document est la suivante: le but de la conception du mécanisme de bail est de minimiser la charge de gestion du nœud maître . Ce n'est en fait pas facile à comprendre. Mon idée est la suivante. Il faut dire que c'est pour une gestion plus efficace des morceaux . Étant donné que la gestion des blocs est un processus dynamique aux yeux de GFS, la gestion des blocs par le maître comprend, mais sans s'y limiter, les points suivants:

1. Le maître vérifie la distribution actuelle des copies, puis déplace les copies pour mieux utiliser l'espace du disque dur et équilibrer la charge plus efficacement
2. La sélection d'un nouveau Chunk est similaire à celle lors de sa création: équilibrer l'utilisation du disque dur, limiter le nombre d'opérations de clonage en cours sur le même serveur Chunk et répartir les copies entre les racks
3. Lorsque le nombre de copies effectives de Chunk est inférieur au facteur de réplication spécifié par l'utilisateur, le nœud maître le répliquera à nouveau

Si chaque Chunk est configuré en tant que Paxos/Raftgroupe, la migration (pour l'utilisation du disque dur) sera très gênante [9], et la surcharge du Chunk deviendra également relativement importante, car la surcharge du protocole de cohérence forte lui-même est très grand.

Bien sûr, ce ne sont que mes pensées personnelles.

Dynamo

Ce que Dynamo décrit est en fait la partie de nœud sans propriétaire dans [2], parce que [2] cet article est un article que j'ai écrit après avoir lu DDIA, et maintenant il semble que le contenu de cette section dans DDIA soit en fait lié à [10] Écrit dans ce papier.

Dynamo utilise un hachage cohérent optimisé pour la distribution des données. De toute évidence, il existe deux méthodes les plus intuitives pour la redondance des données. Chaque nœud est compté comme maître et esclave (le type de chaîne est également possible), ou pour une disponibilité extrême comme Dynamo L'introduction d'écritures de nœuds sans propriétaire.

En plus de stocker localement chaque clé de sa plage, Dynamo copie également ces clés sur les N-1 nœuds successeurs dans le sens des aiguilles d'une montre sur l'anneau. Prenons l'exemple ci-dessus. Si une clé est insérée dans l'intervalle [A, B), le nœud BCD stockera cette clé. En d'autres termes, le nœud D stockera la clé dans la plage (A, B], (B, C) et (Toutes les touches en C, D].

Une liste de nœuds responsables du stockage d'une clé spécifique est appelée une liste de préférences, et tout nœud de stockage dans Dynamo est éligible pour recevoir toutes les opérations de lecture et d'écriture sur la clé du client, ce qui signifie qu'elle peut apparaître ici. Nœud multi-maître écrivez. Afin d'assurer la cohérence, dans la configuration générale W+R > N, nous appelons le nœud qui traite les opérations de lecture ou d'écriture comme coordinateur. Le processus de lecture et d'écriture est le suivant:

1. Lors de la réception d'une demande d'écriture, le coordinateur génère une nouvelle version de l'horloge vectorielle et écrit la nouvelle version localement. Le coordinateur envoie ensuite la nouvelle version (avec la nouvelle horloge vectorielle) aux N nœuds joignables supérieurs dans la liste préférée. Si au moins les nœuds W-1 renvoient une réponse, l'opération d'écriture est considérée comme réussie.

2. Lors de la réception d'une demande de lecture, le coordinateur demande toutes les versions existantes des données des N nœuds joignables supérieurs dans la liste préférée pour la clé, puis attend les réponses R, puis renvoie les résultats au client. Si le coordinateur final collecte plusieurs versions des données, il renvoie toutes les versions qui, selon lui, ne sont pas causales. Différentes versions seront coordonnées, remplaceront la version actuelle, et enfin réécrites.

Les amis qui ne connaissent pas les horloges vectorielles peuvent vérifier les informations.

Il y a un autre problème ici, à savoir comment synchroniser les valeurs directes de plusieurs nœuds, car l'écriture est multi-nœuds, nous ne savons pas quelles clés d'autres nœuds ont différentes de nous, devons-nous envoyer tous les chaque fois que nous synchronisons Key? Bien sûr, ce n'est pas nécessaire. Dynamo utilise pour MerkleTreeréaliser la synchronisation entre les réplicas. Voici un inconvénient du hachage cohérent avec les nœuds virtuels. Cela entraînera de nombreux MerkleTreeéchecs lorsque le nœud maître est nouvellement ajouté , et il est difficile de récupérer. l'arbre peut être reconstruit à partir des données existantes, car il key rangeest détruit, comment optimiser cet article ne sera pas abordé.

La façon dont Dynamo atteint une utilisabilité extrême grâce à de telles écritures de nœuds sans propriétaire ne sera pas abordée dans cet article.

redis

Le schéma de redondance des données de Redis est la réplication maître-esclave, et le schéma de haute disponibilité est Sentinelque la sentinelle agit comme un nœud d'élection. Lorsqu'il est utilisé Redis Cluster, slotle nœud maître qui en a au moins un sert de nœud de vote pour l'élection et le nœud esclave est le nœud d'élection. Une fois l'élection du nœud esclave réussie, elle sera exécutée slave no oneet l'attribution des emplacements du nœud maître d'origine sera révoqué afin que ces emplacements pointent vers lui-même. Diffusé après l'hôte PONG, ce paquet Gossip est utilisé pour notifier la fin du basculement.

En raison du problème de l'implémentation Redis, en fait, la réplication maître-esclave n'a pas du tout la moindre cohérence, car l'esclave sera mis à jour après la réussite de la mise à jour du maître, et le processus de mise à jour est asynchrone, et il n'y a pas de Quorumconcept . Les données à envoyer sont d'abord stockées dans la redisClientstructure. Dans le tampon de réponse buf, la synchronisation ne sera effectuée qu'après réception d'un événement inscriptible de ce client, et c'est au moins la prochaine boucle d'événements.

Cela signifie qu'il n'y a pas de cohérence dans la redondance des données Redis. Utiliser Redis comme verrou distribué est théoriquement insensé. Bien sûr, théoriquement. Après tout, le nœud maître est en panne et les données de base ne sont pas synchronisées avec le serveur esclave. la probabilité est trop faible, mais une fois que la base est grande, tout peut arriver.

Le Redis Clusterschéma de redondance des données en Chine est toujours la réplication maître-esclave. Le processus de synchronisation de base est le même que ci-dessus, mais la détection des échecs, le processus de basculement sont différents et le rôle de lancement de l'élection est également différent. Cet article ne le fait pas discuter.

grand conte

Redondance des données Bigtable pour nous donner une nouvelle idée, à savoir l'aide d'autres composants pour la redondance des données, Bigtablel'utilisation de GFSvenir à droite Tabletet Redo Pointla redondance des données.

Je pense que c'est la méthode la plus courante, c'est-à-dire d'utiliser un composant de stockage distribué mature comme système de fichiers réseau, ce qui peut donner à l'application supérieure une abstraction simple et puissante. Bien sûr, il y a une chose à être claire dans votre esprit Ce n'est pas un cache distribué, ce qui signifie qu'il est très courant de fonctionner pendant plusieurs centaines de millisecondes à la fois, il est donc nécessaire d'utiliser la localité espace / temps pour mettre en cache ces données en mode utilisateur, et il est également nécessaire lors de l'écriture buffer. Autrement dit, dans la figure memtable, il est vrai que cela peut entraîner une perte de données. Après tout, les données ne sont pas stockées sur le disque. Ici, vous pouvez implémenter un fichier de journalisation Redo pointpour en restaurer un memtable.

Pour la soumission des journaux, bigtable a fait une optimisation, voir la section [11] commit log.

Comme une opération GFS est très coûteuse, le mode utilisateur nécessite une grande quantité de cache (cache), BigTable utilise deux niveaux de cache, le cache d'analyse est le premier niveau de cache, le cache principal est la paire clé-valeur obtenue par le Serveur de tablette via l'interface SSTable; Bloc; Le cache est le cache de deuxième niveau et le cache est le bloc du SSTable lu à partir de GFS. Pour les applications qui lisent souvent les mêmes données à plusieurs reprises, l'analyse du cache est très efficace.

Memcache

Le plus haut niveau de redondance des données est qu'il n'y a pas besoin de redondance des données!

Comment une mémoire cache pleine a-t-elle la redondance des données? Vous parlez de redondance. Même les informations de routage sont stockées dans le client, bien sûr, si c'est pour la sécurité des données, bien sûr, il n'y a pas besoin de redondance des données. Mais il peut y avoir redondance en raison de l'efficacité .

Mais évidemment, lorsqu'un nouveau cluster est ajouté, le taux de réussite du cache sera très faible à ce moment, ce qui affaiblira la capacité d'isoler les services back-end. Cela peut être considéré comme une avalanche de cache spéciale. À ce stade, l'équipe de Facebook l'approche [12] est le préchauffage à froid du cluster , c'est -à- dire que nous pouvons laisser le client de ce nouveau cluster récupérer les données du client du cluster en cours d'exécution depuis longtemps, de sorte que le temps nécessaire à ce cluster froid atteigne sa pleine la charge sera considérablement raccourcie.

Voici l'architecture de l'équipe Facebook utilisant le cluster Memcache: Je

viens de dire qu'il n'y a pas besoin de redondance, pourquoi cela s'est-il reproduit? Comme mentionné précédemment, pour être efficace, l'équipe Facebook a non seulement réalisé regionune redondance des données entre les deux, mais également regionune redondance interne des données.

Il est décrit dans [12] 5 comme suit:

• Nous désignons une région pour contenir les bases de données principales et les autres régions pour contenir des répliques en lecture seule; nous nous appuyons sur le mécanisme de réplication de MySQL pour maintenir les bases de données répliques à jour avec leurs maîtres.
• Nous désignons une région pour contenir la base de données principale, et d'autres régions contiennent des répliques en lecture seule; nous nous appuyons sur le mécanisme de réplication de MySQL pour maintenir la base de données de répliques synchronisée avec la base de données principale.

Dans ce cas, vous pouvez profiter des avantages d'un centre de données multiples et effectuer l'opération de lecture dans la région, que le délai memcacheou le Storage Clusterdélai soit très faible.

Dans le deuxième regionexemplaire, il y a la description suivante dans [12]:

Nous utilisons la réplication pour améliorer la latence et l'efficacité du serveur Memcached.

Évidemment, lorsque le volume de requêtes d'une certaine clé dépasse la charge de la machine unique, nous devons faire quelques optimisations, sinon il peut y avoir des 缓存击穿problèmes. De manière générale, il existe actuellement deux méthodes:

1. Division basée sur la clé primaire (basée sur le hachage ou les caractéristiques des données).
2. Copie complète (opération de lecture optimisée)

Ce dernier est une redondance de données. Alors, comment choisir les deux options ci-dessus? Je pense qu'il y a deux facteurs:

1. La taille de la collection de raccourcis clavier
2. La différence de coût entre la demande de plusieurs clés et la demande de clés uniques

La première est facile à comprendre, comment avoir une seule touche de raccourci et comment la diviser est inutile. À l'heure actuelle, la réplication complète est la voie royale. Je pense que c'est aussi la raison pour laquelle Alibaba Cloud Tair [13] a choisi le solution multi-copie pour éviter les hotspots. Chaque fois que je mentionne Tair, je dois dire quelque chose, je suis tellement heureuse! Heureux Dieu Dieu éternel! !

Mais lorsque les points chauds sont relativement uniformes et qu'il n'y a pas de super raccourci clavier, la fragmentation des données est évidemment une très bonne méthode.

Le coût de clé unique et multi-clé est le problème décrit dans [12]:

• Prenons l'exemple d'un serveur Memcached contenant 100 éléments et capable de répondre à 500 000 requêtes par seconde. Chaque demande demande 100 clés. La différence de surcharge de Memcached pour la récupération de 100 clés par demande au lieu d'une clé est faible. Pour mettre à l'échelle le système pour traiter 1M de requêtes / s, supposons que nous ajoutions un deuxième serveur et que nous partagions l'espace clé de manière égale entre les deux. Les clients doivent maintenant diviser chaque demande de 100 clés en deux demandes parallèles de 50 clés. Par conséquent, les deux serveurs doivent encore traiter 1M de requêtes par seconde. Cependant, si nous répliquons les 100 clés sur plusieurs serveurs, la demande d'un client pour 100 clés peut être envoyée à n'importe quelle réplique. Cela réduit la charge par serveur à 500 000 requêtes par seconde
• Prenons l'exemple d'un serveur Memcached avec 100 éléments de données, capable de traiter 500 000 requêtes par seconde. Trouvez 100 clés primaires pour chaque demande. Dans Memcached, la différence de coût entre l'interrogation de 100 clés primaires pour chaque demande et l'interrogation d'une clé primaire est très faible . Afin d'étendre le système pour gérer 1M de requêtes / s, supposons que nous ajoutions un deuxième serveur et distribuions uniformément la clé primaire aux deux serveurs. Le client doit maintenant diviser chaque requête contenant 100 clés primaires en deux requêtes parallèles contenant 50 clés primaires. En conséquence, les deux serveurs doivent encore gérer 1M de requêtes par seconde. Ensuite, si nous répliquons les 100 clés primaires sur deux serveurs, une demande client contenant 100 clés primaires peut être envoyée à n'importe quel réplica. Cela réduit la charge sur chaque serveur à 500 000 requêtes par seconde.

CRAQ

Ce dont j'ai déjà parlé, c'est de savoir comment certains logiciels industriels utilisent le mécanisme de redondance des données, mais peu importe comment cela change, il ne peut fondamentalement pas échapper au sort de la réplication maître-esclave (sauf pour aucun maître), mais la stratégie de mise en œuvre est différente en raison de la différence Peu importe, y a-t-il uniquement une charge maître-esclave pour la redondance des données?

Bien sûr que non, la réplication de chaîne est également un excellent choix, sans parler du CRAQ optimisé de la réplication de chaîne.

Jetons un coup d'œil aux résultats de la comparaison des performances dans [14]:

Étant donné que le stockage en chaîne lit et écrit à deux nœuds, ces deux opérations peuvent être simultanées tout en garantissant une forte cohérence, et si le maître et l'esclave veulent assurer une forte cohérence, les lectures et les écritures doivent passer par le nœud maître, comme zk De cette façon , la cohérence FIFO du point de vue du client n'est pas prise en compte. Par conséquent, les performances du stockage en chaîne sont supérieures à celles des opérations d'écriture dans la plage de 0% à 25% pour les opérations de mise à jour. Et même si le stockage en chaîne ne garantit pas une forte cohérence, il garantit naturellement le FIFO du point de vue du client, et n'a pas besoin d'en maintenir un comme zk zxid.

Le CRAQ optimisé du stockage en chaîne peut considérablement améliorer le débit de lecture tout en garantissant une forte cohérence. Et pour un débit d'écriture plus élevé, CRAQ permet également de réduire les exigences de cohérence, c'est-à-dire la cohérence finale. Cela signifie que les anciennes données peuvent être renvoyées dans un laps de temps (c'est-à-dire avant que l'écriture ne soit appliquée à tous les nœuds).

Mentionnez-le simplement sans entrer dans les détails, veuillez vous référer à [14] [15] pour plus de détails.

Pour résumer

Plus tard, je prévois d'écrire un autre article sur la distribution d'événements dans le stockage distribué, qui est également une question très intéressante.

Après avoir résumé ces derniers, j'ai tout de suite l'impression que mon esprit est plus clair. Je pense qu'il y a très peu d'articles sur Internet plus détaillés mais simples pour décrire ce contenu. Cela peut être considéré comme une petite contribution aux débutants dans ce domaine.

Étant donné que le résumé du contenu comme celui-ci est un long processus de première ligne et qu'il s'agit d'une recrue de printemps rapide récemment, cet article ne peut être rédigé qu'après avoir examiné les connaissances relatives à la distribution, donc cet article n'est pas encore terminé et j'en apprendrai de nouvelles. des choses plus tard, j'ajouterai encore des choses.

Le niveau de l'auteur est limité et Haihan est invité à corriger les erreurs.

référence:

1. " Parlez d'un peu de compréhension de la cohérence distribuée "
2. " Réplication des données entre les nœuds "
3. " Algorithme de consensus "
4. " Présentation et dérivation de l'algorithme Paxos "
5. 《La réplication ViewStamped revisitée 解读》
6. Ceph: un système de fichiers distribués évolutif et hautes performances
7. Système de fichiers Google
8. Le service Chubby Lock pour les systèmes distribués faiblement couplés
9. " Algorithme de radeau: problème de changement de membre de cluster "
10. Dynamo: le magasin de valeurs-clés hautement disponible d'Amazon
11. Bigtable: un système de stockage distribué pour les données structurées
12. Mise à l'échelle de Memcache sur Facebook
13. « Mécanisme de hachage de données à chaud de Tair, le service de cache distribué de la technologie Double 11 2017 »
14. Réplication en chaîne pour prendre en charge un débit et une disponibilité élevés
15. Stockage d'objets sur CRAQ