分布式系统中的NWR
意义
NWR是一种在分布式存储系统中用于控制一致性级别的一种策略
定义
- N: 同一份数据的副本(replica)份数
- W: 写入一个数据时候要保证成功的份数
- R: 读取一个数据需要读取的副本份数
结论
1.W+R>N时，读写的副本中肯定存在交集，读操作的时候可以根据版本号或者修改时间来比较哪一份是最新数据，所以系统是强一致性的
2.W+R<=N时，是弱一致性的
3.(N,W,R)=(1,1,1)时为单机系统
4.(N,W,R)=(2,1,1)时为主从系统（例如redis主从），是弱一致性的；
5.N越大，可靠性越好；W或者N越大性能越差；经验上设置W和R都为N/2+1
6.(N,W,R)=(3,2,2)时为最小系统，任何时候保证写入两个成功副本即返回；读取时要最少读取两个副本；显然对于最小系统，任意一个节点出现问题后就会退化成(2,1,1)问题
故障方案
1.如果网络故障引起分区，可以让少数节点不提供服务，牺牲可用性来保证可用性；当节点恢复后同步副本日志到这些节点；
2.在要求最终一致性的场景，可以让少数节点分区只提供读取服务，不提供写入服务，待同步后再写入；
3.大多折中方案中是牺牲部分一致性来提高可用；
分片
如果说副本是提高可用性防止单点故障的方案，那么分片就是提高性能的方案；我们在mysql设计中对于大量数据进行分库、分表操作其实就是分片；redis集群的slots其实也是分片；通常利用一个哈希算法来确定（决策）数据写入（坐落于）哪个节点。显然分片可以可以提升单实例的性能，数据分布到不同节点上了，实现了负载均衡
集群
在前面的描述中，同一份数据产生N个副本，分布到N个节点上。
Redis的slots，Cassandra的patitions，MongoDB的shards，elastic的shared
我的理解是对于整个分布式系统节点数量M，每一份数目副本数为N,如果M:N=1:1即为上面描述的情况,在实际情况中效率较为低下;当N较大时存在效率低下，数据冗余过多的问题，所以实际中采用M>N的方案。
在elasticsearch中primary shared和replica shared不会分布到同一个节点上，防止单点故障，来保证高可用性，同时对于同一份数据不同的节点也可以提供负载均衡的作用。
NWR+分片方案=提高可用性，提高性能
参考出处
https://blog.csdn.net/lavorange/article/details/52489998