Nosql 是否可以在显示最终一致性的数据存储中管理用户/身份？

是否可以在显示最终一致性的数据存储中创建/存储用户帐户

如果没有一堆复杂的体系结构来避免出现两个具有相同UID（例如电子邮件地址）的帐户的情况，管理帐户创建似乎是不可能的

最终一致性存储的用户是否使用单独的一致性数据库作为身份存储，或者是否有我应该探索的解决方案/模式

提前感谢,

Jamie

在最终一致的数据存储中使用管理是可能的。我们做到了。它在以下假设下工作：

冲突不应该发生，当冲突发生时，有一条明确的解决冲突的道路。如果帐户ID是一个人的电子邮件地址，那么如果两个不同的人试图在同一封电子邮件下注册，那么这里就有一个更大的问题。在这种情况下，我们所做的是在发现冲突后立即阻止这两个新帐户，并向冲突地址发送电子邮件，向用户解释存在问题（可能存在欺诈）。您可以要求用户重置为该帐户，也可以要求他们与支持部门联系

同一用户在数据不一致的时间段内重复访问同一复制副本。例如，如果某人刚注册，下一个请求是登录，则必须根据存在新注册详细信息的数据副本验证该登录。因此，如果最终的一致性是由于位于不同地理位置的多个数据中心造成的，并且在正常情况下，请求会发送到地理位置最近的数据中心，那么您就可以了

---

存在一些边缘情况，例如，如果用户针对一个数据中心注册，那么该中心崩溃，现在用户无法登录，即使他仍然可以看到从其他数据中心提供的应用程序。您可以根据每日新用户数和数据中心平均停机时间计算此情况的预期频率。然后决定是否值得担心（百万/十亿/无论您的数字是多少）中的一个用户出现问题，并可能联系支持部门。不久前，我面临着同样的决定，从成本效益的角度来看，答案是否定的。

谢谢+埃拉德。这是一个非常有用的答案。除此之外，我还得出了一个结论，即通过延迟账户定稿，可以减少第2点的影响。这可以通过发送一个链接来验证用户的电子邮件地址来实现。该帐户将被创建，但不会被激活。在激活时，如果存在两个具有相同电子邮件的帐户，则可以进行解决。此外，您可以通过对帐户等一致性关键信息使用更高的一致性级别，将最终一致性对Cassandra等平台的影响降至最低，同时利用信息最终一致性的速度，使信息的最新性变得不那么重要。见一致性水平@