关于obproxy 备优先读策略的优先级疑问

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】 obproxy
【 使用版本 】 v4.2.1
【问题描述】当将obproxy的 proxy_route_policy 设置为 follower_first 时当客户端弱读的时候优先发往备副本,如果无备副本可用则发往主副本。OBCP V3教程如下的优先级是如下
image

如果是无备副本可用则发往主副本,考虑优先级的顺序Region位置>合并状态>IDC关系?优先级为什么不是如下:

情况A: ( 同机房不合并的主----->同城不同机房不合并的主 这种不考虑直接不同城的主原因?)

同机房不合并的备 —> 同城不同机房不合并的备–>
同机房在合并的备---->同城不同机房合并的备----->
不同城不合并的备----->不同城合并的备------->
同机房不合并的主----->同城不同机房不合并的主—>
不同城不合并的主----->不同城合并的主

B、先考虑region以及合并状态,所有的备优先,没有备在考虑主 ,为什么优先级不是这种?

同机房不合并的备 —> 同城不同机房不合并的备–>
同机房在合并的备---->同城不同机房合并的备----->
不同城不合并的备----->不同城合并的备------->
同机房不合并的主----->同城不同机房不合并的主—>
同机房合并的主----->不同城不合并的主
同城不同机房合并的主----->不同城合并的主

1 个赞

因为虽然是备优先,但是也要考虑各种路由策略对请求的影响
对于A情况的疑问:
先考虑同城不合并的主、以及同城不同机房不合并的主,原因是如果跨城访问,rt会高很多
对于B情况的疑问:
我们这边是首先考虑发往备、且尽量保证同城同机房的情况,然后再考虑合不合并的情况,可以看到越往后的考虑,控制的粒度越小,并且整体控制并不是完全顺序关系的,首先考虑尽量发往同机房、同城,然后考虑尽量发往备、最后考虑尽量发往不合并的机器,当前上面说的也不是很完美,比如合并的主是最后考虑的,哪怕在同城,建议还是按照我们给出的策略来理解

1 个赞