我们有用户数据库，用于创建/更新用户和识别（阅读）用户。我们阅读的次数比写的要多。写下约100万/天，阅读大约1亿多。我们可以分开读写，但AFAIK我们需要强大的一致性。
如果我们从阅读副本开始阅读，它将最终保持一致。可能存在用户创建但尚未在只读副本中可用的情况。或者，用户已更新某些信息（名称），并且此更改尚未出现在其他区域。仅从一个区域进行服务意味着其他区域的延迟会更高。
我们目前正在使用RDBMS。 Netflix's Active-Active blog读得很好。但这将是一个巨大的变化。最重要的是，它需要改变团队/组织的思维方式。此外，要做到正确需要付出很多努力。我们需要立即采取措施，因为缓慢的反应令业务陷入困境。因此，我正在尝试探索其他可能给我们留出空间和时间思考实际实施的选择。
作为第一步，我计划在不同地区拥有低TTL的第一级缓存。这将减少相当多的读取。这也将最终保持一致。
第二步可能是使缓存失效到位。这可以减少一点点的不一致。这也将最终保持一致。
[编辑] - 根据意见/建议
这里我谈论的是不同的AWS区域。由于我们有单个写入系统（1个RDBMS），所有写入只会到达一个区域。但是为了实现多区域读取，即使通过db或custom（例如SNS + SQS或Dynamodb流）进行异步复制，也可能会出现延迟，因为调用将跨越区域边界。由于网络问题可能会出现故障，这可能会导致进一步的延迟（重试等）。
是的，最终的一致性会有所帮助，但我们将不得不考虑上面列出的问题。我们可能不得不接受一些不一致和失败。可能有时会通过支持处理客户问题。我也相信，与利益相比，这些问题相当少，而且大多数时候这些问题都是暂时的。我想要找到的是一个更好，更简单的解决方案，如果有的话。我认为这是我们许多人试图解决的问题，或许多人已经解决了。因此，最好采取指导和学习。
提前致谢!!!
答案 0 :(得分：0)
我觉得你的解决方案（跨区域读取副本并具有低ttl的第一级内存缓存）是合适的。通过内存缓存为客户提供服务。如果此缓存中没有用户对象，则从read replica中获取它 - ＆gt;存储在缓存中 - ＆gt;为它服务。如果用户更改假设名称;只需更新内存缓存并创建asynchronus事件（可能通过发送JMS消息）来更新主数据库。
因为您从内存中用户提供的服务将会看到更新的信息。
请注意，此解决方案非常完美，因为这适用于IAM，而不适用于产品信息，因为用户一次只能从一个位置登录。