整理思路

master

2PC

Can

redis

存储

异步

逻辑时钟-逻辑顺序，发现过时

管理者有proxy和shard服务器的路由数据管理者将shard路由信息下发到proxy，将proxy路由信息下发到发现服务，tcaplus假设正常路由变化只有扩容和缩容，通过中间状态解决路由一致的问题。对于单shard没法负载均衡，考验hash算法是否能够完全分配。写一致性用一致性hash将同样的key放在同样的proxy上。hash路由的好处是牺牲顺序，但带来读写落在同一个节点上，保证一致性操作。持久性，异常会丢数据数据迁移，shard分裂，主动同步+proxy纠错没有管理者挂掉的容灾方案细节缺失：是否有异常情况重试?迁移写采用版本控制，保证写入和迁移不冲突

UndoRedo

binlog

move

proxy

双挂，剩下点不知道最终数据是什么，没有办法保证一致

Ack

阻塞

redis流言协议：存活检测：大部分检查失败标记为Fail，多点一致性问题消息传递：

client

shard

从redis

Propare

gfs

数据一致性

1. 缺陷发现、自恢复

有状态

3PC

迁移

流言协议1. 集群节点检测、加入、离开、崩溃、恢复2. 信息广播

hdfs

发现

客户端根据hash选定slot，但是slot在哪些redis上并不知道每个redis保存路由信息：slot在那个节点上、是否迁移；master slave节点位置；各个存活状态可用性：master是slave选举出来的，master失活到选举出来需要时间，此时无法提供写服务master选举依赖slave的最小id，获取大多数同意，因为没有数据一致性要求，比较简单读写一致性：客户端能找到slot的master节点（没有异常的情况）本质是单点原子读写写写一致性：redis写原子性，master上节点写一致（没有异常）路由不一致带来的问题：读写无影响，因为可以容忍失败，但是选master一定要一致！slot迁移：读写找原节点、没有找新节点，原子性迁移每个键。发布订阅，不知道谁订阅全网广播，遇到脑裂数据就不不一致了，去中心化不用paxos就会遇到路由信息变化只有了两种：slot迁移和master切换redis版本流言协议：tcp长连接、全部连接，随机发送已知节点，交流本节点slot master slave、其他节点位置和存活情况协议一致性问题：心跳包版本（Lamport timestamp），slot数据全同步；master slave；fail累计计数、达到一定广播

超时、乱序

中心化方便同步，但是需要考虑挂掉的替代者

Commit/Rollback

客户端

协议

Vote

从

大文件、chunk单写多读，写和读都没有一致性问题namenode启动获取datanode chunk信息客户端是否可以缓存chunk信息，如何确保一致性文件校验、读可以发现错误只写不改，流水线同步复制客户端读无法找到一个正在写的chunk，因为datanode写完才会更新namenode删除，搞出一个回收站

大文件、chunk分。路由压力减轻写的问题，单写多写？读的问题，一致性读、最终一致性？文件损坏、崩溃快速切换（真的需要很快吗？客户端可以重试，还有副本）高吞吐、延时无要求，什么拖累的延时？客户端缓存chunk路由信息，减少master压力，但带来一致性问题。读很难一致性版本和校验检测技术，客户端读校验、chunk服务器自检查，写入校验追加写至少一次策略类似消息队列租约，保证多点写入的顺序一致。本质还是选主完成同步操作，实际写同步类似两步写，但允许部分节点失败重试版本控制，master有chunk版本，获取租约增加，chunk服务器写入成功增加，当两者不一致chunk失效

协调者路由

过程失败全部在等超时回滚

管理

崩溃、恢复

Tcaplus

会话保持

路由查找删除回收无效chunk写入选主，顺序同步版本检查

分布式数据库：存储分布：数据库层面分布式存储；文件系统分布式；多点存储客户端多读路由：类型 固定路由；动态路由 算法：顺序 hash 客户端请求：proxy代理请求；master单点存储查询客户端自己再找；各个节点存储 变动：单点控制下发变动；集群集体决定