Hacks de design do sistema:

1. ) Write Heavy system — Reference-1 , Reference-2
2. ) Ler sistema pesado — Referência-1 , Referência-2
3. ) Teorema CAP -

5.) AP (disponibilidade com tolerância de partição) — Cassandra, Dynamo, CouchDB, Riak, Elastic Search, MongoDB (replicado).

6.) CA (Consistência com Disponibilidade) - MySQL, Postgres.

Notas curtas de referência:

MongoDB - MongoDB é fortemente consistente por padrão — se você fizer uma gravação e depois uma leitura, assumindo que a gravação foi bem-sucedida, você sempre poderá ler o resultado da gravação que acabou de ler. Isso ocorre porque o MongoDB é um sistema mestre único e todas as leituras vão para o primário por padrão. Se você opcionalmente habilitar a leitura dos secundários, o MongoDB se tornará eventualmente consistente, onde é possível ler resultados desatualizados. O MongoDB também obtém alta disponibilidade por meio de failover automático em conjuntos de réplicas:http://www.mongodb.org/display/DOCS/Replica+Sets

Garantias de consistência do Redis Cluster -

Redis Cluster não garante consistência forte. Em termos práticos, isso significa que, sob certas condições, é possível que o Redis Cluster perca as gravações que foram confirmadas pelo sistema para o cliente.

A primeira razão pela qual o Redis Cluster pode perder gravações é porque ele usa replicação assíncrona. Isso significa que durante as gravações acontece o seguinte:

Seu cliente escreve para o mestre B.

O mestre B responde OK ao seu cliente.

O mestre B propaga a escrita para suas réplicas B1, B2 e B3.

Como você pode ver, B não espera uma confirmação de B1, B2, B3 antes de responder ao cliente, pois isso seria uma penalidade de latência proibitiva para o Redis, portanto, se seu cliente escrever algo, B reconhece a gravação, mas trava antes podendo enviar a escrita para suas réplicas, uma das réplicas (que não recebeu a escrita) pode ser promovida a master, perdendo a escrita para sempre.

No Redis, Alta Disponibilidade é mais do que Tolerância à Partição. O Redis possui arquitetura Master Slave e, se um Master falhar, os Redis Sentinels promovem um Slave para ser o novo Master, tornando toda a solução altamente disponível. E um mestre pode falhar (ou ficar indisponível) por vários motivos (por exemplo, falta de memória), não necessariamente devido a uma partição de rede.

Em seguida, vem o caso da partição de rede (P), e se (P) acontecer, o Redis ficará indisponível na partição minoritária. É por isso que, da perspectiva do CAP, o Redis é CP porque fica indisponível em partições minoritárias. Observe que ainda estará disponível na partição majoritária.

Você pode ler mais sobre o Redis High Availability aqui . Consulte o parágrafo intitulado “Consistência sob partições” para obter detalhes sobre o particionamento.

O Redis também é chamado de eventualmente consistente porque quando (P) acontece, a partição minoritária ainda está disponível por alguns segundos e qualquer gravação feita durante esse período na partição minoritária será eventualmente descartada.

Cassandra - clique aqui