Rocket - tilelink - FIFOFixer

https://mp.weixin.qq.com/s/JS4Pguwa6LXjPsMq6nW8HA

 

简单介绍FIFOFixer的实现。

 

​​

 

1. 基本介绍

 

按照一定的策略把某一部分manager的fifoId摊平转换为一个fifoId，并为这个fifoId实现同步功能。这样上游节点看到的fifoId就减少了，所需要实现的同步功能就少了，减轻了其负担。

 

2. TLFIFOFixer.Policy

 

用于筛选Manager的策略：

​​

 

定义了如下三种：

​​

 

3. fifoMap

 

用于根据策略重新映射各个manager的fifoId：

​​

 

1) 按策略分成两组：

 

​​

符合策略的叫flatManagers，不符合的叫keepManagers。

 

2) 取得两组manager的fifoId：

 

​​

如果某fifoId在两个组中都有，那么把它当做符合策略的使用。

 

根据注释：

a. 所谓flat，就是摊平，所有的fifoId都变成0；

b. 所谓keep，就是保持，compacted的意思是压缩，即保持每一个都不一样，但是压缩成为连续的自然数；

 

3) 构建两组老fifoId到新fifoId的映射：

 

​​

a. 摊平的那一组，所有fifoId映射后的值都是0；

b. 保持的那一组，所有fifoId映射为从1开始的连续的自然数值；

 

4) 把两组映射合在一起：

 

​​

 

5) fixMap

 

为每一个manager分配的fifoId：

​​

A. 符合策略的manager的新fifoId为0；

B. 不符合策略的manager有两种情况：

a. 若原fifoId = None，新fifoId=None；

b. 若原fifoId != None，新fifoId为按顺序压缩后的新fifoId；

 

6) splatMap

 

重新映射，把符合策略的fifoId压缩为从0开始的自然数：

​​

a. 不符合策略的manager的新fifoId为None；

b. 原fifoId=None的manager，新fifoId不变，也是None；

c. 符合策略的manager的新fifoId为按顺序压缩后的从0开始的自然数；

 

7) 对比

 

​​

 

4. diplomacy node

 

需要调整下游节点传过来的fifoId，进行fix，也就是使用fixMap生成的新fifoId：

​​

 

5. lazy module

 

用于实现内部逻辑：

a. 因为符合策略的manager的fifoId被摊平了，所以需要为他们做同步功能；

b. 不符合策略的manager各自具有不同的fifoId，其同步由client实现；

 

1) 成对出现的输入边和输出边

 

​​

 

2) 处理下游的managers的fifoId

 

​​

 

3) 是否属于符合策略的fifo的请求：

 

​​

其中：

a. edgeIn表明使用的是转换之后的fifoId，根据diplomacy node中的用法，即fixMap中的fifoId；

b. _.fifoId==Some(0)表明address所属的manager符合策略；

c. 因为上游client看到符合策略的manager的fifoId都为0，而与之对应的下游manager的fifoId不一定为0，所以需要我们为这些请求做同步处理；

d. _.fifoId!=Some(0)表明address所属的manager不符合策略；

 

4) 找出符合策略的manager：compacted

 

​​

a. f==Some(0)：表明对应的manager符合策略；

b. 不符合策略的manager对应的None被flatMap过滤掉，不会存在于compacted中；

c. 符合策略的manager中，原fifoId为None的，被fifoId=s还原为None；

d. 符合策略的manager中，原fifoId不为None的，被fifoId=s重新编排为从0开始的自然数；

e. edgeOut表明使用的是下游manager；

 

5) a_id

 

把摊平的fifoId再提起来：

​​

根据请求访问的地址，把请求分配到不同的fifo；原来fifo相同的还分配到同一个fifo。

 

a_noDomain表示manager属于符合策略的manager中原fifoId为None的那一部分。

 

6) 记录某source的请求是否需要做同步：

 

​​

响应消息到来时，就不再需要做同步了。

 

7) 是否需要挂住停止发送请求：

 

​​

a. 不需要Fifo的client不作处理：c.requestFifo；

b. 该client是否包含当前source；

c. 该client下属所有的source中是否有请求排斥其他请求：flight.slice(c.sourceId.start, c.sourceId.end).reduce(_ || _)

 

该client若要求挂住，需满足如下条件：

a. 当前请求源自该client；

b. 请求的第一个beat；

c. 该client下属的source中已经存在发出但仍未响应的请求；

d. a_noDomain || id =/= a_id

 

这里分析一下d：

a. a_noDomain

 

若a_noDomain为真，则表明两个请求的fifoId至少有一个为0。请求的fifoId=0表明对应的下游manager的fifoId=None，意为接收到的请求不一定会被按顺序响应。

 

若只有一个请求的fifoId=0，那么这两个请求对应着两个下游manager，无法保证响应顺序；

若两个请求的fifoId=0，因为可能存在两个以上下游manager的fifoId为None。所以虽然两个请求的fifoId都为0，但无法保证针对的是同一个下游manager。即便是同一个下游manager，也无法保证顺序。

 

b. id =/= a_id

 

意为这一次请求的a_id与上一次记录的id不同。

同时发出两个相同fifoId的请求，由下游manager保证这两个请求的响应消息安装先后顺序返回；

同时发出两个不同fifoId的请求，其响应顺序则无从保证。

 

8) 是否存在client要求同步：

 

​​

 

9) 根据是否需要同步连接输入边和输出边的channel a/d：

 

​​

 

10) channel b/c/e不做处理：

 

​​

 

6. a_notFIFO重定义

 

是否需要为请求做序列化：

​​

 

可以看到这个名字有两个问题：

a. 词不达意；

b. 名称中含有反转，理解时需要拐一个弯；

 

可以看到，后面使用时也多用其反转义项：

​​

 

所以这里最好重新定义，反转一下意义：

​​

 

修改后用处如下：

​​