Raft优化

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/maxlovezyy/article/details/83177990

副本跨2个AZ

这种情况下必定3副本中有两个副本在一个AZ,另一个副本在另一个AZ。那么我们可以在创建复制组的时候给复制组贴一个标签,2个副本的标签为可参与选主,另一个副本永远不可以发起选主。这样优化的好处是写的时候不会收到跨机房网络的影响。当然,在副本位置变更时需要更新标签。

从读取

论文中从副本是不可以读取的,主的话有发心跳确认主身份后读取和租约期内的读取两种方法。这里提出一种方法,可以做到保持线性一致性的情况下在从上读取。方法就是客户端随机打读请求到N个副本上,副本在收到请求后先发起一轮RPC,问询当前的commit index作为本次读请求的read index,当自己的raft log replay到read index后,就可以返回给客户端响应了。

这里可以做2个优化:

  • 一个是客户端在做完写请求之后,leader顺便返回这个请求的log position(term + log index),客户端在读取的时候把这个信息发送给副本,副本收到之后直接保证log replay到这个位置即可。
  • 一个是副本如果log与客户端的要求有差距,可以拒绝服务,之后客户端根据错误信息重定向到其他副本。

从读取这个优化适用于IO为瓶颈的时候,对于value比较大的系统来讲可能会用到这种优化,比如value有几M+。不过架构上一般都是在外围做CDN和缓存层来解决压力问题。但是这里提出这种对读取优化的服务能力不失为一种可选择的热点读取优化。

猜你喜欢

转载自blog.csdn.net/maxlovezyy/article/details/83177990