Skip to content

Commit babd679

Browse files
Merge pull request #1587 from redis/DOC-5218-js-csc
DOC-5218 node-js client-side caching docs
2 parents 0873b5c + cfac71a commit babd679

File tree

1 file changed

+145
-0
lines changed

1 file changed

+145
-0
lines changed

content/develop/clients/nodejs/connect.md

Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -128,6 +128,151 @@ await client.destroy();
128128

129129
You can also use discrete parameters and UNIX sockets. Details can be found in the [client configuration guide](https://github.com/redis/node-redis/blob/master/docs/client-configuration.md).
130130

131+
## Connect using client-side caching
132+
133+
Client-side caching is a technique to reduce network traffic between
134+
the client and server, resulting in better performance. See
135+
[Client-side caching introduction]({{< relref "/develop/clients/client-side-caching" >}})
136+
for more information about how client-side caching works and how to use it effectively.
137+
138+
{{< note >}}Client-side caching requires `node-redis` v5.1.0 or later.
139+
To maximize compatibility with all Redis products, client-side caching
140+
is supported by Redis v7.4 or later.
141+
142+
The [Redis server products]({{< relref "/operate" >}}) support
143+
[opt-in/opt-out]({{< relref "/develop/reference/client-side-caching#opt-in-and-opt-out-caching" >}}) mode
144+
and [broadcasting mode]({{< relref "/develop/reference/client-side-caching#broadcasting-mode" >}})
145+
for CSC, but these modes are not currently implemented by `node-redis`.
146+
{{< /note >}}
147+
148+
To enable client-side caching, specify the
149+
[RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}})
150+
protocol and configure the cache with the `clientSideCache` parameter
151+
when you connect. If you want `node-redis` to create the cache for you,
152+
then you can pass a simple configuration object in `clientSideCache`, as
153+
shown below:
154+
155+
```js
156+
const client = createClient({
157+
RESP: 3,
158+
clientSideCache: {
159+
ttl: 0, // Time-to-live in milliseconds (0 = no expiration)
160+
maxEntries: 0, // Maximum entries to store (0 = unlimited)
161+
evictPolicy: "LRU" // Eviction policy: "LRU" or "FIFO"
162+
}
163+
});
164+
```
165+
166+
However, you can get more control over the cache very easily by creating
167+
your own cache object and passing that as `clientSideCache` instead:
168+
169+
```js
170+
import { BasicClientSideCache } from 'redis';
171+
172+
const cache = new BasicClientSideCache({
173+
ttl: 0,
174+
maxEntries: 0,
175+
evictPolicy: "LRU"
176+
});
177+
178+
const client = createClient({
179+
RESP: 3,
180+
clientSideCache: cache
181+
});
182+
```
183+
184+
The main advantage of using your own cache instance is that you can
185+
use its methods to clear all entries, invalidate individual keys,
186+
and gather useful performance statistics:
187+
188+
```js
189+
// Manually invalidate keys
190+
cache.invalidate(key);
191+
192+
// Clear the entire cache
193+
cache.clear();
194+
195+
// Get cache metrics
196+
// `cache.stats()` returns a `CacheStats` object with comprehensive statistics.
197+
const statistics = cache.stats();
198+
199+
// Key metrics:
200+
const hits = statistics.hitCount; // Number of cache hits
201+
const misses = statistics.missCount; // Number of cache misses
202+
const hitRate = statistics.hitRate(); // Cache hit rate (0.0 to 1.0)
203+
204+
// Many other metrics are available on the `statistics` object, e.g.:
205+
// statistics.missRate(), statistics.loadSuccessCount,
206+
// statistics.averageLoadPenalty(), statistics.requestCount()
207+
```
208+
209+
When you have connected, the usual Redis commands will work transparently
210+
with the cache:
211+
212+
```java
213+
client.set("city", "New York");
214+
client.get("city"); // Retrieved from Redis server and cached
215+
client.get("city"); // Retrieved from cache
216+
```
217+
218+
You can see the cache working if you connect to the same Redis database
219+
with [`redis-cli`]({{< relref "/develop/tools/cli" >}}) and run the
220+
[`MONITOR`]({{< relref "/commands/monitor" >}}) command. If you run the
221+
code above but without passing `clientSideCache` during the connection,
222+
you should see the following in the CLI among the output from `MONITOR`:
223+
224+
```
225+
1723109720.268903 [...] "SET" "city" "New York"
226+
1723109720.269681 [...] "GET" "city"
227+
1723109720.270205 [...] "GET" "city"
228+
```
229+
230+
The server responds to both `get("city")` calls.
231+
If you run the code with `clientSideCache` added in again, you will see
232+
233+
```
234+
1723110248.712663 [...] "SET" "city" "New York"
235+
1723110248.713607 [...] "GET" "city"
236+
```
237+
238+
The first `get("city")` call contacted the server, but the second
239+
call was satisfied by the cache.
240+
241+
### Pooled caching
242+
243+
You can also use client-side caching with client pools. Note that the same
244+
cache is shared among all the clients in the same pool. As with the
245+
non-pooled connection, you can let `node-redis` create the cache for you:
246+
247+
```js
248+
const client = createClientPool({RESP: 3}, {
249+
clientSideCache: {
250+
ttl: 0,
251+
maxEntries: 0,
252+
evictPolicy: "LRU"
253+
},
254+
minimum: 5
255+
});
256+
```
257+
258+
If you want to access the cache, provide an instance of
259+
`BasicPooledClientSideCache` instead of `BasicClientSideCache`:
260+
261+
```js
262+
import { BasicPooledClientSideCache } from 'redis';
263+
264+
const cache = new BasicPooledClientSideCache({
265+
ttl: 0,
266+
maxEntries: 0,
267+
evictPolicy: "LRU"
268+
});
269+
270+
const client = createClientPool({RESP: 3}, {
271+
clientSideCache: cache,
272+
minimum: 5
273+
});
274+
```
275+
131276
## Reconnect after disconnection
132277

133278
`node-redis` can attempt to reconnect automatically when

0 commit comments

Comments
 (0)