Redis +“真相来源”数据库一致性

Question

我正在构建一个分析工具，并面临一些基于时间序列的指标的性能问题。我一直在试验Redis + bitmapist，它允许我在数据库写入时急切地准备指标，并对性能非常满意。

然而，我对如何确保我的数据库和Redis保持同步感到有点困惑。我的数据库是存储所有事件数据的“真实来源”，但用户仪表板将依赖Redis来显示指标。

我是否应该定期对我的Redis指标进行完整的重新构建，以确保我的数据库和Redis之间没有差异？(例如:事件发生时会写入DB，但不能写入Redis)

如果我的Redis服务器宕机，重新处理所有事件和重建指标将需要很长时间。我的仪表板是否应该查询数据库作为备份计划，即使特定指标的数据库查询逻辑与Redis查询逻辑完全不同？

Answer 1

本质上，您在这里所指的是维护缓存一致性的问题。

首先，您需要确定对于仪表板来说，陈旧程度有多陈旧。一旦你有了它，使用它作为你的限制，并为存储在Redis中的数据设置一个过期时间。请注意，具体如何做到这一点与您选择如何在Redis中存储结果密切相关。

接下来，让您的仪表板执行"get or store“序列。这意味着您首先查询Redis设置中的数据，如果找到，则显示该数据。如果未找到，则查询源数据库，将结果存储在Redis中，设置相应的过期时间，并显示它。对于重新启动或重新启动，缓存预热让Redis保留在磁盘上(默认情况下)，并且在重新启动时不会丢失条目-当然，过期的条目除外。

这一过程将最大限度地减少过时数据的风险，同时根据请求提供数据的直接更新。另一种选择是将存储在原始数据库中的事件也存储在Redis中。然而，该选项将意味着完全复制数据，而不是只保留Redis仪表板中的“热”或选择项，以提高仪表板性能。

Answer 2

Redis上的写操作应该使用可靠的服务总线来完成，这样就可以根据需要重试多次来执行写操作：

• Azure Service Bus.
• RabbitMQ

这样，您的系统将更加可靠，因为消息队列或服务总线可以提供用于定义消息可以不成功地出队1、2或1K次的设置。如果因为Redis宕机而导致向Redis写入指标失败，则没有问题:异步进程将再次尝试写入Redis，依此类推。

您的Redis数据库可能会保持几秒钟、几分钟甚至一个小时的不同步，但您知道，一旦解决了临时问题，您的系统将尝试恢复其正常状态。

另一方面，从Redis3.0开始，你就有了，这是Redis内置的分片方法。也就是说，您可以将数据分区到两个或多个Redis服务器中。这一点很重要，可以避免单个服务器宕机可能影响对客户的整个服务。

此外，Redis还具有数据persistency to disk。

我相信我已经给出了足够的技巧和工具，让你意识到你应该能够可靠地同步你的最终商店和你的基于Redis的快速商店。