Salesforce使用Spring Data Redis内存泄漏经验

2021/10/29 19:11:25

本文主要是介绍Salesforce使用Spring Data Redis内存泄漏经验,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

Salesforce负责全渠道库存服务的 Commerce Cloud 团队使用Redis作为远程缓存来存储适合缓存的数据。远程缓存允许我们的多个进程获得缓存数据的同步和单一视图。

使用模式是生命周期较短、缓存命中率高并在实例之间共享的条目。为了与 Redis 交互,我们使用了Spring Data Redis(带有Lettuce),它一直帮助我们在我们的实例之间共享我们的数据条目,并提供一个与 Redis 交互的低代码解决方案。

我们应用程序的后续部署显示出一个奇怪的现象,Redis 上的内存消耗不断增加,而且没有减少的迹象。

随着时间的推移,内存消耗几乎呈线性增长,系统吞吐量增加,但随着时间的推移没有显着的回收。这种情况达到了如此极端,以至于当内存增加并接近 100% 时,需要手动刷新Redis 数据库。以上似乎表明 Redis 条目发生了内存泄漏。

调查

第一个怀疑是 Redis 条目要么没有配置生存时间 (TTL),要么配置了超出预期的 TTL 值。这表明我们用于速率限制的 Redis Repository 实体类没有任何 TTL 配置:

<span style="color:#333333"><span style="background-color:#f5f5f5">@RedisHash(<span style="color:#00bb00">"rate"</span><span style="color:black">)
<strong>public</strong> <strong>class</strong> RateRedisEntry implements Serializable {
    @Id
    <strong>private</strong> String tenantEndpointByBlock; </span><span style="color:#0000aa"><em>// A HTTP end point</em></span><span style="color:black">
    ...
}

</span><span style="color:#0000aa"><em>// CRUD repository.</em></span><span style="color:black">
@Repository
<strong>public</strong> <strong>interface</strong> RateRepository <strong>extends</strong> CrudRepository<RateRedisEntry, String> {}
</span></span></span>

为了验证确实未设置 TTL 的数据,与 Redis 服务器实例建立连接,并使用 Redis 命令 TTL <name entry key> 检查列出的某些条目的 TTL 值。

<span style="color:#333333"><span style="background-color:#f5f5f5">TTL <span style="color:#00bb00">"rate:block_00001"</span><span style="color:black"> 
-1
</span></span></span>

如上所示,有些条目的 TTL 为 -1,表示未过期。虽然这显然是手头问题的嫌疑原因,并且修复它以明确设置 TTL 值以实践良好的软件卫生似乎是前进的方向,但由于相对较少的数量,有人怀疑这是问题的真正原因条目和内存使用。

添加 TTL 后,入口代码如下所示:

<span style="color:#333333"><span style="background-color:#f5f5f5">@RedisHash(<span style="color:#00bb00">"rate"</span><span style="color:black">)
<strong>public</strong> <strong>class</strong> RateRedisEntry implements Serializable {
    @Id
    <strong>private</strong> String tenantEndpointByBlock;

    @TimeToLive
    <strong>private</strong> Integer expirationSeconds;
    ...
}
</span></span></span>

关键问题聚焦到:

<span style="color:#333333"><span style="background-color:#f5f5f5">@RedisHash(<span style="color:#00bb00">"rate"</span><span style="color:black">)
</span></span></span>

为了检查它,我们使用了以下 Redis 命令:

<span style="color:#333333"><span style="background-color:#f5f5f5">KEYS *
1) <span style="color:#00bb00">"rate"</span><span style="color:black">
2) </span><span style="color:#00bb00">"block_00001"</span> </span></span>

如您所见,有两个条目。一个是带有键名的条目“rate:block_00001”和一个带有键“rate”。

额外条目“rate:block_00001”是意料之中的,但另一个条目令人惊讶地发现。随着时间的推移监控系统还表明,与“rate” 密钥相关的内存正在稳步增加。

<span style="color:#333333"><span style="background-color:#f5f5f5">>MEMORY USAGE <span style="color:#00bb00">"rate"</span><span style="color:black">
(integer) 153034
.
.
.
> MEMORY USAGE </span><span style="color:#00bb00">"rate"</span><span style="color:black">
(integer) 153876
.
.
> MEMORY USAGE </span><span style="color:#00bb00">"rate"</span><span style="color:black">
(integer) 163492
</span></span></span>

除了增加内存增长外,“rate”条目上的 TTL为 -1,如下所示:

<span style="color:#333333"><span style="background-color:#f5f5f5">>TTL <span style="color:#00bb00">"rate"</span><span style="color:black">
-1
>TYPE </span><span style="color:#00bb00">"rate"</span><span style="color:black">
set
</span></span></span>

它清楚地指出了最有可能的嫌疑,即其增长没有随着时间的推移而减少的迹象。

那么,这个条目是什么,为什么它会增长?

 

Spring Data Redis 在 Redis 中为每个@RedisHash创建一个 SET 数据类型。SET 的条目充当 CRUD 存储库使用的许多 Spring Data Redis 操作的索引。

例如,SET 条目如下所示:

<span style="color:#333333"><span style="background-color:#f5f5f5">>SMEMBERS <span style="color:#00bb00">"rate"</span><span style="color:black">
1) </span><span style="color:#00bb00">"block_00001"</span><span style="color:black">
2) </span><span style="color:#00bb00">"block_00002"</span><span style="color:black">
3) </span><span style="color:#00bb00">"block_00003"</span><span style="color:black">
...
</span></span></span>

我们决定在 Stack Overflow和Spring Data Redis 的 GitHub 页面上发布我们的情况,请求社区就如何最好地解决这个问题提供一些帮助——要么阻止这个 SET 的增长,要么如何阻止它的创建,如我们真的不需要任何其他索引功能。

在等待社区响应的同时,我们发现启用Spring Data Redis 注释EnableRedisRepositories的属性实际上会使 Spring Data Redis 侦听KEY事件并随着时间的推移在收到KEY 过期事件时清理 Set 。

<span style="color:#333333"><span style="background-color:#f5f5f5">@EnableRedisRepositories( enableKeyspaceEvents 
    = EnableKeyspaceEvents.ON_STARTUP)
</span></span>

启用此设置后,Spring Data Redis 将确保 Set 的内存不会继续增加,并清除过期条目

<span style="color:#333333"><span style="background-color:#f5f5f5"><span style="color:#00bb00">"rate"</span><span style="color:black"> 
</span><span style="color:#00bb00">"rate:block_00001"</span><span style="color:black"> 
</span><span style="color:#00bb00">"rate:block_00001:phantom"</span><span style="color:black"> <--除了基础之外的幻影条目
......
</span></span></span>

创建幻像 Phantom Keys 以便 Spring Data Redis 可以将带有相关数据的RedisKeyExpiredEvent传播到 Spring Framework 的ApplicationEvent订阅者。Phantom(或Shadow)条目比它正在隐藏的条目存活时间更长,因此当 Spring Data Redis 接收到主条目过期事件时,它将从 Shadow 条目中获取值以传播RedisKeyExpiredEvent,该事件将容纳除了密钥之外的过期域对象。

Spring Data Redis 中的以下代码接收幻像Phantom 条目过期并从索引中清除该项目:

<span style="color:#333333"><span style="background-color:#f5f5f5"><strong>static</strong> <strong>class</strong> MappingExpirationListener <strong>extends</strong> KeyExpirationEventMessageListener {

 <strong>private</strong> <strong>final</strong> RedisOperations<?, ?> ops;
 ...
 @Override
 <strong>public</strong> <strong>void</strong> onMessage(Message message, @Nullable byte[] pattern) {
    ...
    RedisKeyExpiredEvent event = <strong>new</strong> RedisKeyExpiredEvent(channel, key, value);
 
    ops.execute((RedisCallback<Void>) connection -> {
        <span style="color:#0000aa"><em>// Removes entry from the Set</em></span><span style="color:black">
        connection.sRem(converter.getConversionService()
            .convert(event.getKeyspace(), byte[].<strong>class</strong>), event.getId());
        ...
    });
 }
..
}
</span></span></span>

这种方法的主要问题是 Spring Data Redis 必须使用过期的事件流并执行清理而产生的额外处理开销。还应该注意的是,由于 Redis Pub/Sub 消息不是持久性的,如果条目在应用程序关闭时过期,则不会处理过期事件,并且这些条目不会从 SET 中清除。

有效地使用 CRUDRepository 意味着为每个条目创建更多的影子/支持条目,从而导致更多的 Redis 服务器数据库内存消耗。如果条目过期时不需要 Spring Boot 应用程序中的过期详细信息,您可以通过对EnableRedisRespositories注释进行以下更改来禁用 Phantom 条目的生成。

<span style="color:#333333"><span style="background-color:#f5f5f5">@EnableRedisRepositories(.. shadowCopy = ShadowCopy.OFF )
</span></span>

上述的最终效果是 Spring Data Redis 将不再创建影子副本,但仍会订阅 Keyspace 事件并清除条目的 SET。传播的 Spring Boot 应用程序事件将只包含 KEY 而不是完整的域对象。

 

有了以上关于性能和额外内存存储的所有发现,我们认为对于我们正在处理的用例,Redis CRUDRepository 和 KEY Space 事件增加的额外开销对我们没有吸引力。出于这个原因,我们决定探索一种更精简的方法。

我们制作了一个概念验证应用程序来测试使用 CrudRepository 或直接使用RedisTemplate公开 Redis 服务器操作的类之间的响应时间差异。通过测试我们观察RedisTemplate到更有利。

通过连续执行 GET 操作五分钟并取完成操作所用时间的平均值来进行比较。我们看到的是,几乎所有使用 CRUDRepository 的 GET 操作都在毫秒范围内,而没有 CRUDRepository 的概念验证主要在纳秒范围内。我们注意到的另一件事是 CRUDRepository 在执行操作时也有更多上升的趋势,增加了执行其操作的延迟。

 

解决方案

根据研究,我们的前进方向如下:

  • Spring Data Redis CrudRepository:启用Redis Repository的key space事件,启用Spring Data Redis清除过期条目的Set类型。这种方法的好处是它是一种低代码解决方案,通过在注解上设置一个值,让 Spring Data Redis 订阅 KEY 过期事件并在后台进行清理。不利的一面是,对于我们的案例,我们从未使用过的东西会额外使用内存,即 SET 索引和 Spring Data Redis 订阅 Keyspace 事件并执行清理所产生的处理开销。
  • 使用RedisTemplate自定义Repository:在不使用CRUD Repository的情况下处理Redis I/O操作,使用RedisTemplate,构建基本需要的操作。好处是它导致只创建我们在 Redis 中需要的数据,即哈希条目,而不是其他工件,如 SET 索引。我们避免了 Spring Data Redis 订阅和处理 Keyspace 事件以进行清理的处理开销。不利的一面是,我们不再利用 Spring Data Redis 的 CRUD 存储库的低代码魔法及其在幕后所做的工作,而是使用代码来完成所有工作。

在考虑了我们所有的发现之后,尤其是围绕概念验证应用程序和我们的系统的指标,以及我们对团队的需求(更多的是关于快速响应时间和低内存使用率)之后,我们采用的方向不是使用CrudRepository,而是使用RedisTemplate与 Redis 服务器交互。由于代码更透明且功能更直接,因此它提供了一种解决方案,其中包含的未知行为要少得多。

我们的代码最终看起来像这样:

<span style="color:#333333"><span style="background-color:#f5f5f5"><strong>public</strong> <strong>class</strong> RateRedisEntry implements Serializable {
   <strong>private</strong> String tenantEndpointByBlock;
   <strong>private</strong> Integer expirationSeconds;
    ...
}
@Bean
<strong>public</strong> RedisTemplate<String, RateRedisEntry> redisTemplate() {
   RedisTemplate<String, RateRedisEntry> template = <strong>new</strong> RedisTemplate<>();
        
   template.setConnectionFactory(getLettuceConnectionFactory());
        
   <strong>return</strong> template;
}
<strong>public</strong> <strong>class</strong> RedisCachedRateRepositoryImpl implements RedisCachedRateRepository {

    <strong>private</strong> <strong>final</strong> RedisTemplate<String, RateRedisEntry> redisTemplate;

    <strong>public</strong> RedisCachedRateRepositoryImpl(RedisTemplate<String, RateRedisEntry> redisTemplate) {
        <strong>this</strong>.redisTemplate = redisTemplate;
    }
    
    <strong>public</strong> Optional<RateRedisEntry> find(String key, Tags tags) {
        <strong>return</strong> Optional.ofNullable(<strong>this</strong>.redisTemplate.opsForValue()
        .get(composeHeader(key)));
    }
    
    <strong>public</strong> <strong>void</strong> put(<strong>final</strong> @NonNull RateRedisEntry rateEntry, Tags tags) {
        <strong>this</strong>.redisTemplate.opsForValue().set(composeHeader(rateEntry.getTenantEndpointByBlock()),
            rateEntry, Duration.ofSeconds(rateEntry.getRedisTTLInSeconds()));
    }

    <strong>private</strong> String composeHeader(String key) {
        <strong>return</strong> String.format(<span style="color:#00bb00">"rate:%s"</span><span style="color:black">, key);
    }
}
</span></span></span>

通过以这种方式使用它,我们直接处理条目,因此不存在存储不需要的索引或结构的风险。

部署我们的解决方案后,我们的内存使用量完全下降并保持稳定,在条目的 TTL 达到 0 后,任何峰值都会下降。

 

结论

Spring Data Redis Crud Operations 的魔力是通过创建额外的数据结构(如用于索引的 SET)来实现的。当项目过期而不启用Spring Data Redis 以侦听 KEY 空间事件时,不会清除这些额外的数据结构。对于条目非常长或条目集易于处理且有限的缓存模式,带有 CrudRepositories 的 Spring Data Redis 为 Redis 的 CRUD 操作提供了低代码解决方案。

但是,对于数据由多个进程缓存和共享的缓存模式,以及条目具有可以缓存它们的较小窗口的缓存模式,避免侦听 KEY 事件并使用RedisTemplate为所需的 CRUD 操作执行 Redis 操作似乎是最佳的。

 

 小编为大家准备一份Spring Data 资料

 

 

 

 

 

 

 

 

 

 

 

需要的扫码免费领取



这篇关于Salesforce使用Spring Data Redis内存泄漏经验的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程