在使用最终一致的分布式数据存储(在我的情况下为 CouchDB)的场中运行 Web 应用程序时,我是否应该确保给定用户始终被定向到相同的数据存储实例?
在我看来,任何 Web 请求都可以使用任何数据存储的替代方法增加了处理一致性问题(重试、检查等)的复杂性。另一方面,如果给定会话中的用户总是被定向到同一个沙发节点,我的一致性问题会不会主要围绕“共享”用户数据而被大大简化?
我也对指导用户的策略感到好奇,但也许我会保留另一个问题(欢迎评论)。
在使用最终一致的分布式数据存储(在我的情况下为 CouchDB)的场中运行 Web 应用程序时,我是否应该确保给定用户始终被定向到相同的数据存储实例?
在我看来,任何 Web 请求都可以使用任何数据存储的替代方法增加了处理一致性问题(重试、检查等)的复杂性。另一方面,如果给定会话中的用户总是被定向到同一个沙发节点,我的一致性问题会不会主要围绕“共享”用户数据而被大大简化?
我也对指导用户的策略感到好奇,但也许我会保留另一个问题(欢迎评论)。
根据CAP 定理,分布式系统可以具有完全一致性(所有节点同时看到相同的数据)或可用性(每个请求都收到响应)。在分区或数据存储实例故障期间,您必须以一个换另一个。
我是否应该确保给定用户始终被定向到相同的数据存储实例?
理想情况下,您不应该!当给定的实例失败时你会怎么做?分布式数据存储的一个主要特性是在网络或实例故障的情况下仍然可用。
如果给定会话中的用户总是被定向到同一个沙发节点,我的一致性问题会不会主要围绕“共享”用户数据而被大大简化?
你是对的,这样架构会简单得多,但同样,如果该实例失败,你会怎么做?大量的工程工作已经投入到分布式系统中,以允许多个实例回复查询。我不确定 CouchDB,但 Cassandra 允许您选择一致性模型,您必须权衡可用性以获得更高程度的一致性。默认情况下,客户端配置为以循环方式请求服务器,从而分配负载。
我建议您阅读Dynamo 论文。作者描述了分布式数据库背后的许多工程细节。