Delete key in underlying cache when calling Delete API about bcache HOT 6 CLOSED

What about delaying the actual removal to when we try to get a deleted key? Or a garbage collector, similar to what redis does? Every x seconds it picks some random keys and if they are expired they get removed, in this case instead of looking for expired keys we'd look for keys marked as deleted.

from bcache.

https://redis.io/commands/expire#appendix-redis-expires

from bcache.

@luisdavim many thanks for the suggestion and the link, i'll definitely look into it.

The way expiration work this way is because my use case actually doesn't need any expiration.

But thinking about it again, bcache will get more usage if it has similar behaviour with other common caches, it might need some API changes, but i think it is worth to do.

from bcache.

my plan for v0.2

key points:

• expiration will be handled by bcache, unlike v0.1 which basically do nothing with expiration
• passive key deletion. No GC-like mechanism at this phase, could be added later if needed
• deletion delay: add delay before actually delete the key, it is used to handle temporary network connection issue, which prevent data syncing between nodes
• specify ttl instead of expirationTimestamp. expiration timestamp in this new mechanism is error prone. (e.g.: use time.Now().Unix() instead of time.Now().UnixNano())

API changes:

• Set(key, val string, ttl int):
  • ttl in seconds with no default value.
  • ttl <=0 make it expired instantly
• Get(key string) (val string, exists bool)
• Delete(key string , deleteDelay int):

DeletionDelay will be added as field of Config for New:

• in seconds
• if deleteDelay <= 0, use default value

Let me know if you have any comments @luisdavim

from bcache.

Note that the underlying cache is LRU cache with max keys, so it won't going to unlimited number of keys

from bcache.

Sounds like a solid plan.

from bcache.