我有一种独特的配置管理问题。我不太认为 zookeper 是为解决它而构建的,但我可能是错的。
系统将为网络中的多个设备提供配置。配置本身由数千万个配置对象组成。
如果尚未配置设备,则需要读取整个配置的当前版本(数千万个对象)。
配置设备后,它需要接收对配置的版本更改。变化仅以数百/秒或低千/秒的量级发生。
使用 zookeeper 的基于文档的模型和 1 MB 响应限制,这似乎不太适合。我错了吗?
我有一种独特的配置管理问题。我不太认为 zookeper 是为解决它而构建的,但我可能是错的。
系统将为网络中的多个设备提供配置。配置本身由数千万个配置对象组成。
如果尚未配置设备,则需要读取整个配置的当前版本(数千万个对象)。
配置设备后,它需要接收对配置的版本更改。变化仅以数百/秒或低千/秒的量级发生。
使用 zookeeper 的基于文档的模型和 1 MB 响应限制,这似乎不太适合。我错了吗?
ZooKeeper 可能仍然不适合您的应用程序,但 1 MB 响应限制是每个操作。因此,如果所有配置对象的大小都小于 1 MB,那么读取/写入它们不会有问题。
对于这种情况,需要记住几件事:所有数据都存储在内存中。它通过记录到磁盘而变得持久,并且使用复制变得可靠,但是如果你的内存用完了,你就完成了。还有每个 znode 的内存开销(大约 100 字节)。如果您有 10,000,000 个对象并且每个对象仅存储 100 个字节,那么您的内存占用量约为 2G。假设您有一个配置相对较好的服务器,这应该不是什么大问题。另外请记住,从崩溃中恢复需要更长的时间,因为您必须在启动期间读取大约 2G 的数据。
你在客户端也有一个相关的问题:如果客户端真的要读取所有的配置对象,他们会通过网络提取大量数据!假设每个对象都小于 1 MB,您不会遇到任何限制,但这需要一点时间。