CAP-常见系统分析

一致性

说明

分布式系统，同步存在延迟，各节点的数据一定是不一样的
读一致性：两次读取数据一致
写一致性/读写一致性：写成功本身可以看成一个读操作，写完能看到，类似于两次读取结果一致
多客户端，多节点将整个问题复杂化了
客户端视角的读一致性：单个客户端两次读取(可能不同节点)一致，全局视角的读一致性：不同客户端同时两次读取一致
客户端视角的写一致性：单个客户端写完自己能读，全局视角的写一致性：某客户端写完所有客户端都能读取到

kafka

acks=-1(all)+同步发送 保证全局写一致，只能看到同步过的数据(hw)而不是最新的数据 保证全局读一致

zk

顺序一致性，客户端视角的读一致+写一致，数据有序的，不会倒退的

ES

1 等待足够副本为active或超时
2 写入primary
3 发请求给所有其他副本+等待所有的结果(可能失败或超时)
4 返回客户端(可能是个部分成功的结果)，若存在失败副本，primary报告master某副本写入失败，不承担读请求
足够副本：consistency(5.0以下)/wait_for_active_shards(5.0开始)，这是前置校验，这里判断副本active不代表后面写入一定会成功，但很大概率是的
超时：timeout
replication(5.0以下)：sync/async，是primary写完就返回客户端还是收到所有副本的应答再返回，5.0无此参数，只能同步
高写一致性方案：consistency/wait配置所有副本+写请求带refresh，大概率保证了写入在所有副本都是成功的，而且返回客户端后是可见的
consistency/wait配置小点呢？虽然可能某副本写失败，但很快此副本会不承担读，所以会有少部分时间不一致，但不严重
读一致性：没什么保证，preference走同一副本或许可行

Hbase

数据只有一份(数据只在某个regionServer的某region内)，Hbase内没有副本这个概念，不存在不一致，强一致，绝对的全局的读一致+写一致
疑问：HDFS不是有多副本吗，但是HDFS存放的是不变的文件，即写入完成后各副本之间没有同步，都是静态的，不存在不一致