How to Get a HashSet from Redis Cache?

[gmij]

App A: use Redis, set to Redis with HashSet, key match FusionCache Role. v2:xxx:yyy
App B: use FusionCache to Load v2:xxx:yyy, the Data is null.

use Redis-Insight to Find data. the key has Data.

[jodydonetti]

Hi @gmij you mean that App A is writing to Redis without going through FusionCache?
This does not work, because FusionCache saves in Redis your value + some extra metadata, all packaged inside an envelope. So the "shape" is different.

Long story short: if you want to read from FusionCache, you need to write from FusionCache (so the data is saved in the correct format).

Hope this helps.

[gmij]

ok,,,,,i know.

but....is a bad msg.....

[jodydonetti]

Can you explain more what you mean?

[gmij]

Hi @gmij you mean that App A is writing to Redis without going through FusionCache?你好，你的意思是 App A 在写入 Redis 时没有经过 FusionCache 吗？ This does not work, because FusionCache saves in Redis your value + some extra metadata, all packaged inside an envelope. So the "shape" is different.这行不工作，因为 FusionCache 会将你的值和一些额外的元数据保存到 Redis 中，所有这些都封装在一个信封里。所以“形状”是不同的。

Long story short: if you want to read from FusionCache, you need to write from FusionCache (so the data is saved in the correct format).长话短说：如果你要从 FusionCache 读取，你需要从 FusionCache 写入（这样数据才能以正确的格式保存）。

Hope this helps.  希望这有帮助。

What we hope to do is exactly what you understand.
And the reason why I say this is bad news is because App A is a historical application, and we don't want to reference FusionCache in it, while App B is a new reference that has already used FusionCache. The current issue we are facing is that these two applications need to share the same data, with App A handling Redis changes, while App B is only responsible for using data from Redis.

[jodydonetti]

Got it. I may have something in mind... give some time to bake the idea...

[jodydonetti]

Hi @gmij , I have an update: I'm playing with the idea of implementing something called "distributed cache raw mode", where the idea is that, if you enable it (default is false, so it's opt-in), you can tell FusionCache to just store the raw data in the distributed cache. Anyway I'm still really undecided, because it can be a big change, both to do and to support in the future.

This though will also disable a whole set of FusionCache features (but not all), so it must be used with great care.

Mind you, it's not yet 100% confirmed, and the design it's not set in stone, and I have a lot of cases to check, and etc... but I'm thinking about it.

Would this be interesting for your use case?

Now, more importantly, a couple of questions about your scenario:

And the reason why I say this is bad news is because App A is a historical application, and we don't want to reference FusionCache in it

Just to understand: you cannot or you don't want? And why? I'm trying to understand the use case better, thanks.

while App B is a new reference that has already used FusionCache. The current issue we are facing is that these two applications need to share the same data, with App A handling Redis changes, while App B is only responsible for using data from Redis.

This looks more like using Redis as the database instead of as a distributed cache.

For example, what happens if App B (only responsible for reading from Redis) does not see anything there? Does it have a factory that can grab the real data? If Redis contains the real data, like a database normally does, can this be a case where you can use FusionCache with only L1 (memory cache) and where Redis is used inside the factory as what is normally the database?

What I mean is that the fact that it's Redis does not necessarily mean that it must be used as L2 (distributed cache).

I hope I've been able to explain myself.

Please let me know, thanks.

[gmij]

hi... @jodydonetti

I'm glad to see new progress on this matter. Regarding the several scenarios you mentioned, here's what I think.

Just to understand: you cannot or you don't want? And why? I'm trying to understand the use case better, thanks.

These two applications are maintained by two distinct teams, with one of them believing that direct utilization of Redis suffices, as introducing hybrid caching would unnecessarily elevate complexity. Their application business logic is more intricate, yet their requirements for real-time performance are relatively lower.

This looks more like using Redis as the database instead of as a distributed cache.

The current scenario involves App B exposing a web API for App A to utilize. They load the required data from the database based on business needs and return it to us, with each access taking approximately one second. After discussing with them, they implemented a caching mechanism where the web API optimizes and returns data from the cache. Whenever the data changes, they update the cache to ensure we have access to the latest information. However, they directly manipulate Redis using the HashSet data structure, which hinders our ability to leverage a hybrid cache for loading.

Initially, we hoped that the hybrid cache could accommodate HashSet data structures. Yet, from our previous discussions, we understood that there is additional metadata involved, making it challenging to manage. My suggestion is to separate metadata storage and data storage by placing them in different paths, such as using "v2:data:key" for data and "v2:metadata:key" for metadata. While this approach may increase maintenance costs across different paths, it could provide a clearer distinction and easier management.