我想弄清楚我是否走在正确的轨道上。我正在构建一个(实时)统计/分析服务,我使用 redis 来存储一些集合和散列。
现在让我们假设我取得了一些成功,我需要扩大规模。哈希环技术看起来不错,但我的印象是它只适用于缓存场景。
如果一个节点宕机了怎么办?理论上,它的密钥现在由其他节点拥有。在实践中,他们不会拥有数据。它丢失了,对吗?与添加/删除节点相同。
我错过了一些基本的东西吗?这会是穷人的集群吗?
我想弄清楚我是否走在正确的轨道上。我正在构建一个(实时)统计/分析服务,我使用 redis 来存储一些集合和散列。
现在让我们假设我取得了一些成功,我需要扩大规模。哈希环技术看起来不错,但我的印象是它只适用于缓存场景。
如果一个节点宕机了怎么办?理论上,它的密钥现在由其他节点拥有。在实践中,他们不会拥有数据。它丢失了,对吗?与添加/删除节点相同。
我错过了一些基本的东西吗?这会是穷人的集群吗?
在集群中使用多个节点有两个原因:
两者本质上是不同的,但您可以同时实现这两种方法——使用一致的哈希来指向一组具有标准主/从设置的节点,而不是单个节点。
如果集群是您的主要数据存储而不是缓存,您将需要一个不同的重新分配策略,包括复制数据。
我的实现是基于让客户端从 64k 桶中选择一个作为哈希,并拥有一个将该桶映射到节点的表。最初,所有都映射到节点#1。
当节点 #1 变得太大时,它的从节点变为主节点 #2,并且更新表以将节点 #1 的一半键映射到节点 #2。此时,所有读取和写入都将使用新映射,您只需要清理现在位于错误节点上的键。根据性能要求,您可以一次检查所有密钥,也可以像到期系统那样检查随机选择的密钥。