如果您使用 Apache Ignite,您可能已经注意到,您可以使用许多不同的客户端连接器。客户端节点、粗客户端、瘦客户端、JDBC 驱动程序、ODBC 驱动程序、REST API…这一切可能会有点令人困惑。

“我需要在我的应用程序中使用哪种类型的客户端?” – 你可能会问自己。

所以,让我打破这个。下面是所有可用的客户端连接器 Apache Ignite 开箱即用,以及一些最佳实践,关于何时应该(或不应该)使用它们。

厚客户端(又名客户端节点)

厚客户端基本上是一个常规 Ignite 节点,在客户端模式下运行。

客户端节点和服务器节点之间的区别是逻辑的,而不是物理的。客户端不参与缓存、计算、服务部署和其他类似活动,但在引擎盖下,它们的工作方式(几乎)与服务器完全相同。这主要意味着客户端节点使用相同的发现和通信机制,这既带来优点,也带来缺点。

优点

  • 厚客户端是拓扑的一部分,因此它了解分区配置以及应用于缓存的数据配置技术。每当粗客户端发送读取或更新缓存条目的请求时,它都会直接转到存储此条目的节点 – 从可伸缩性和性能的角度来看,这非常有效。
  • 厚客户端提供阿帕奇点火中提供的全套 API。某些功能(例如,近缓存连续查询)仅在粗客户端中可用。

缺点

与往常一样,高效率和丰富的功能附带价格。

  • 首先,一个厚的客户端是相当重的(因此名称) – 在某些情况下,它可能会消耗相当多的CPU和RAM。例如,如果执行 SQL 查询,则客户端实际上用作减少器,从不同的节点累积子结果并进行最终计算。再次 – 这有利于性能,但这也需要更多的 CPU/RAM 电源
  • 其次,要求每个粗客户端与每个服务器节点具有完全连接。此外,由于粗客户端只是常规节点,因此服务器节点可能会启动与客户端节点的 TCP 连接。如果群集和应用程序之间存在防火墙、NAT 或负载平衡器,则使用厚客户端将非常困难甚至不可能。基本上,这意味着在运行服务器节点的同一物理环境中最好使用厚客户端。
  • 最后,请记住,认为客户端仅适用于 JVM 语言、.NET 语言和C++。对于其他平台,您必须使用其他选项。
  • 瘦客户端

    实际上,瘦客户更接近于我们在谈论客户时通常的想法。精简客户端非常轻量,启动与群集中的一个节点的单个 TCP 套接字连接,并通过简单的二进制协议进行通信。它还遵循非常简单的请求-响应模式。

    优点

    • 瘦客户端消耗最少的资源,从网络通信的角度来看,非常不苛刻。这使得它们非常适合远程应用程序,在 NAT 或防火墙后在群集的数据中心外运行。在资源有限的设备上,它们也能正常工作。IoT 是瘦客户端用例的一个很好的例子。
    • 瘦客户端使用的二进制协议与语言和平台无关,这意味着您几乎可以在任何地方运行瘦客户端。目前,Ignite 提供了用 Java、.NET、C++、Python、NodeJS 和 PHP 编写的实现,这些实现已经超过了我们为厚客户端编写的实现。并且很容易将新语言添加到此列表中。

    缺点

    • 瘦客户端不具有配置感知功能。它通常只连接到群集中的一个节点,该节点用作网关 – 来自客户端的所有请求都通过此服务器节点。这造成了明显的瓶颈。某些实现支持两个或多个节点之间的负载平衡,但即使在这种情况下,可伸缩性也比使用粗客户端更为有限。
    • 瘦客户端提供有限的 API。目前,您只能创建/销毁缓存、执行键值操作和 SQL 查询。计算网格和服务网格API 将来可能会添加(贡献是JDBC 和 ODBC 驱动程序

      JDBC 和 ODBC 分别是 JVM 和C++兼容语言的标准 SQL API。Ignite 为这些 API 提供了现成的实现:

      在体系结构上,它们的工作方式与精简客户端完全一样 – 连接到其中一个节点,并将该节点用作网关。因此,SQL 驱动程序与瘦客户端共享优点和缺点。不过,我还想提几个关键的区别。

      优点

      • JDBC 和 ODBC 是行业标准,这意味着提供的驱动程序可以更轻松地与现有的面向SQL 的工具集成。例如,您可以使用它们透明地将 Tableau 或 Pentaho 等 BI 工具连接到 Apache Ignite。

      缺点

      • 此处的限制是显而易见的 – 您从这种类型的客户端连接器获得 SQL API。根据我的经验,如果您想在可扩展性和性能方面充分利用 Apache Ignite,则绝大多数用例需要更多的功能。除非您别无选择,只能使用标准的 JDBC/ODBC,否则我绝对建议查看其他选项。

      REST API

      Apache Ignite 还附带REST API,它允许执行基本操作,如读取或更新缓存条目、执行 SQL 查询、查看某些指标等。

      在其当前实现中,此 API 并不真正适合任何性能敏感目的,因此我通常避免将其用于生产中任何类型的应用程序。

      但是,REST API 有时在开发或测试期间可能很有用, 例如,快速检查特定的条目值或 SQL 查询结果。

      选择正确的选项

      好的,客户端连接器有几个选项,每个选项都有其各自的优点和缺点

      1. 如果应用程序部署在运行服务器节点的同一环境中,并且只要应用程序和每个服务器节点(即没有防火墙或 NAT)之间存在完全网络连接,则使用粗客户端。一般来说,厚客户端应该是您的第一选择,因为它们是最有效的,并提供最多的功能。
      2. 如果应用程序是远程的和/或在资源有限的设备上运行,请使用瘦客户端。这是你的第二个选择。
      3. 最后,如果应用程序必须使用标准的 JDBC 或 ODBC API(例如,它是一个 BI 工具,如 Tableau),请使用相应的SQL 驱动程序

      就是这样!不再让人困惑了,对吧?我当然希望如此。但是,如果还有什么仍然不清楚,请随时评论下面。

    Comments are closed.