Skip to main content

Posts

Showing posts with the label redis

Storing Request Statistics Using Redis

If we build a backend service, we probably need to keep any statistics related to our service such as number of requests, average time for processing, number of errors, etc. We may also need to have statistic records in several time precisions for example hourly and daily. The simplest solution, we can just store any information into a table in our database, then calculate the summary when needed or by a request. But, it will cost our system storage and computing resources. Unlike relational databases or NoSQL that only have CRUD operations in general, Redis operations are related to the type of data that is stored. For example, a list will have push or pop operations, a sorted set will have a ranking, incrementing, or union operation, and so on. For instance for storing request statistics in Redis, we will store statistics of the response time of a backend application. The metrics are minimum time , maximum time , number of responses , and total response time . The last two metrics ...

Securing Redis to Be Accessed From All Interfaces

Redis can bind to all interfaces with bind * -::* configuration. But, Redis also enables protected-mode by default in its configuration file. It will make bind * -::* configuration ineffective because the protected-mode requires both to explicitly state the binding interfaces and to define user authentication. The unsecured way is to set protected-mode no in the configuration. It will make our Redis server becomes accessible from any interfaces without authentication. It may be fine if we deploy our Redis server in a closed environment such as in a containerized one without exposing and pointing any port to the Redis service port. So that, the service can only be accessible from other services in the container's network. The recommended way is to keep protected-mode yes in the configuration. Then, we need to add a new user authentication configuration and limiting access for the default user. A default user is a user with no assigned name when the client tries to connect ...

Persisting Data and Replication in Redis

As we know, Redis is an in-memory key-value store database. If our data is stored in our host memory (RAM), how can we restore all values from the last state of our system in case of system reboot or power outages? Redis provides two options for persisting our data. The first is by creating a snapshot and the second is by appending each write action into a file. The second is also called the append-only-file (AOF) method. Applying those options is as trivial as updating several lines of the Redis configuration file. Redis performs snapshotting with certain rules by default. Enabling the auto-snapshot method with different rules is done by configuring the following lines in the /etc/redis/redis.conf file. save 300 10 save 30 1000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /var/lib/redis The line save 300 10 means snapshot will be automatically updated in the background if at least 10 writes have occurred within 300 seconds. The li...