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

Question

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

向应用程序公开的功能将是只读的 + 一些涉及多个键的作业(分析)。

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

Answer 1

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

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