我正在编写一个实时聊天应用程序，许多用户都会使用它。我正在考虑使用Amazon的ElasticCache Redis来管理我们的PUB / SUB和最新消息缓存。
我看到的唯一问题是将这些实时消息保存到数据库以备将来使用。有关可以使用哪种策略将这些消息从Elastic Cache保存到数据库的任何建议。
RDS是首选还是我应该使用NoSQL，例如Dynmodb存储这些消息？ 我应该创建一个队列来存储来自Cache的这些消息，还是保存它们实时也可以。
由于
答案 0 :(得分：4)
此处适当的策略主要取决于卷，预期查询模式和邮件保留。我们假设您希望支持永久保留并从那里移动：
大型RDS实例每秒可轻松处理数千次写入，而读取从站将有助于有效平衡读取负载。特别是Aurora非常有用，我建议你研究它并将其与传统的RDS进行比较。此外，由于不同的锁定策略对整体吞吐量更有利，因此底层机制的Postgres将具有比MySQL支持的实例更高的写入吞吐量。如果你的直播消息是通过pubsub系统转发的，那么额外的＆＃34;最近的消息＆＃34;如果音量足够低，则可能实际上不需要redis in redis可以由读取从属设备处理，也可以由主设备处理。这也取决于聊天系统的类型。 1对1聊天与基于会议或全球聊天将具有显着不同的阅读特征。
SQL解决方案的最大问题是随着时间的推移消息，并且如果您的消息计数达到十亿+规模，则能够有效地显示任何消息。根据不同的聊天类型，这可能是可分解的，但像NoSQL解决方案这样的东西可能会更有意义。当然，他们并非没有警告。它们可以更加水平地扩展，并且能够处理高端每秒写入或消息数量的更高增长，并且基于数据模型具有更自然的分片能力，但数据模型将更加严格和更难以某种方式查询。
话虽如此，为简单起见，如果您不打算传递十亿条消息标记或1000条消息/秒，那么从SQL开始可能会提供一些简单性和灵活性。从具有较少专业知识的NoSQL数据库开始，更有可能比通过遇到意外警告或开发问题更快地使您陷入麻烦。
就您实际使用的写入模式而言，我认为首先写入数据库，第二次写入缓存，并在成功写入后发布到pubsub主题有助于确保历史一致性。这也取决于你想做的保证。如果实时交付比历史准确性更重要，那么相反的顺序可能适用。但是，如果选择SQL数据库，则意味着吞吐量直接与单个SQL主数据库的写入吞吐量相关联。 Postgres最近推出了双向复制的可能性，它为您提供了多主机支持，但它有很多警告，我不相信RDS支持它。
对于pub-sub redis可能就足够了，但这又取决于规模。在更高端，更分散和容错的东西可能更合适。例如，AWS有一个专用的pubsub service with SNS。这将有助于缓解管理，并且在消息吞吐量方面可能会有更大的增长空间。 Redis是伟大的，并且非常快，但它也将成为单点故障，受内存限制，并且在一天结束时绑定到单个线程。但是如果你从规模的低端开始并且没有计划达到非常高的吞吐量，那么Redis就足够了。
重要：但是，对于pubsub使用redis的一件事是redis should not be exposed to outside connections。这是一个潜在的大规模安全问题，因此，如果您的网络外部的客户端直接连接（就像我假设您希望使用聊天系统），Redis将是一个糟糕的选择。应始终阻止外部连接。 始终
TL; DR： - 对于规模较低的端点，RDS可能会在很长一段时间内通过传统的主从设置满足您的需求，但像Dynamo或Cassandra这样的NoSQL解决方案可以更好地满足长期增长，令人难以置信的高吞吐量或显着的数据量。 - 出于安全考虑，Redis可能不是PUBSUB的绝佳选择，对于缓存层可能需要也可能不需要，但其他pubsub技术可能足以用于实时邮件传递。