我们在 Java servlet 容器中运行的 Web 后端中使用 Hazelcast (2.3) 在集群中分发数据。 Hazelcast 地图使用 MapStore 接口保存在 MySQL 数据库中。现在，我们正在使用 Java 原生客户端接口，我想知道“原生”客户端和嵌入式版本在性能方面有什么区别。
“本机”客户端可能连接到任何集群节点并且针对每个请求再次做出此决定是否正确？
在使用嵌入式版本时，避免在本机客户端通过 TCP 套接字发送所有请求和响应的开销是否正确？
是否可以得出这样的结论：嵌入式版本通常比“本机”客户端更快？
如果是“本地”客户端：MapStore 实现是 Hazelcast 服务器的一部分（作为运行时的类）是否正确？还是它是“本机”客户端的一部分，以便所有必须持久化的数据首先通过 TCP 套接字发送？
【问题讨论】：
标签： hazelcast
您为本地客户端提供连接的节点集。一旦它连接一个，它将使用该节点与集群通信，直到它死亡。当它死亡时，客户端将连接到其他节点以继续通信。
对于本机客户端，有两个跃点，一个从客户端到节点，一个从节点到目标节点。 （目标节点是目标数据所在的节点）对于嵌入式客户端，只有单跳，因为它已经知道所需数据的位置（目标节点）
一般情况下是的，但请参阅：（来自hazelcast documentation）
LiteMember 是集群的成员，它有套接字连接到 集群中的每个成员，它都知道数据在哪里，所以它会 更快地获取数据。但是 LiteMember 有集群 即使在同一个 RAC 上，它也必须位于同一个数据中心。 但是，本机客户端不是成员，并且依赖于集群之一 成员。本机客户端可以位于 LAN 或 WAN 中的任何位置。它可以扩展 好多了，开销也少了很多。因此，如果您的客户较少 比 Hazelcast 节点，那么 LiteMember 可以是一个选项；除此以外 一定要试试 Native Client。经验法则：尝试使用本地客户端 首先，如果它对您来说表现不够好，那么请考虑 LiteMember。
4- 存储操作在 hazelcast 服务器中执行。从客户端发送的对象由目标节点持久化到集中式数据存储区，目标节点也将对象存储在其内存中。
【讨论】：