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. 名称中含有反转，理解时需要拐一个弯；
可以看到，后面使用时也多用其反转义项：
所以这里最好重新定义，反转一下意义：
修改后用处如下：
