如果您使用 Apache Ignite，您可能已经注意到，您可以使用许多不同的客户端连接器。客户端节点、粗客户端、瘦客户端、JDBC 驱动程序、ODBC 驱动程序、REST API…这一切可能会有点令人困惑。
“我需要在我的应用程序中使用哪种类型的客户端？” – 你可能会问自己。
所以，让我打破这个。下面是所有可用的客户端连接器 Apache Ignite 开箱即用，以及一些最佳实践，关于何时应该（或不应该）使用它们。
厚客户端（又名客户端节点）
厚客户端基本上是一个常规 Ignite 节点，在客户端模式下运行。
客户端节点和服务器节点之间的区别是逻辑的，而不是物理的。客户端不参与缓存、计算、服务部署和其他类似活动，但在引擎盖下，它们的工作方式（几乎）与服务器完全相同。这主要意味着客户端节点使用相同的发现和通信机制，这既带来优点，也带来缺点。
优点
- 厚客户端是拓扑的一部分，因此它了解分区配置以及应用于缓存的数据配置技术。每当粗客户端发送读取或更新缓存条目的请求时，它都会直接转到存储此条目的节点 – 从可伸缩性和性能的角度来看，这非常有效。
- 厚客户端提供阿帕奇点火中提供的全套 API。某些功能（例如，近缓存或连续查询）仅在粗客户端中可用。
缺点
与往常一样，高效率和丰富的功能附带价格。
- 首先，一个厚的客户端是相当重的（因此名称） – 在某些情况下，它可能会消耗相当多的CPU和RAM。例如，如果执行 SQL 查询，则客户端实际上用作减少器，从不同的节点累积子结果并进行最终计算。再次 – 这有利于性能，但这也需要更多的 CPU/RAM 电源
瘦客户端
实际上，瘦客户更接近于我们在谈论客户时通常的想法。精简客户端非常轻量，启动与群集中的一个节点的单个 TCP 套接字连接，并通过简单的二进制协议进行通信。它还遵循非常简单的请求-响应模式。
优点
- 瘦客户端消耗最少的资源，从网络通信的角度来看，非常不苛刻。这使得它们非常适合远程应用程序，在 NAT 或防火墙后在群集的数据中心外运行。在资源有限的设备上，它们也能正常工作。IoT 是瘦客户端用例的一个很好的例子。
- 瘦客户端使用的二进制协议与语言和平台无关，这意味着您几乎可以在任何地方运行瘦客户端。目前，Ignite 提供了用 Java、.NET、C++、Python、NodeJS 和 PHP 编写的实现，这些实现已经超过了我们为厚客户端编写的实现。并且很容易将新语言添加到此列表中。
缺点
- 瘦客户端不具有配置感知功能。它通常只连接到群集中的一个节点，该节点用作网关 – 来自客户端的所有请求都通过此服务器节点。这造成了明显的瓶颈。某些实现支持两个或多个节点之间的负载平衡，但即使在这种情况下，可伸缩性也比使用粗客户端更为有限。
- 瘦客户端提供有限的 API。目前，您只能创建/销毁缓存、执行键值操作和 SQL 查询。计算网格和服务网格API 将来可能会添加（贡献是JDBC 和 ODBC 驱动程序
JDBC 和 ODBC 分别是 JVM 和C++兼容语言的标准 SQL API。Ignite 为这些 API 提供了现成的实现：
- https://apacheignite-sql.readme.io/docs/jdbc-driver.
- https://apacheignite-sql.readme.io/docs/odbc-driver。
在体系结构上，它们的工作方式与精简客户端完全一样 – 连接到其中一个节点，并将该节点用作网关。因此，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 查询结果。
选择正确的选项
好的，客户端连接器有几个选项，每个选项都有其各自的优点和缺点
- 如果应用程序部署在运行服务器节点的同一环境中，并且只要应用程序和每个服务器节点（即没有防火墙或 NAT）之间存在完全网络连接，则使用粗客户端。一般来说，厚客户端应该是您的第一选择，因为它们是最有效的，并提供最多的功能。
- 如果应用程序是远程的和/或在资源有限的设备上运行，请使用瘦客户端。这是你的第二个选择。
- 最后，如果应用程序必须使用标准的 JDBC 或 ODBC API（例如，它是一个 BI 工具，如 Tableau），请使用相应的SQL 驱动程序。
就是这样！不再让人困惑了，对吧？我当然希望如此。但是，如果还有什么仍然不清楚，请随时评论下面。