learning-redis

Source Webpage
Source Code

Chapter 01 - Introduction

Lecture 001 - Welcome

Lecture 002 - Course prerequisites

Lecture 003 - Using the exercise files

Chapter 02 - Setting Up

Lecture 001 - Install Redis

Msc install via docker
  • Refer: https://hub.docker.com/_/redis/
  • Cmd: docker pull redis
  • Cmd: docker run --name rdb -p 6379:6379 -d redis
  • Cmd: docker exec -it rdb redis-cli

Lecture 002 - Setting up Redis with ioredis

Npm init
The generated file
Install some dev dependencies
  • Cmd: npm i --save-dev babel-cli babel-preset-env babel-preset-stage-0
Install dependencies
  • Cmd: npm i ioredis nodemon
  • And make "start" cmd: nodemon ./index.js --exec babel-node -e js
Make a .babelrc file
Make index.js file
  • We set the "name" key for a value
  • And run node app: "npm run start", we can see the name logged in the console
Test
  • The "name" have value

Lecture 003 - Overview of the client tools

Reference for redis client implementation
Here is for nodejs
  • Click on the link, it will navigate to github repository

Chapter 03 - Introduction to Redis Basics

Lecture 001 - Introduction to Redis

About redis

Lecture 002 - Data types available

Data types available

Lecture 003 - Redis persistence explained

Redis persistence explained
  • Refer: https://redis.io/topics/persistence
  • 1. Aof,rdb is a mechanism for two types of redis persistence. For the recovery of Redis after crash.
  • 1.1 The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
  • 1.2 The AOF persistence logs every write operation received by the server
  • 2. RDB advantages
  • 2.1 RDB is a very compact single-file point-in-time representation of your Redis data. RDB files are perfect for backups.
  • 2.2 RDB is very good for disaster recovery
  • 2.3 RDB maximizes Redis performances since the only work the Redis parent process needs to do in order to persist is forking a child that will do all the rest. The parent instance will never perform disk I/O or alike.
  • 2.4 RDB allows faster restarts with big datasets compared to AOF.
  • 3. RDB disadvantages
  • 3.1 RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage).
  • 3.2 RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big.
  • 4. AOF advantages
  • 4.1 Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query. With the default policy of fsync every second write performances are still great (fsync is performed using a background thread and the main thread will try hard to perform writes when no fsync is in progress.) but you can only lose one second worth of writes.
  • 4.2 The AOF log is an append only log, so there are no seeks, nor corruption problems if there is a power outage. Even if the log ends with an half-written command for some reason (disk full or other reasons) the redis-check-aof tool is able to fix it easily.
  • 4.3 Redis is able to automatically rewrite the AOF in background when it gets too big. The rewrite is completely safe as while Redis continues appending to the old file, a completely new one is produced with the minimal set of operations needed to create the current data set, and once this second file is ready Redis switches the two and starts appending to the new one.
  • 4.4 AOF contains a log of all the operations one after the other in an easy to understand and parse format. You can even easily export an AOF file. For instance even if you flushed everything for an error using a FLUSHALL command, if no rewrite of the log was performed in the meantime you can still save your data set just stopping the server, removing the latest command, and restarting Redis again.
  • 5. AOF disadvantages
  • 5.1 AOF files are usually bigger than the equivalent RDB files for the same dataset.
  • 5.2 AOF can be slower than RDB depending on the exact fsync policy. In general with fsync set to every second performance is still very high, and with fsync disabled it should be exactly as fast as RDB even under high load. Still RDB is able to provide more guarantees about the maximum latency even in the case of an huge write load.
  • 5.3 In the past we experienced rare bugs in specific commands (for instance there was one involving blocking commands like BRPOPLPUSH) causing the AOF produced to not reproduce exactly the same dataset on reloading. These bugs are rare and we have tests in the test suite creating random complex datasets automatically and reloading them to check everything is fine. However, these kind of bugs are almost impossible with RDB persistence. To make this point more clear: the Redis AOF works by incrementally updating an existing state, like MySQL or MongoDB does, while the RDB snapshotting creates everything from scratch again and again, that is conceptually more robust. However - 1) It should be noted that every time the AOF is rewritten by Redis it is recreated from scratch starting from the actual data contained in the data set, making resistance to bugs stronger compared to an always appending AOF file (or one rewritten reading the old AOF instead of reading the data in memory). 2) We have never had a single report from users about an AOF corruption that was detected in the real world.
  • 6. Ok, so what should I use?
  • 6.1 The general indication is that you should use both persistence methods if you want a degree of data safety comparable to what PostgreSQL can provide you.
  • 6.2 If you care a lot about your data, but still can live with a few minutes of data loss in case of disasters, you can simply use RDB alone.
  • 6.3 There are many users using AOF alone, but we discourage it since to have an RDB snapshot from time to time is a great idea for doing database backups, for faster restarts, and in the event of bugs in the AOF engine.
  • Note: for all these reasons we'll likely end up unifying AOF and RDB into a single persistence model in the future (long term plan).

Lecture 004 - Setting up persistence

Redis.conf file
  • Here the default, we have, "save 900 1" means after 900 seconds if has 1 change, redis will make a snapshot
  • And "save 300 10"
  • We can put as many like this as we can
Redis.conf file - aof
  • By default aof option is disable
  • Let change it to "yes" and restart redis
Restart redis
  • With specify the conf file
The appendonly.aof file
  • This is just generated, it store transaction info

Lecture 005 - Setting up replication

Redis2.conf file - port
  • Let clone from redis.conf
  • Change the port to 6380
Redis2.conf file - slaveof
  • Main server is 127.0.0.1 with port 6379
Redis2.conf file - appendfilename
Start the second one
  • Let restart the first one (redis.conf, master)
  • We start with redis2.conf
We can see the log mention sync two instances
See the log on master
  • We can see it recognise the slave
Test
  • Set country usa
Test - master node
  • The last line mention that sync is OK
  • 07206test - slave node
  • The last line mention the sucessful

Lecture 006 - Redis further configuration

The password
  • Here is the master node
Mention the master node password
Need the password to execute the command
Pass the password in nodejs

Chapter 04 - Datasets in Depth

Lecture 001 - Exploration of strings

Incr and incrby and decr
Getset
  • Get first, then set
Multiple key-value
  • With mget, mset
Exists and del
Expiration

Lecture 002 - Strings in action

Set with expiration
  • Oredis cmd very strain forward with redis command
Mget mset
  • Note that the address incr two times, so the last value is 1053

Lecture 003 - The hash data structure

Reference
Hash data
  • Similar with normal cmds, just with prefix "h"

Lecture 004 - Hashes in action

Copy code to a module
  • Name Strings
  • Stay on strings.js
  • Note that at the end we need a line: export default Strings;
Import Strings and try to run
  • It's OK
Make a module Hashes
  • Implement it
  • Use it in index.js
  • See the console, it works

Lecture 005 - Exploration of lists

List basic cmds
  • Lpush: left push
  • Rpush: right push

Lecture 006 - Lists in action

List in nodejs oredis
Appeding
  • Note that the second run, redis append the data into the previous one
  • Here with the second run, we can see two "mecury" in the list

Lecture 007 - Challenge_ Implement ioredis

Set cmds
  • Sadd
  • Smembers
  • Sismember
  • Sadd tags:react. means we make a sublist (react) from set (tags)
  • Sunionstore
Set cmds
  • Pop and scard

Lecture 008 - Solution_ Implement ioredis

Set in action
The console

Lecture 009 - Challenge_ Explore sorted sets

Sorted sets cmds
  • Zrevrange means reverse
  • -inf means information
  • Zrank returns index of the given value

Lecture 010 - Solution_ Explore sorted sets

Sorted sets cmds in action

Chapter 05 - Advanced Concepts

Lecture 001 - Security with Redis

Lecture 002 - Publish and subscribe with Redis

Subscribe
Publish some msgs
Received msg
Publish to chanel has no subcribed yet
  • Redis returns 0

Lecture 003 - Redis cluster and Sentinel

About sentinel
About redis cluster

Chapter 06 - Conclusion

Lecture 001 - Next steps

Next step