我在完全理解AMQP.Net使用的“信用”属性时遇到了问题。它的读取方式似乎可以用来防止发送者排队过多的数据。如果我将信用额度设置为较低的值，则当信用计算结束时，“ResponseLink.Closed”事件将触发并且该过程停止。我想做的是设置一个信用卡，以便当接收器不堪重负时，发送方可以暂停以允许接收器稍微赶上然后从它停止的位置再次开始发送。目前，发送方正在排队这么多数据，以致计算机在接收器运行缓慢时耗尽内存。这可能通过使用信用或是否需要使用替代解决方案？
我目前使用AMQP.Net的方式是客户端调用服务器请求发送某种类型的数据。服务器调用数据库并获取非常大的数据列表。然后使用以下命令将此数据从foreach循环发送到客户端：
??客户端通过其末尾的OnMessage事件获取这些内容。由于发送速度比客户端可以处理的速度快，因此内存使用量会快速增长。如何才能在服务器端获得一些反馈，以了解客户端何时处理了n条消息，以便在发送更多消息之前可以暂停？
答案 0 :(得分：1)
此更新更好地描述了您如何使用库以及您遇到的问题。根据您在请求消息中的内容，您可以尝试两种解决方案。
如果您的客户端请求总是有大量数据，则可以切换为使用客户端的单个接收器链接。在侦听器端，您注册链接处理器（ILinkProcessor）并在收到链接附加请求时创建SourceLinkEndpoint。创建链接时，可以在attach.properties中传递特定于请求的数据。您还需要实现IMessageSource接口。该库将在流和确认事件上调用您的方法实现。在GetMessageAsync方法中，您可以查询数据库以获取仅适合一条消息的数据，或者用于填充从中提供GetMessageAsync调用的内存缓存的项列表。传输完所有数据后关闭链接。在此模型中，AMQP链接流控制将在消息传输中进行，您可以完全控制链接可以使用多少内存。
如果您更喜欢请求/响应模型，则需要实现一些分页逻辑以避免侦听器端的高内存消耗。请求/响应模式是使用一对链接在标准AMQP消息传输之上构建的。一个链路中的流控制独立于另一个链路，不能用于协调请求和响应消息的传输。您可以更频繁地发送请求，而不是为每个请求提供固定大小（或数量）的消息，而不是将所有数据提供给一个客户端请求。