是否可以在具有最终一致性的数据存储中管理用户/身份？
是否可以在具有最终一致性的数据存储中创建/存储用户帐户？
如果没有大量架构复杂性来管理帐户创建似乎是不可能的，以避免出现两个具有相同 UID（例如电子邮件地址）的帐户的情况？
最终一致性存储的用户是否使用单独的一致数据库作为身份存储，或者是否有我应该探索的解决方案/模式？
预先感谢，
杰米
Is it possible to create/store user accounts in a data store that exhibits eventual consistency?
It seems impossible to manage account creation without a heap of architectural complexity to avoid situations where two account with the same UID (e.g. email address) can occur?
Do users of eventual consistency stores use a separate consistent DB as an identity store, or are there solutions/patterns that I should be exploring?
Thanks in advance,
Jamie
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在最终一致的数据存储中进行使用管理是可能的。我们做到了。它在以下假设下工作：
冲突不应该发生，当冲突发生时，有一个明确的解决冲突的路径。如果帐户 ID 是一个人的电子邮件地址，那么如果两个不同的人尝试使用同一电子邮件进行注册，则会出现更大的问题。在这种情况下，我们要做的就是在发现冲突后立即阻止两个新帐户，并向冲突地址发送电子邮件，向用户解释存在问题（可能存在欺诈）。您可以要求用户重置帐户或要求他们联系支持人员。
同一个用户在时间范围内重复访问，数据不一致的情况会转到同一个副本。例如，如果一个人刚刚注册，下一个请求是登录，您必须根据存在新注册详细信息的数据副本验证该登录。因此，如果最终的一致性是由于位于不同地理位置的多个数据中心造成的，并且在正常情况下，请求会发送到地理位置上最近的数据中心，那就没问题。
有一些边缘情况，例如，如果用户在一个数据中心注册，那么该中心崩溃了，现在用户无法登录，即使他仍然可以看到由其他数据中心提供的应用程序。您可以根据每天的新用户数和平均数据中心停机时间来计算这种情况的预期频率。然后决定是否值得担心（百万/十亿/无论您的数字是多少）中的一个用户遇到问题并可能联系支持人员。不久前我也面临着同样的决定，从成本效益的角度来看，答案是否定的。
It is possible to do use management in an eventually consistent data store. We do it. It works under the following assumptions:
Conflicts shouldn't happen and when they do there's a clear path to conflict resolution. If the account ID is a person's email address, then if two separate people try to register under the same email there's a bigger problem here. What we do in this case is block both new accounts as soon as the conflict is discovered and send an email to the address in conflict explaining to the user that there's an issue (possible fraud). You can either ask the user to reset to the account or ask them to contact support.
Repeated access by the same user within the timeframe in which the data is inconsistent go to the same replica. For instance, if a person just registered and the next request is a login, you must validate that login against the data replica where the new registration details exist. So if the eventual consistency is due to multiple data centers in different geographic locations and under normal conditions a request goes to the closest data center geographically, you're OK.
There are some edge cases, such as if a user registered against one data center, then that center crashed, and now the user cannot login even though he still can see the application - served from some other data center. You can calculate the expected frequency of this case based on your number of daily new users and average data center downtime. Then decide whether it's worth worrying about one user in a (million/billion/whatever your number is) having a problem and possibly contacting support. I faced the same decision not long ago and decided that from a cost-benefit perspective the answer is no.