Java 使用具有LMAX干扰器的Hazelcast映射-性能影响

我们需要运行order manager应用程序的活动实例以实现弹性。在我们的团队中，Hazelcast是跨弹性实例共享状态的首选分布式缓存

在应用程序中，我使用单编写器模式和LMAX中断器库。所以基本上我有一个繁忙的主线程，它从disruptor环形缓冲区读取传入的订单事件，并在不涉及任何阻塞操作的情况下快速处理它

现在唯一的问题是，只要我的主线程接收到一个事件，它就会首先在Hazelcast分布式映射中执行查找，以获取当前订单的状态，而Hazelcast查找是一个相对缓慢的操作~5-10毫秒。我想了解：

1如果这仍然是一件可以接受的事情，即使用LMAX disruptor时从分布式地图读取数据

另外，由于Hazelcast调用是线程安全的，涉及分布式锁，并且LMAX人员建议避免主业务线程中与线程相关的锁，以便CPU优化的代码缓存保持热状态，因此调用Hazelcast是否是LMAX Disruptor主处理线程的反模式

---

有人能在这上面加上2美分吗？

当然，我认为这是不可接受的。IMap不仅无限期地阻塞，还进行网络调用

我认为一个办法是

或者将IMap访问拆分为另一个线程并进行通信 它在单独的环形缓冲区中使用异步事件 或者订阅IMap条目侦听器并将数据存储在内存中（如果合适）。

---

谢谢我正在考虑将对IMap的调用移动到一个单独的线程中，将获取的订单和传入的事件包装在一个消息中，并将其发送到我的主线程读取的环形缓冲区。但问题在于写作。当主线程处理完事件后，它必须更新IMap中订单的共享状态。因此，写入必须是同步的，以确保其他实例可以看到订单的最新状态。否则，如果下一个实例碰巧处理了相应订单的下一个事件，它可以找到stale order obj.@saurabh.in。我不确定我是否理解正确，但奇怪的是，为什么要通过多个实例处理同一订单。如果一个实例将处理给定顺序的所有事件，则更容易。您可以使用分区来实现可伸缩性。这是一个要求还是一个特殊的设计？是的，这是一个很好的观点。在订单管理器的一端，我们有kafka代理，因此我确实确保同一个实例使用kafka分区获取特定订单id的所有事件。另一方面，存在使用不同连接详细信息的并发websocket连接，每个活动实例一个连接不是我个人的偏好。所以在这方面，我无法控制哪个实例得到它。我可以在IMap中维护orde id->instance，以确保同一个实例得到它，但这会在系统中添加另一个状态。@saurabh.in我仍然不确定您的体系结构是什么。对于活动，您应该使用一些复制和领导选择工作流。阿飞·卡夫卡是开箱即用的。不确定Hazelcast是如何参与的，为什么订单流甚至需要它，以及它的角色是什么。订单管理器应用程序一端通过kafka连接到内部系统，因此我们可以从消息路由等方面获得好处。但另一端使用websocket连接连接到供应商服务器-每个活动实例一个连接。来自供应商的任何事件都会复制到所有活动实例。所以我使用hazelcast来决定哪个实例可以处理这个事件。此外，订单上下文事件后处理存储在hazelcast中，以便任何实例都可以获取它。但我明白你避免hazelcast存储订单ctx的意义。Hi@saurabh.in你能在hazelcast分布式地图上实现disruptor吗？Hi@user3203030，是的。的确但是，我只能将事件处理速度提高到每txn 2-3毫秒。正如我在上面的问题中所猜测的，Hazelcast现在是DB的拦截器，但当它成为瓶颈时，我停止在DB中存储。我们可以通过Kafka分区完全摆脱Hazelcast集群。但是，我们需要一个组件将供应商消息定向到主题内的特定Kafka分区，然后我的组件的每个弹性实例都可以连接到Kafka主题的特定分区。Kafka分区还支持粘性连接。Wow@saurabh.in您能否共享在分布式hazelcast对象（如map或queue）上运行的disruptor示例代码片段。将对用户3203030非常有用，要明确的是，干扰器和hazelcast集群没有直接关系。我在接收事件的入口点使用hazelcast作为通用分布式缓存，以决定哪个弹性实例应该处理它。这是一个阻塞操作，每个事件可能需要1到5毫秒！ . 我使用hazelcast分布式锁尝试从具有相同事件密钥的所有实例写入hazelcast映射，并且允许能够插入数据的实例继续执行事件。LMAX干扰器与hazelcast缓存无关。