文章目录
前言
当面对一个复杂的分布式系统时，如果我们想了解其内部运行的情况，我们通常的做法是进行内部指标metric的收集和暴露。但是如果我们遇到一些内部指标的统计需要进行系统服务内部逻辑的大规模改动或者目标metric的指标收集操作会影响到服务的正常请求处理，那么这个时候我们有没有好的办法呢？最完美的方法无疑是搭建出一个元数据完全一致的READ-ONLY模式的系统，注意了这里指的是一个独立的服务。本文笔者将以Ozone的Recon服务为例，来聊聊这个只读模式的系统应该如何来做。
Ozone Recon模式的运作原理
在Ozone中，就做了这么一个只读模式的SCM服务，名字叫Recon服务。Recon用来做SCM内的Container情况的分析。
Recon作为只读模式的SCM，它理应持有完全一致的Container信息，这样才能做准确的模拟分析。但这里有个问题，Recon不能处理来自外部的Container写请求操作的。对于这种情况的处理，Recon采用了下面的办法：
- 1）Recon从SCM服务节点上同步一份初始Container db文件。
- 2）Datanode额外配置Recon的地址作为Container Report的另外一个心跳报告地址。
- 3）Recon和SCM一样，同样接受下面Datanode的Container报告信息，进行内部Container状态的更新。
- 4）当Recon接受到新的Container时，它需要额外向SCM服务查询，此Container是否是有效的Container，如果是，则添加到自身内存中。
- 5）Datanode将会实现对于来自于SCM的Container Delete操作的ACK回复，表明其已正确删除本地的Container。Recon可以利用此ACK回复正式移除其维护的对应Container信息。
Recon采用了上述的方案后，就能保证和SCM主服务完全一致的内存元数据信息了，然后它就可以做许多灵活的自定义分析了，并且它不会影响到SCM服务的运行。假设没有这样一个“影子”系统，我们想要的部分系统分析将会受制于系统内部的本身逻辑实现等原因。
以下为上述步骤的流程图展示：
总结
不过笔者在这里不仅仅是只想谈Ozone Recon的原理过程，而想表达的是Ozone Recon的只读模式系统实现原理具有通用性。它的实现思路完全适用于类似的其它基于心跳 report进行状态同步的分布式存储系统。在这点上，它的这个实现方式是具有通用性的。 而且作为只读的系统，它不进行任何报告的action回复指令操作，风险也很低，对其下报告的slave节点没有任何的影响。
引用
[1].https://issues.apache.org/jira/browse/HDDS-1996 . Ozone Recon Service v0.2
