<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Redis on LOCRIAN_V Blog</title>
    <link>https://lv-blog.pages.dev/en/tags/redis/</link>
    <description>Recent content in Redis on LOCRIAN_V Blog</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Tue, 05 May 2026 22:46:44 +0800</lastBuildDate>
    <atom:link href="https://lv-blog.pages.dev/en/tags/redis/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Close Look at Common Caching Strategies</title>
      <link>https://lv-blog.pages.dev/en/posts/programming/backend/redis/common-cache-strategies/</link>
      <pubDate>Tue, 05 May 2026 22:46:44 +0800</pubDate>
      <guid>https://lv-blog.pages.dev/en/posts/programming/backend/redis/common-cache-strategies/</guid>
      <description>&lt;h1 id=&#34;the-three-cache-brothers&#34;&gt;The Three Cache Brothers&lt;/h1&gt;
&lt;h2 id=&#34;cache-penetration&#34;&gt;Cache Penetration&lt;/h2&gt;
&lt;p&gt;What it is: a flood of requests querying data that doesn&amp;rsquo;t exist in the database. The cache has nothing, so it keeps hammering the database.
Prevention:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Cache null values
&lt;ol&gt;
&lt;li&gt;Even when the database finds nothing, put an empty marker in the cache (with a short TTL, e.g. 2 minutes; only after that TTL expires can the database be queried again)&lt;/li&gt;
&lt;li&gt;The next time the same id comes in, it&amp;rsquo;s blocked directly&lt;/li&gt;
&lt;li&gt;Pros: effectively intercepts large numbers of penetration requests&lt;/li&gt;
&lt;li&gt;Cons:
&lt;ol&gt;
&lt;li&gt;A malicious attack with many different non-existent keys fills the cache with useless data and wastes memory&lt;/li&gt;
&lt;li&gt;It delays data consistency; new data has to wait for the cache to expire&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Bloom filter&lt;/strong&gt; (recommended)
&lt;ol&gt;
&lt;li&gt;At startup, put all legitimate ids into the Bloom filter&lt;/li&gt;
&lt;li&gt;If the Bloom filter says no, it really doesn&amp;rsquo;t exist&lt;/li&gt;
&lt;li&gt;Pros:
&lt;ol&gt;
&lt;li&gt;No high-memory-usage risk&lt;/li&gt;
&lt;li&gt;No data-consistency risk&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;li&gt;Cons:
&lt;ol&gt;
&lt;li&gt;There&amp;rsquo;s a tiny false-positive rate&lt;/li&gt;
&lt;li&gt;Insertions and deletions need maintenance; when data updates, the Bloom filter must be updated in sync&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;li&gt;Rate limiting and validation at the interface layer
&lt;ol&gt;
&lt;li&gt;Intercept at the API gateway or Controller layer&lt;/li&gt;
&lt;li&gt;Parameter validation, rate limiting, and degradation&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;li&gt;Mutex-based rebuild
&lt;ol&gt;
&lt;li&gt;A mutex mainly solves cache breakdown (a hot key expiring), but in the cache-empty-object scenario, if there are many concurrent requests for a non-existent key, a lock can be used&lt;/li&gt;
&lt;li&gt;Each access lets one thread query the DB while the others wait&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Big companies&amp;rsquo; practice&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Close Study of Redis&#39;s LFU Memory Eviction Policy</title>
      <link>https://lv-blog.pages.dev/en/posts/programming/redis/redis-memory-eviction-policy-lfu/</link>
      <pubDate>Fri, 19 Jul 2024 13:10:54 +0800</pubDate>
      <guid>https://lv-blog.pages.dev/en/posts/programming/redis/redis-memory-eviction-policy-lfu/</guid>
      <description>&lt;p&gt;Redis&amp;rsquo;s LFU (Least Frequently Used) eviction policy is an &amp;ldquo;upgraded&amp;rdquo; approximate algorithm built on top of LRU. It reuses the same 24-bit &lt;code&gt;lru&lt;/code&gt; field in the object header and, through clever encoding and logarithmic counting, achieves an approximate tracking of access frequency at a tiny memory cost.&lt;/p&gt;
&lt;p&gt;Below we examine it point by point: from the storage structure, to counter increment/decrement, to the eviction decision, to parameter configuration.&lt;/p&gt;
&lt;hr&gt;
&lt;h3 id=&#34;1-the-bit-layout-of-the-24-bit-field&#34;&gt;1. The bit layout of the 24-bit field&lt;/h3&gt;
&lt;p&gt;Every Redis object has an &lt;code&gt;lru&lt;/code&gt; attribute (24 bits). In LFU mode it no longer holds a second-level timestamp but is split into two parts:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
