我应该将内存中的 SQL (Hekaton) 用于队列消息传递系统吗？答案

【问题标题】：Should I use In memory SQL (Hekaton) for queue messaging system?我应该将内存中的 SQL (Hekaton) 用于队列消息传递系统吗？
【发布时间】：2015-12-04 10:44:11
【问题描述】：

我使用的平台具有使用 SQL 服务器表作为队列的消息传递系统。

该系统基于此：Using Tables as queues

ATM 我们面临一些可扩展性问题，因为这种分布式架构主要基于 SQL 锁和磁盘操作，以保证数据的持久性/一致性。

为了解决基于磁盘的 I/O 瓶颈并改善糟糕的分配逻辑，我们正在考虑将基于磁盘的 SQL 表更改为 SQL 2014 和 2016 上可用的内存 SQL (Hekaton)。

我已经阅读了一些关于 Hekaton 的资料，但我仍然不确定这是否是最好的方法，或者是否可以将这些队列实现到内存中以及这是否是最好的方法。

大多数队列都在实现悲观并发，而 Hekaton 仅使用无锁系统乐观并发（基于多版本）。 “总是”（我知道这是一个坏词）是否有可能将悲观并发变为乐观并发？例如在上述队列中。

Hekaton 是否适用于许多插入/删除（入队/出队）、订单行（FIFO 队列）和大量表大小变化（服务器上的工作负载变化会增加/减少队列大小）？是否可以正确更新本机存储过程查询性能的统计信息？

我觉得本机编译的 SQL 存储过程会大大提高性能，但我不确定这种实现（相关的 FIFO 队列）是否适合在 Hekaton 上使用，因为我没有找到任何示例使用 Hekaton 的“内存队列”实现。

【问题讨论】：

标签： sql-server queue message-queue optimistic-concurrency memory-optimized-tables

【解决方案1】：

您可以在 Hekaton 中实现您所描述的内容 - 正如您所提到的，如果交易因同一行上的并发而中止，应用程序将不得不重试。话虽如此，您还必须考虑 SQL 2014 不支持大型二进制对象，您将需要使用 SQL 2016 或像我们为 ASP.NET 会话状态所做的那样解决它：

http://blogs.msdn.com/b/kenkilty/archive/2014/07/03/asp-net-session-state-using-sql-sever-in-memory.aspx

Hekaton 是为 OLTP 设计的，这意味着大量的插入、更新和删除。

提前计划内存需求：

https://msdn.microsoft.com/en-us/library/dn133186.aspx

【讨论】：

我已经使用 Hekaton 实现了 3 种类型的队列。做了一个解决方法来支持超过 8060b 的限制：当消息的有效负载高于限制时，我只在磁盘中存储对表的引用。我认为这会起作用，因为我不会收到很多高于限制的消息，但 2016 年将发布一个具有更高限制的版本。当并发发生时，我还实现了重试逻辑。由于项目处于待机状态，我还不确定我是否从这个实施中获得了很多收益，但我觉得 Hekaton 有很多限制，需要很多变通方法。
我们在 2016 年缩小了很多差距，包括 T-SQL 表面积。我认为你的努力是值得的，我们正在大力投资 Hekaton。我忘了提到你应该尽可能地坚持使用本地编译的程序。此外，上面提到的 ASP.NET 会话状态带有源代码，因此请查看并与您的实现进行比较。