在关键GemFire中，与使用Spring数据存储库相比，使用Spring缓存具有优势

Question

SDG (Spring )是Spring (GemfireCacheManager)和Spring (GemfireTemplate)用于GemFire的库或框架。

使用其中一种比另一种有什么明显的缺陷/优点？

基本的需要将底层数据作为回购工具使用OQL功能，GemfireTemplate可以提供finder methods，它可以充当cache lookup，更像search。

另一方面，spring-cache为基本缓存操作(get/put)提供了开箱即用的能力。如果我们想使用GemfireTemplate来完成这个任务，我们必须编写自定义代码。

对于technically是否有理想的用例使用spring-cache进行GemFire，反之亦然？

Answer 1

“缓存”和“数据访问”模式(CRUD +查询等)实际上是两个不同的关注点。

正如春季医生解释的那样，当给定相同的输入返回相同的输出或结果时，缓存本质上是一种降低调用应用程序服务操作(Spring中的Java“方法”)的成本的方法。

成本可以通过多种不同的方式来衡量，但本质上可以归结为CPU利用率、IO活动(例如磁盘/存储访问)、网络(例如，对远程服务进行REST调用，比如使用谷歌的Maps API、例如等对地址进行地理编码)。

通过在内存中缓存频繁或最近使用的结果，应用程序可以更好地响应。当然，开发人员必须小心，因为s/他正在以使用更多内存(即资源利用率)为代价来交换性能(即延迟)，因此开发人员必须对内存中保存的内容进行更多的选择，这就是为什么缓存通常使用LRU或LFU算法来根据使用维护缓存中最相关的条目。结合其他策略(过期(TTL或TTI)、驱逐、压缩、使用本机内存等)可以有所帮助。此外，开发人员必须记住其他因素，例如处理陈旧的数据，或者在更新时使条目无效等等。

Spring Data GemFire可以位置 (也见这；首选)关键GemFire作为https://docs.spring.io/spring/docs/5.0.2.RELEASE/spring-framework-reference/integration.html#cache中的“缓存提供者”，它使用Spring的OOTB框架实现了忽略模式。例如..。

@Service
class CustomerService {

  Autowired
  CustomerRepository customerRepository;

  @Cacheable("Customers")
  Customer findBy(Long id) {
    ...
    return customerRepository.findBy(id);
  }
}

在本例中，CustomerRepository可能由关系数据库管理系统支持，而GemFire可能是缓存提供程序。

当然，CustomerService类可以对远程服务进行REST调用，这是一种可能代价高昂的操作，因为它涉及网络和HTTP协议。

我在SDG的caching-example参考实现(RI)中就是这样做的。它地理编码物理地址到地理坐标(经度/纬度)以及反地码坐标返回到物理地址.GeocodingRepository (使用 by GeocodingService)是用于地理编码的Google地图API的包装器，它调用REST调用谷歌的Maps API。

显然和地址的地理坐标不改变所有这些频繁，是一个主要的候选缓存。

相反，对于一般数据访问(CRUD + Query，等等)，您可以使用SDG提供的o.s.d.g.GemfireTemplate，或者更好地使用SDG提供的SD仓库抽象和扩展作为底层的“记录系统”(SOR)访问数据存储，而不是作为缓存。因此，在这种情况下，GemFire将是数据库和数据访问模式的适当替代，而不是与数据相关的目标问题相关的缓存。例如：

interface CustomerRepository extends CrudRepository<Customer, Long> {

  List<Customer> findAllByContactEventsTimestampGreaterThanAndAddressCityIn(LocalDateTime timestamp, Collection<String> cities);

}

最酷的是，使用SD的存储库抽象，我可以通过遵循特定的公约 ( 示例 )来表达非常简单或复杂的查询。

无论如何，缓存与存储库是两个不同的东西，甚至可以组合。

希望这能有所帮助！

-John