分布式系统中元数据、Location Cache、Schema 的管理的工程实践

实践

对于一个规模不超过100台机器的系统，元数据最好不要做持久化，适合启动期间做汇报。

有什么好处呢？无持久化状态，就不需要担心持久化数据和内存数据不一致的问题，不用担心很多升级兼容的问题。

机器规模不大，做实时汇报和实时收集，代价非常小，使用并行处理，几秒钟就可以做完。

当前，这一切有个前提：多 ZONE 隔离，轮转升级。升级期间， ZONE 之间只有日志流，不会有跨 ZONE 的其它数据访问。升级完一个 ZONE，再升级下一个 ZONE。直至所有 ZONE 均升级完毕后，才放开多 ZONE 之间的通信管制。

这么做的代价是，升级期间提供服务的 ZONE 会减少一个。但是这通常是可以接受的。

Rethink

对于规模更大的集群，这个方法存在的问题不是汇报时间长短的问题，而是元数据内存占用问题。假设集群中有大量不活跃的元数据，这些元数据是否应该做汇报呢？如果汇报，可能机器很快就撑爆了。

两种解决思路：

1. 改进汇报方式，例如改变粒度，把细粒度汇报做进一步细分，做成大粒度汇报，按需汇报等。
2. 增加持久化的内部表，数据都是存在内部表中，按需拉取。

各有利弊。

不过这个事情如何破解呢？要看场景，从你服务的对象角度出发找破局点。不能为了技术而技术。技术再好，在客户场景里都是千疮百孔！