caching - 将 Hazelcast / Redis 隐藏在 REST 控制器后面是否有点矫枉过正？

Question

我们正在使用内存数据存储，可能是 Hazecast 或 Redis（技术尚未确定），主要是内存数据存储将用作缓存提供程序，但也用作运行某些分析的计算平台。Hazelcast / Redis 提供自己的本地客户端，允许对网格内容进行细粒度操作。将 hazelcast/redis 实例包装在 Jetty 中会暴露一个 rest 接口，并且不为客户端应用程序提供对 Hazelcast/Redis 的直接访问，这会不会有点过头了？例如，REST 控制器的职责是检索条目、应用过滤器并在缓存未命中时从数据库中检索条目。

暴露给应用程序的功能将是只读 + 一些涉及多个键（分析）的作业。

所以基本上客户端应用程序不应该直接更新网格的内容。或者，如果发生这种情况，这将是非常罕见的，并且可能是在任何情况下都将在所选内存解决方案上运行的作业的结果。

Answer 1

这实际上取决于用例。从 Hazelcast 的角度来看，我们看到的许多实现都使用内存解决方案来减少延迟并提高吞吐量。为减少网络跃点的数量付出了很多努力（例如，通过智能客户端功能将请求直接发送到托管数据的集群成员，而不是通过负载平衡器或主节点）。REST 控制器引入了另一个网络跃点，以及额外的处理时间。而且，另一个潜在的故障点。

所以我想说如果低延迟/高吞吐量是主要关注点，我不会引入 REST 层。