Pratique du Shadowing: What Is Redis Really About? Why Is It So Popular? - Apprendre l'anglais à l'oral avec la vidéo
Choisissez un mode d'entraînement
Chaque mode ouvre une salle d'entraînement en plein écran.
159 phrases
Si les phrases sont trop courtes ou trop longues, cliquez sur Edit pour les ajuster.
1
What is Redis?
2
Why does it show up in so many system design problems?
3
And why do so many teams rely on it in production?
4
Redis is versatile.
5
It's worth the time to learn it well.
6
In this video, we focus on three ideas.
7
How Redis executes commands, how it stores and persists data,
8
and how people use it in real systems.
9
Let's start with what Redis is.
10
Redis is a single-threaded, in-memory data structure server.
11
This short description hides three important design choices.
12
First, single thread execution.
13
Redis processes commands one at a time in a single thread.
14
Strictly speaking, Redis 6 and newer added IO threads for networking,
15
but the actual command logic still runs sequentially.
16
The order is predictable.
17
The first request in is the first request processed.
18
There are no logs to reason about and no concurrent writes to the same key.
19
If one command blocks, every other command waits behind it.
20
You might ask, if Redis uses only one thread to run commands,
21
how does it stay fast?
22
Redis hides latency with batching.
23
Clients can bundle commands with pipelining or wrap a set of commands in a transaction.
24
One network roundtrip now carries many commands.
25
The single thread still executes each command in order,
26
but the socket stays busy instead of waiting for each request-response pair.
27
Second, Redis keeps data in RAM.
28
The upside is very low latency.
29
Redis can respond in sub-millisecond time,
30
even when we send hundreds of commands per second.
31
The downside is durability.
32
If the machine dies, the data in memory is gone unless we configure persistence carefully.
33
This trade-off is central to how teams use Redis.
34
We'll come back to this.
35
Third, Redis is a key value store that exposes data structures directly.
36
A value in Redis can be many things.
37
For example, it can be a string,
38
a list, a hash, a set,
39
a sort of set, or a stream.
40
The protocol is small and simple,
41
but Redis provides many specialized commands for each data structure.
42
Here is a simple example of a counter.
43
We call setCounter5 getCounterReturns5.
44
IncrementCounter bumps it atomically to 6.
45
Each command acts on a key.
46
Atomicity matters when multiple clients touch the same key.
47
Because Redis runs commands one at a time,
48
increment completes as a single atomic step.
49
Multiple clients incrementing the same counter won't interfere with each other.
50
Now let's move on to persistent and durability.
51
Since Redis lives in memory,
52
we need to plan for crashes.
53
Different teams make different choices.
54
Many teams run Redis as a pure cache with persistence turned off.
55
The database is the source of truth.
56
Rights go to the database.
57
Redis only stores cached results.
58
If Redis crashes in this setup, we lose the cache.
59
The application rebuilds it on demand by querying the database.
60
No important data is lost because we never treated Redis as the source of truth.
61
Some teams skip this persistence but add replicas.
62
The primary node handles all writes.
63
Replicas handle read traffic.
64
If the primary dies, a replica is promoted to replace it.
65
In this case, we may lose availability for a few seconds during failover,
66
but we preserve most of the cache data in memory on the replicas.
67
This trace this ILOverhead for memory overhead.
68
Each replica roughly doubles the memory footprint.
69
Another option is to enable RDB snapshots.
70
We configure Redis to take a snapshot every few minutes.
71
On restart, Redis loads the snapshot into memory.
72
This allows Redis to come back with warm data instead of an empty cache.
73
We accept losing the writes that happened after the last snapshot.
74
For a cache workload, this is usually a reasonable trade-off because the cache warms up quite quickly.
75
When Redis holds data we cannot afford to lose,
76
we turn on the append-only file.
77
A common configuration is append only yes with append fsync every sec.
78
Redis appends each write to a log on disk.
79
The operating system flushes buffer write to disk roughly once per second.
80
In a crash, we lose at most 1 second of data.
81
We can configure fsync after every command for a stronger durability.
82
But that is much slower and has a big impact on throughput.
83
Most teams avoid that unless the dataset is small and latency is not critical.
84
In practice, the real question is whether Redis should hold critical state at all
85
or whether it should just be used as a cache.
86
Many teams keep critical data in a durable database and rely on Redis mainly for caching and ephemeral state.
87
That covers persistence.
88
Next, let's talk about scaling Redis.
89
Most Most teams start with a single Redis instance.
90
On decent hardware, a single node can handle a large number of operations per second for many workloads.
91
When reads become the bottleneck,
92
the first scaling step is to add replicas.
93
The primary node accepts all writes.
94
Repicas serve read traffic.
95
This increases read throughput, but write throughput is still capped by the primary.
96
When write volume grows too large for a single instance,
97
many teams adopt client-side sharding.
98
We run multiple independent Redis instances.
99
The application hashes each key and picks a Redis node based on the hash.
100
For a static cluster, a simple modular hash works.
101
For dynamic scaling, libraries such as Katama use consistent hashing so that adding or removing a node does not reshuffle all keys.
102
Each node here is independent.
103
There is no cross-node coordination and no distributed protocol between Redis servers.
104
So we treat Redis as a cache,
105
a node failure simply causes cache misses for the subset of keys that live on that node until the cache repopulates.
106
Redis cluster also exists as an option,
107
it provides automatic sharding and failover.
108
But this comes with added complexity.
109
Operating and debugging a Redis cluster setup is also more complex than running independent nodes.
110
Because of this, many teams prefer simple client-side sharding for cache workloads
111
and only adopt Redis cluster when they need its specific guarantees.
112
Now let's review some common Redis workloads.
113
The classic use case is caching.
114
A service checks Redis before hitting the database.
115
If there is a cache hit,
116
we return the value immediately.
117
If there is a cache miss,
118
we query the database, store the result in Redis,
119
and return the response to the client.
120
Over time, the cache fills up.
121
We need a clean up strategy.
122
One approach is to set a time to live on each key.
123
After the TTL expires, the key stops being returned and is cleaned up lazily.
124
Another approach is to configure a memory limit and an eviction policy so that Redis evicts keys,
125
for example the least recently used one, when memory is full.
126
Multiple service instances can share counters through Redis.
127
We use atomic increment commands on keys that represent a user,
128
an IP, or an API token.
129
Combined with TTLs or Lua scripts,
130
we can implement various rate limiting algorithms without adding a separate coordination service.
131
There are many nuances here,
132
so we dedicate an entire video to this topic.
133
Check the link in the description.
134
So far, Redis looks like a fast key value store.
135
The data structure server part becomes powerful when we look at features like SORTASET.
136
Leaderboards are a common example.
137
A SORTASET maintains items order by score.
138
We can insert a player with a score,
139
update the score when it changes,
140
query the top-end players or look up a player's rank.
141
These operations typically run in logarithmic time relative to the size of the set.
142
This pattern generalizes well.
143
You can build trending post lists,
144
most active users, top sellers,
145
and many other top-end ranking problems on top of Sortaset.
146
Let's wrap up.
147
Redis is fast, predictable, and versatile.
148
Single-threaded execution keeps behavior simple to reason about.
149
In-memory storage delivers very low latency.
150
Native data structures such as hashes and Sortasets solve problems that would be clunky to implement in a relational database.
151
Most teams start with a single instance.
152
Ad replicas will read traffic and availability,
153
then use client-side sharding when they need more write throughput.
154
When we understand these trade-offs around execution,
155
persistence, and data structures, Redis fits cleanly into our system designs.
156
Ready to age your next technical interview?
157
Join our community where we offer comprehensive courses on system design,
158
coding, behavioral questions, machine learning, and object-oriented design.
159
more at bitebico.com.
Télécharger l'application
Tout pour parler couramment
Prononciation IAChaque phrase notée
Phonétique (IPA)Maîtrisez chaque son
VocabulaireEnrichissez votre lexique
Jeu de vocabulaireApprenez en jouant
Même chaîne
C13
Proxy vs Reverse Proxy (Real-world Examples)
Daily ConversationUniversity StudentsWorking Adults
C12
Cache Systems Every Developer Should Know
Daily ConversationUniversity StudentsWorking Adults
C12
Top 5 Redis Use Cases
Daily ConversationUniversity Students
C13
Everything You Need to Know About DNS: Crash Course System Design #4
Daily ConversationUniversity StudentsWorking Adults
C12
CAP Theorem Simplified
Daily ConversationUniversity StudentsWorking Adults
C12
What Is REST API? Examples And How To Use It: Crash Course System Design #3
Daily ConversationUniversity StudentsWorking Adults
C18
8 Most Important System Design Concepts You Should Know
Daily ConversationUniversity StudentsWorking Adults
C11
The Secret Sauce Behind NoSQL: LSM Tree
Daily ConversationUniversity StudentsWorking Adults
C11
System Design: Why is Kafka fast?
Business EnglishUniversity StudentsWorking Adults
C16
What Are Microservices Really All About? (And When Not To Use It)
Business EnglishUniversity StudentsWorking Adults
C13
System Design Was HARD - Until You Knew the Trade-Offs
Daily ConversationUniversity StudentsWorking Adults
C13
How Does a URL Shortener Work?
Business EnglishInterview EnglishUniversity Students
C13
System Design: Why is Kafka Popular?
Business EnglishUniversity StudentsWorking Adults
C14
What is API Gateway?
Business EnglishUniversity StudentsWorking Adults
C12
10+ Key Memory & Storage Systems: Crash Course System Design #5
University StudentsWorking Adults
C150
Kubernetes Explained in 6 Minutes | k8s Architecture
Business EnglishUniversity StudentsWorking Adults
B2How Git Works: Explained in 4 Minutes
Business EnglishUniversity StudentsWorking Adults
FOR YOU
Vidéo recommandée
C1231 phrases
Redis Crash Course - the What, Why and How to use Redis as your primary database
Daily ConversationUniversity StudentsWorking Adults
C13
80 phrases
What is clean code? - Uncle Bob
Business EnglishUniversity StudentsWorking Adults
C22
129 phrases
2.2k
Business EnglishUniversity StudentsWorking Adults
C130
26 phrases
Docker in 100 Seconds
American AccentBusiness EnglishUniversity StudentsWorking Adults
C12
108 phrases
Neuroscientist's Guide To 10X Your Focus & Memory | Dr Sahar Yousef | FO559 Raj Shamani
Business EnglishUniversity StudentsWorking Adults
C11
186 phrases
Why Shopify Moved Inventory Reservations from Redis to MySQL
Business EnglishUniversity StudentsWorking Adults
C21
83 phrases
PostgreSQL Architecture Explained: Deep Dive for Beginners
Business EnglishUniversity StudentsWorking Adults
C26
87 phrases
Every NestJS Concept Explained in 9 Minutes
Business EnglishUniversity StudentsWorking Adults
C112
77 phrases
The Most Successful Idea in Computer Science
Business EnglishUniversity StudentsWorking Adults
C12
130 phrases
Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond
Business EnglishUniversity StudentsWorking Adults
Vocabulaire et conseils d’expression pour cette leçon
Cette leçon d’expression orale de niveau C2 s’appuie sur la vidéo « What Is Redis Really About? Why Is It So Popular? ». Les mots qui reviennent le plus souvent : Redis, command, cache, key, teams. Cette vidéo contient 159 phrases et 1411 mots à répéter en shadowing. La partie parlée dure 8:58. Le locuteur parle à un rythme naturel d’environ 157 mots par minute, proche d’une conversation courante. Seuls 70 % des mots font partie des 3 000 mots les plus courants en anglais, le vocabulaire est donc exigeant.
Vocabulaire clé de cette vidéo
Les 15 mots les plus avancés de la vidéo, avec leur prononciation et leur sens :
| Mot | Prononciation | Sens |
|---|---|---|
| cache nom | /kæʃ/ | cache, mémoire cache |
| replica nom | /ˈɹɛplɪkə/ | réplique, copie exacte |
| hash nom | /ˈhæʃ/ | hachis |
| persistence nom | /pəˈsɪst(ə)ns/ | persistance |
| append verbe | /ʌˈpɛnd/ | appendre, suspendre |
| configure verbe | /kənˈfɪɡə(ɹ)/ | configurer |
| latency nom | /ˈleɪ.tən.si/ | latence |
| shard nom | /ˈʃɑːd/ | éclat, tesson |
| snapshot nom | /ˈsnæpʃɒt/ | instantané |
| throughput nom | /ˈθɹuː.pʊt/ | débit |
| workload nom | charge de travail | |
| cluster nom | /ˈklʌstɚ/ | groupe |
| durability nom | /dəɹəˈbɪləti/ | durabilité, résistance |
| query nom | /ˈkwɪɹ.i/ | question |
| versatile adjectif | /ˈvɜː.səˌtaɪl/ | polyvalent |
Les verbes à particule que vous entendrez
| Mot | Prononciation | Sens |
|---|---|---|
| clean up verbe | nettoyer | |
| fill up verbe | remplir | |
| turn off verbe | éteindre | |
| warm up verbe | /ˌwɔː(ɹ)m ˈʌp/ | se réchauffer, se chauffer |
| wrap up verbe | emballer |
Prononciation à surveiller
- Les sons « th »: throughput /ˈθɹuː.pʊt/, logarithmic /ˌlɒɡəˈɹɪðmɪk/, algorithm /ˈælɡəɹɪðm̩/
- Les sons « sh » et « zh »: cache /kæʃ/, hash /ˈhæʃ/, shard /ˈʃɑːd/, snapshot /ˈsnæpʃɒt/, coordination /kəʊˌɔːdɪˈneɪʃən/
- Mots longs — placez bien l’accent: durability /dəɹəˈbɪləti/, predictable /pɹəˈdɪktəbləl/, coordination /kəʊˌɔːdɪˈneɪʃən/, atomicity /ˌætəˈmɪsɪti/, ephemeral /ɛˈfɛ.mə.ɹəl/
Les sons difficiles pour les francophones :
- /h/ — il se souffle, il n’est pas muet: hash /ˈhæʃ/, behavioral /bɪˈheɪvjəɹəl/, overhead /ˈəʊvəˌhɛd/
- /tʃ/ et /dʒ/ — à ne pas adoucir en « ch » et « j »: generalize /ˈd͡ʒɛn.(ə.)ɹə.laɪz/, sequentially /səˈkwɛntʃəli/, modular /ˈmɑd͡ʒəlɚ/, batch /bæt͡ʃ/
- /r/ anglais — langue recourbée, sans frotter la gorge: replica /ˈɹɛplɪkə/, configure /kənˈfɪɡə(ɹ)/, throughput /ˈθɹuː.pʊt/, durability /dəɹəˈbɪləti/, increment /ˈɪŋkɹɪmn̩t/
Comment s’entraîner avec cette vidéo
- Écoutez la vidéo en entier une fois sans parler et notez les mots que vous ne connaissez pas.
- Commencez à la vitesse 0,75×, répétez phrase par phrase, puis revenez à la vitesse normale quand cela devient facile.
- Enregistrez-vous et comparez avec l’original, en faisant attention à des mots comme cache, replica, hash.
Qu'est-ce que la technique du Shadowing ?
Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.