分布式系统中元数据、Location Cache、Schema 的管理的工程实践
作者：互联网
实践
对于一个规模不超过100台机器的系统，元数据最好不要做持久化，适合启动期间做汇报。
有什么好处呢？无持久化状态，就不需要担心持久化数据和内存数据不一致的问题，不用担心很多升级兼容的问题。
机器规模不大，做实时汇报和实时收集，代价非常小，使用并行处理，几秒钟就可以做完。
当前，这一切有个前提：多 ZONE 隔离，轮转升级。升级期间， ZONE 之间只有日志流，不会有跨 ZONE 的其它数据访问。升级完一个 ZONE，再升级下一个 ZONE。直至所有 ZONE 均升级完毕后，才放开多 ZONE 之间的通信管制。
这么做的代价是，升级期间提供服务的 ZONE 会减少一个。但是这通常是可以接受的。
Rethink
对于规模更大的集群，这个方法存在的问题不是汇报时间长短的问题，而是元数据内存占用问题。假设集群中有大量不活跃的元数据，这些元数据是否应该做汇报呢？如果汇报，可能机器很快就撑爆了。
两种解决思路：
- 改进汇报方式，例如改变粒度，把细粒度汇报做进一步细分，做成大粒度汇报，按需汇报等。
- 增加持久化的内部表，数据都是存在内部表中，按需拉取。
各有利弊。
不过这个事情如何破解呢？要看场景，从你服务的对象角度出发找破局点。不能为了技术而技术。技术再好，在客户场景里都是千疮百孔！
标签：持久,ZONE,Cache,粒度,升级,汇报,Location,分布式系统,数据 来源： https://blog.csdn.net/maray/article/details/116201043