4

我想知道我是否可以用这个来请求回复：

  • 1 hazelcast 实例/成员（中心点）
  • 1 个带有 hazelcast-client 的应用程序通过队列发送请求
  • 1 个带有 hazelcast-client 的应用程序等待请求进入队列

第一个应用程序还接收第二个应用程序发布的另一个队列上的响应。

这是继续的好方法吗？还是您想到了更好的解决方案？

谢谢！

4

5 回答 5

3

最近几天，我还研究了一个“类似 soa”的解决方案，它使用 hazelcast 队列在不同机器上的不同进程之间进行通信。

我的主要目标是

  1. “一对多”通信，保证对多对一的回复

  2. “一对一”沟通方式

  3. “一对一”沟通，在一定时间内接听

长话短说，我今天放弃了这种方法，原因如下：

  1. 大量复杂的代码，包括执行器服务、可调用对象、可运行对象、InterruptedException、关闭处理、hazelcast 事务等

  2. 当接收者的生命周期比发送者短时，在“一对一”通信的情况下悬挂消息

  3. 如果我在正确的时间杀死某些集群成员，则会丢失消息

  4. 所有集群成员都必须能够反序列化消息，因为它可以存储在任何地方。因此，对于某些客户端和服务，消息不能是“特定的”。

我改用了一种更简单的方法：

  1. 所有“服务”都使用 hazelcast 集群成员 UUID 作为键在 MultiMap（“服务注册表”）中注册自己。每个条目都包含一些元信息，如服务标识符、负载因子、开始时间、主机、pid 等

  2. 客户端选择该 MultiMap 中的条目之一的 UUID，并为所选的特定集群成员使用 DistributedTask（分布式执行器服务）来调用服务，并可选择（及时）获得回复

  3. 只有服务客户端和服务必须在其类路径中具有特定的 DistributedTask 实现，所有其他集群成员都不会受到打扰

  4. 客户端可以自己轻松地找出服务注册表中的无效条目：如果他们看不到具有特定 UUID (hazelcastInstance.getCluster().getMembers()) 的集群成员，则服务可能会意外死亡。然后客户端可以选择“活动”条目，负载因子较少的条目，在幂等服务的情况下重试等

使用第二种方法（例如超时或取消任务），编程变得非常简单和强大，需要维护的代码更少。

希望这可以帮助！

于 2013-02-14T20:24:17.837 回答
2

过去我们构建了一个使用 Hazelcast 队列作为总线的 SOA 系统。这是一些头条新闻。

一种。每个服务都有一个收入Q。简单来说服务名就是队列的名字。您可以拥有任意数量的服务提供商。您可以放大和缩小。您所需要的只是这些服务提供者来轮询这个队列并处理到达的请求。

湾。由于系统是完全异步的，为了关联请求和响应，请求和响应中还有一个调用 ID。

C。每个客户端将请求发送到它要调用的服务的队列中。该请求包含服务的所有参数、发送响应的队列名称和调用 ID。队列名称可以是客户端的地址。这样每个客户端都将拥有自己独特的队列。

d。收到请求后，服务提供者对其进行处理并将响应发送到应答队列

e. 每个客户端还不断地轮询其输入队列以接收它发送的请求的答案。

这种设计的主要缺点是队列不像地图那样可扩展。因此，它不是非常可扩展的。但是它仍然可以每秒处理 5K 请求。

于 2013-02-09T00:30:58.020 回答
2

我为自己做了一个测试，并验证它在一定限制下运行良好。

架构是 Producer-Hazelcast_node-Consumer(s)

使用两个 Hazelcast 队列，一个用于请求，一个用于响应，我可以测量不到 1 毫秒的往返时间。

如果我放置多个请求队列的消费者，负载平衡工作正常。

如果我添加另一个节点，并将客户端连接到每个节点，那么往返时间超过 15 毫秒。这是由于 2 个 hazelcast 节点之间的复制所致。如果我杀死一个节点，客户端会继续工作。所以故障转移是以时间为代价的。

于 2013-02-11T15:23:12.617 回答
1

您不能使用相关 ID 对 hazelcast 中的单个队列执行请求-回复吗？这是应该唯一定义队列的 2 个提供者/消费者之间的对话的 id。

于 2013-01-21T18:25:52.950 回答
0

此设置@unludo 的目的是什么？我只是好奇

于 2013-02-07T05:50:35.473 回答