Hacks de conception de système :

1. ) Écrire un système lourd — Référence-1 , Référence-2
2. ) Lire le système lourd — Référence-1 , Référence-2
3. ) Théorème CAP -

5. ) AP (Disponibilité avec tolérance de partition) — Cassandra, Dynamo, CouchDB, Riak, Elastic Search, MongoDB (répliqué).

6.) CA (cohérence avec la disponibilité) - MySQL, Postgres.

Notes courtes de référence :

MongoDB - MongoDB est fortement cohérent par défaut - si vous effectuez une écriture puis une lecture, en supposant que l'écriture a réussi, vous pourrez toujours lire le résultat de l'écriture que vous venez de lire. En effet, MongoDB est un système à maître unique et toutes les lectures vont au primaire par défaut. Si vous activez éventuellement la lecture à partir des secondaires, MongoDB devient finalement cohérent lorsqu'il est possible de lire des résultats obsolètes. MongoDB bénéficie également d'une haute disponibilité grâce au basculement automatique dans les jeux de réplicas :http://www.mongodb.org/display/DOCS/Replica+Sets

Garanties de cohérence Redis Cluster -

Redis Cluster ne garantit pas une cohérence forte. Concrètement, cela signifie que sous certaines conditions, il est possible que Redis Cluster perde des écritures reconnues par le système au client.

La première raison pour laquelle Redis Cluster peut perdre des écritures est qu'il utilise la réplication asynchrone. Cela signifie que pendant les écritures, ce qui suit se produit :

Votre client écrit au maître B.

Le maître B répond OK à votre client.

Le maître B propage l'écriture à ses répliques B1, B2 et B3.

Comme vous pouvez le voir, B n'attend pas un accusé de réception de B1, B2, B3 avant de répondre au client, car ce serait une pénalité de latence prohibitive pour Redis, donc si votre client écrit quelque chose, B accuse réception de l'écriture, mais plante avant étant capable d'envoyer l'écriture à ses répliques, l'une des répliques (qui n'a pas reçu l'écriture) peut être promue maître, perdant l'écriture pour toujours.

Dans Redis, la haute disponibilité ne se limite pas à la tolérance de partition. Redis a une architecture Master Slave et si un Master tombe en panne, Redis Sentinels promeut un Slave comme nouveau Master, ce qui rend l'ensemble de la solution hautement disponible. Et un maître peut échouer (ou devenir indisponible) pour un certain nombre de raisons (par exemple, manque de mémoire), ce n'est pas nécessairement dû à une partition réseau.

Vient ensuite le cas de la partition réseau (P), et si (P) se produit, alors Redis devient indisponible dans la partition minoritaire. C'est pourquoi, du point de vue CAP, Redis est CP car il devient indisponible dans les partitions minoritaires. Veuillez noter qu'il sera toujours disponible en partition majoritaire.

Vous pouvez en savoir plus sur la haute disponibilité de Redis ici . Reportez-vous au paragraphe intitulé « Cohérence sous les partitions » pour plus de détails sur le partitionnement.

Redis est également appelé cohérent à terme car lorsque (P) se produit, la partition minoritaire est toujours disponible pendant quelques secondes et toutes les écritures effectuées pendant cette période sur la partition minoritaire seront finalement supprimées.

Cassandre - cliquez ici