在多个区域扩展身份服务

Posted 2023-02-23

【中文标题】在多个区域扩展身份服务

【英文标题】：Scaling Identity service in multiple regions

【发布时间】：2018-01-03 23:00:51

【问题描述】：

我们有用于创建/更新用户和识别（读取）用户的用户数据库。我们阅读的次数多于写作的次数。每天写大约 100 万，阅读大约 100+ 万。我们可以分离读写，但是我们需要强一致性。

如果我们从只读副本开始读取，它将最终保持一致。可能存在用户已创建但在只读副本中不可用的情况。或者，用户更新了一些信息（名称），而其他区域尚未出现此更改。仅从一个区域提供服务意味着其他区域的延迟更高。

我们目前正在使用 RDBMS。 Netflix's Active-Active blog 是一本好书。但这将是一个很大的变化。最重要的是，它需要改变团队/组织的心态。此外，要做到这一点需要付出很多努力。我们需要立即采取一些措施，因为缓慢的响应正在给业务带来困扰。因此，我正在尝试探索其他可能会给我们喘息空间和时间来考虑实际实施的选项。

作为第一步，我计划在不同区域建立一个低 TTL 的一级缓存。这将减少相当多的读取。这又将是最终一致的。

第二步可能是设置缓存失效。这可以稍微减少不一致。这又将是最终一致的。

还有哪些其他选择？ Google、Facebook 等公司如何 规模？ 我不想进入分片。或者，我应该吗？我们确实有 自动增量。 最终的一致性真的有这么大的痛苦吗？一世 在面向阅读的情况下有使用它的经验，但这个是 读/写。

[编辑] - 基于 cmets/suggestions

这里我说的是不同的 AWS 区域。由于我们有单一写入系统（1 个 RDBMS），所有写入都将仅到达一个区域。但是对于实现多区域读取，即使通过 db 或自定义（例如 SNS + SQS 或 Dynamodb 流）进行异步复制，也可能存在延迟，因为调用将跨越区域边界。由于网络问题可能会出现故障，这又会导致进一步的延迟（重试等）。

是的，最终的一致性会有所帮助，但是我们必须考虑上面列出的问题。我们可能不得不接受一些不一致和失败。有时可能会通过支持来处理客户问题。我也相信，与收益相比，这些问题会相当少，而且大多数时候这些问题都是暂时的。我想要找出的是一个更好、更简单的解决方案，如果有的话。我认为这是一个我们中的许多人将试图解决或许多人已经解决的问题。因此，最好接受指导和学习。

提前致谢！！！

【问题讨论】：

解决Anuj的好问题:)

你不同意最终的一致性吗？因为在任何地方都会导致规模化......如果我们尝试同步更新所有节点，那么规模化并不容易

我并不反对最终的一致性。查看修改

【参考方案1】：

我觉得您的解决方案（具有跨区域的读取副本并具有低 ttl 的一级内存缓存）是合适的。从您的内存缓存中为客户服务。如果此缓存中不存在用户对象，则从只读副本获取它-> 存储在缓存中-> 提供它。如果用户更改假设名称；只需更新您的内存缓存并创建异步事件（可能通过发送 JMS 消息）来更新主数据库。

因为你是从内存中服务的，所以用户会看到更新的信息。

请注意，此解决方案非常完美，因为这是针对 IAM 而不是针对产品信息之类的内容，因为用户一次只能从一个位置登录。

【讨论】：

是的，在第二阶段我们可能会这样做。我已经用更多细节更新了这个问题。感谢您的意见。

我扩展了设计，并以 TP 95 的强一致性和低 2 位数毫秒延迟解决了这个问题。我会尽快分享信息。