鉴权:如何保护你的数据安全

鉴权整体架构

etcd鉴权体系架构由控制面和数据面组成:
people-->gRPCServer AuthServer-->Raft-->Apply-->AuthStore-->boltdb

用户发起请求,AuthServer收到请求之后,为了确保个节点间鉴权元数据一致性,会通过Raft模块进行数据同步。
当对应Raft日志条目被集群半数以上节点确认后,Apply模块通过鉴权存储(AuthStore)模块,执行日志条目的内容,
将规格存储到boltdb的一系列鉴权表里面。

etcd目前支持两种Token,分别为SimpleToken和Jwt Token,也可以使用x509证书认证,权限控制方法为RBAC(Role-based access control),
目前支持三种权限:READ、WRITE、READWRITE。

思考题

那些场景会出现Follower日志与Leader冲突,冲突后Follower是如何删除无效的日志条目？

上面的问题分解为两个问题:
1.那些场景会出现Follower日志与Leader冲突？
Leader崩溃的情况下可能,如果Leader和Follower会出现持续崩溃会加剧这个现象。follower可能会丢失一些在新的Leader中日志条目,
也可能会拥有一些Leader中没有的日志条目,或者两者都有发生。

2.Follower如何删除无效日志？
Leader处理不一致是通过Follower直接复制自己的日志来解决。Follower中冲突的日志条目会被Leader的日志覆盖。Leader会记录Follower
的日志复制进度NextIndex,如果Follower在追加日志时一致性检查失败,就会拒绝请求,此时Leader就减小NextIndex值并进行重试,最终
在某个位置让Follower跟Leader一致(从后往前比对,直到一致为止)。

3.为什么WAL日志模块只通过追加,也能删除已经持久化冲突的日志条目？
etcd在实现上采用了一些比较有技巧的方法,在WAL日志中没有删除废弃的日志条目,可以搜索到冲突的日志条目。只是etcd加载WAL日志时,
发现一个Raft Log Index位置上有多个日志条目的时候,会通过覆盖的方式,将最后写入的日志追加到Raf Log中,实现了删除冲突日志条目的效果。