database - 在多个区域扩展身份服务

Question

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

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

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

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

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

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

[编辑] - 基于评论/建议

这里我说的是不同的 AWS 区域。因为我们有单写系统(1 个 RDBMS)，所以所有的写操作都只会到达一个区域。但是为了实现多区域读取，即使通过数据库或自定义(比如 SNS + SQS 或 Dynamodb 流)进行异步复制，也可能会有延迟，因为调用将跨越区域边界。由于网络问题可能会出现故障，这可能会再次导致进一步的延迟(重试等)。

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

提前致谢!!!

Answer 1

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

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

请注意，此解决方案是完美的，因为它适用于 IAM 而不是产品信息之类的内容，因为用户将一次从一个位置登录。