问题标签 [azure-redis-cache]

当我尝试将 redis 用作以下配置的会话服务器时，我遇到了问题：

1. 多个 Windows 服务器使用https://github.com/Azure/aspnet-redis-providers托管相同的应用程序
2. 具有加权路由的弹性负载均衡器将请求重定向到所有 IIS 服务器
3. Redis 托管在 AWS 弹性缓存中，可从两台服务器访问

4. Redis 一次充当 1 个服务器的会话服务器，没有任何问题

   为每个会话创建 3 个密钥

"{/_ktffpxxxxxxg2xixdnhe}_Write_Lock"

"{/_ktffpxxxxxxg2xixdnhe}_Data"

"{/_ktffpxxxxxxg2xixdnhe}_Internal"

问题：当 1+ 台服务器尝试为同一用户提供服务时，通过在同一实例中从 redis 访问会话，如果 server1 已放置，_Write_Lock则 server2 无法读取+更新超时或写入数据，之后它清除了密钥

--> 结果，用户对任何服务器的下一个请求无法验证他/她的会话。

我是唯一一个遇到这个问题的人吗？？请帮忙 ...

注意：在 ELB 中启用会话粘性后，注销不是间歇性的，但这限制了我们在不丢失该服务器的所有用户会话的情况下取出服务器进行升级。

我有个问题。假设我正在使用一个具有 3 个分片（主和从）的 Redis 集群。我才知道，如果一个master和它的slave同时出现故障，Redis Cluster就无法继续运行。之后会发生什么。

1. Redis 集群是否也会从其他 2 个节点中删除所有其他键？（当它回来时）
2. 我们是否需要手动重启这个集群并且我们可以以某种方式保留其他键值（在其他节点上）？
3. 如果我使用 Azure Redis 缓存，它将如何表现？

提前致谢

我们有两个 azure worker 角色——A 和 B。

• A 是一个 Quartz 调度器，它每分钟运行一次作业。
• 它每分钟从“Redis 缓存”中读取一些 id 并为这些 id 执行作业。
• “A”将其输出发布到由 Worker 角色“B”订阅的服务总线队列。
• “B”工作者角色从队列中读取值并对它们执行更多操作。
• 两个工作角色都必须在启动时构建缓存。

现在这里有一些关于 Azure 组件故障的问题：

• 如果 Redis 缓存出现故障，我们该如何处理。我们需要停止执行，直到它再次启动，然后我们需要再次构建缓存。“B”工作者角色应该停止从服务总线拉消息，直到 Redis 再次出现。

• 如何处理工作角色“B”中的服务总线故障？

我们应用程序的一部分用作“规则引擎”。可以根据两个因素配置规则：进程状态和时间。规则可以简单也可以复杂。每条规则都有一个状态 - True 或 False

一个典型的规则如下所示：

时间 9:00 到 11:00 之间的时间和进程 1 状态打开。

时间在 4:00 到 6:00 之间，Process-2 状态为关闭。

所以，这条规则需要在 9:00、11:00、4:00 和 6:00，当 process-1 状态改变，或者 process-2 的状态改变时检查和评估。在评估规则状态是否更改（从之前的状态）之后，我们会引发一个事件。存储新结果，以便下次评估此规则时，可以比较其结果。如果新结果与前一个结果相同，则不会发生任何事情。

我们在应用程序中使用了 3 个不同的组件来实现这一点：

1) Web UI - 创建规则、更改流程状态等。每当流程状态或规则配置发生更改时，它都会引发事件。

2）调度程序 - 这是一个工作角色（窗口服务），每分钟运行一次作业，它检查是否存在开始时间或结束时间是当前时间的任何规则，如果找到，它将向队列提出事件。

3) 规则引擎 - 这个引擎是工作角色（窗口服务），它监听 3 种事件：规则定义更改事件、流程状态更改事件和时间事件。如果发生任何流程状态更改或时间规则事件，它会找出所有以此为条件的规则，触发这些规则并进一步引发事件作为“规则状态更改”。

该解决方案基于 Window Azure 云平台构建。以下是更多设计决策：

1）规则的定义存储在sql server中。如前所述，规则本质上可以是分层的（复杂的）并且由多个条件组成。

2）由于从数据库中按时间或Process1提取规则可能是一项耗时的操作，我们从sql数据库中一次性获取所有这些数据并存储在Redis缓存中。制作密钥以便我们可以通过时间或进程 ID 找到我们的所有规则。此操作在规则引擎启动时完成。所有进程的状态也存储在数据库和缓存中。

3) Azure 服务总线用于将消息从一个组件传递到另一个组件。

4) 每当从 Web UI 更改任何主数据时，都会在队列上传递一个事件，并且规则引擎会更新缓存。

系统的设计考虑了自动缩放。如果工作量增加，队列深度会增加，我们可以向规则引擎添加更多实例。

如果您发现上述设计有任何改进，请提出建议。

以下是我们在高可用性和组件故障方面面临的问题：

使用了多个 azure 服务，它们都可能在不同的时间失败（即使使用了多个实例）：

1) Web UI（Web 角色）99.95 可用性 - 目前这不是问题。

2）调度程序（工人角色）99.95可用性

3) 规则引擎（工人角色）99.95 可用性

4) Azure 服务总线 99.9 可用性

5) Redis Cache 99.9 可用性（数据无 SLA）

假设一切正常，突然出现以下任何一种情况：

问题 1：用户从 UI 更改规则的定义，系统将此数据添加到 sql 数据库，但服务总线没有响应。我们无法将此更改传达给规则引擎，因此系统将不同步。- 一种解决方案可能是回滚数据库操作并告诉用户一段时间后重试。- 另一种选择可能是进行两阶段提交。如果服务总线没有响应，请在数据库中维护一个标志。运行一个后台进程，该进程在队列可用时将此更改推送到队列。

问题 2：用户正在更改任何进程的状态，系统将其添加到 sql 数据库，但服务总线没有响应。此流程状态更改无法与规则引擎通信。规则引擎将不同步。- 与上一个相同。

问题 3：调度程序引擎出现故障：未引发时间事件，因此规则引擎将无法处理这些事件。- 我们可以记录调度程序运行作业的时间。无论何时调度程序，它都应该首先引发所有错过的事件，然后开始执行新的事件。

问题 4：处理来自规则引擎的消息时，缓存出现故障。规则引擎无法处理队列中的消息。这应该没问题，因为我们不会丢失任何消息。但万一缓存回来，它也可能会丢失所有缓存数据。规则引擎将不得不重建缓存（就像在规则引擎启动时所做的那样）。

谢谢你的时间。如果您能添加任何建议，我将不胜感激。

我正在使用 Azure Redis 缓存来存储一些快速查找数据，并且此缓存由 10 个客户端应用程序读取/连接。所有的应用程序都是用 .NET 4.6 编写的，这包括 ASP.NET MVC Web 应用程序、Web API 和少数每 1 秒运行一次的工作角色。所有客户端都使用 StackExchange.Redis 连接到缓存。但是，我遇到了间歇性超时，并且我观察到在 Azure 门户中，最大连接数已达到 1000（对于我的定价层）。由于我只有 10 个客户端应用程序，而且这些应用程序都不是多线程的，那么什么可以创建到缓存的 1000 个连接？

对于缓存客户端，我可以遵循任何最佳实践吗？

我想将大型 JSON 保存到Redis。大小为：大约 5 MB。

有什么方法可以压缩 JSON，然后保存到 Redis。而且，我需要它，因为从 Redis 获取解压缩的数据很慢。

什么是 Azure REDIS 缓存？如何使用它？什么时候用什么时候不用？我可以将它用于从 MS-SQL 服务器访问数据的简单 c# 应用程序吗？开始使用 Azure Redis 缓存的最佳来源是什么？

异常消息：超时执行 GET allBots，inst：1，mgr：不活动，err：从不，队列：7，qu：0，qs：7，qc：0，wr：0，wq：0，in：65536，ar： 0，IOCP：（忙=2，空闲=998，最小=1，最大=1000），工人：（忙=0，空闲=2047，最小=1，最大=2047）

执行 GET stock_by_symbol_leg.to 超时，inst: 1, mgr: Inactive, err: never, queue: 13, qu: 0, qs: 13, qc: 0, wr: 0, wq: 0, in: 0, ar: 0 ，IOCP：（忙碌=3，空闲=997，最小=1，最大=1000），工作人员：（忙碌=3，空闲=2044，最小=1，最大=2047）

执行 GET stock_by_symbol_aapl 超时，inst：1，mgr：不活动，err：从不，队列：13，qu：0，qs：13，qc：0，wr：0，wq：0，in：0，ar：0，IOCP ：（忙=3，空闲=997，最小=1，最大=1000），工人：（忙=3，空闲=2044，最小=1，最大=2047）

超时执行 GET portefoliosBotById_ec030000-0001-1200-0000-000000000000, inst: 1, mgr: Inactive, err: never, queue: 13, qu: 0, qs: 13, qc: 0, wr: 0, wq: 0, in : 0, ar: 0, IOCP: (Busy=3,Free=997,Min=1,Max=1000), WORKER: (Busy=3,Free=2044,Min=1,Max=2047)

我正在使用 StackExchange.Redis 版本 1.1.603 和可用的最小 Azure 实例。我收到很多 GET/SET 超时错误。当我在本地使用我的机器上的 Redis 服务器时，我没有这个问题，这让我倾向于在 Azure 上解决问题。Redis 中存储的信息大约为 2kb 到 10kb。

在 Azure 门户上，我看到我的连接数低于 20，内存使用量在 130meg 左右，cpu 使用率低于 35%，Redis 服务器负载始终低于 13%。我没有从门户中看到任何问题的迹象。

知道在哪里可以获得更多信息来解决这个问题吗？

编辑

自从我的第一篇文章以来，我改进了一些设置。

1）我从 C0 传递到 Azure Redis 的 C1 实例。

2）我将连接字符串更改为 15 秒超时。这是它的外观：

boursexxxxxxx.windows.net:6380,密码=xxxxxxxx,ssl=True,abortConnect=False,connectRetry=5,connectTimeout=15000,synctimeout=15000"

3) 我创建了一个包含 10 个延迟加载 ConnectionMultiplex 的池，我在每次调用时都在轮换。

4）我减少了许多缓存的值。根据序列化的对象，我有：

4.1) 1.25ko (5%)

4.2) 0.154ko (5%)

4.3) 26ko (20%)

4.4) 700ko (这里我们需要努力，但仅限于< 100个条目)

4.5) 5ko (30%)

4.6) 66ko (40%)

我在很多地方都看到过这种推荐，比如：

多个工厂：由同一工厂创建的所有客户端（发送方和接收方）共享一个 TCP 连接。最大消息吞吐量受限于可以通过此 TCP 连接的操作数。单个工厂可以获得的吞吐量随 TCP 往返时间和消息大小的不同而有很大差异。要获得更高的吞吐率，您应该使用多个消息传递工厂。

您可以找到 Redis、RabbitMQ 等的类似建议。我的问题是，一个 TCP 通道怎么会耗尽？我相信单个 TCP 通道没有带宽限制。

那么，为什么人们建议使用多个通道来实现高吞吐量？是不是因为：

1. 如果客户端应用程序向单个 tcp 通道发送大量小消息，则每个操作都会锁定 tcp 套接字然后发送消息。它可能导致锁定争用。如果我们使用多个 tcp 通道，这种争用可以在一定程度上得到解决。

2. 如果在 tcp 通道上发送大消息，则序列化/反序列化并将其推送到通道可能需要一些时间。它可以阻止其他小消息。

这些是实际原因吗（或者如果这些假设是错误的，真正的原因是什么）？

我正在使用带有 .NET 实现的 azure redis 缓存。我有一个需要从缓存中获取的键列表。现在，这是我的实现：`

为了我的解释，我已经简化了一点，但它工作得很好。但是，我想知道是否可以通过将我想要检索的密钥列表传递给批量下载的批处理集来进行类似的设置。通常大约有 200 多个 id。那可行吗？