Five considerations for using Redis (naming)

Original: Five Considerations for using Redis

The following is a question from a question on Quora, which is five questions to avoid with Redis. The answer, which goes beyond the five-question category, describes five considerations for using Redis. If you are using or considering using Redis, you may be able to learn some of the following suggestions to avoid the problems mentioned.

1. Use the key value prefix to make a namespace

While Redis supports multiple databases (the default is 32, you can configure more), other than the default No. 0 library, everything else needs to be used with an extra request. So it might be wiser to use a prefix as a namespace.

In addition, when using the prefix as a namespace partition different key, it is best to use the global configuration in the program to implement, directly in the code to write the prefix is strictly avoided, so maintainability is too poor.

2. Create a key similar to "registry" to mark the use of key

In order to better manage the use of your key value, such as which type of key value belongs to which business, you usually create a document in the internal wiki or somewhere, and by querying this document, we can know what the key in Redis is all about.

In conjunction with this, a recommended practice is to save a registry value in Redis, the name of which can be similar to __key_registry__, the key corresponding to the value of your document location, so that when we use Redis, You can get to the current Redis usage by querying this value directly.

3. Beware of garbage collection

Redis is an in-memory database that provides persistence, and if you do not specify the expiry time of the face value and do not perform regular cleanup, your Redis memory will become more and more expensive, and when one day it exceeds the available memory of the system, the swap is not far from the performance steep drop. So when you're saving data in Redis, it's important to think about the life cycle of your data beforehand, and there are many ways to do it.

For example, you can set the expiration time for your data using Redis's own expiration time. But there is a problem with auto-expiration, which is likely to cause you to have a lot of memory available, let the key expire to free memory, or the memory is not enough key has not expired.

If you want more precise control over your data expiration, you can use a zset to maintain the extent of your data update, you can use timestamps as score value, update the score every time the update operation, so you get a sort of sequence string by update time, you can easily find the oldest data, and delete it from the oldest data until you have enough space.

4. Design your sharding mechanism

Redis does not currently support sharding, but when you have more data than single-machine memory, you have to consider sharding (note: Slave is not used for sharding operations, just a backup and read/write separation of data).

So you might want to consider the problem of fragmentation after a large amount of data, for example, you can set the consistency hash mechanism on the program when there is only one machine, although all the data is initially hashed to a machine, but when you have more and more machines, you just need to migrate a small amount of data to complete.

5. Don't have a hammer, look at all the nails.

When you use Redis to build your service, it's important to remember that you've just found the right tool to implement the functionality you need. Rather than saying that you're building a service with Redis, it's very different, you're using Redis as one of your many tools, just use it when it's appropriate, and choose other methods when it's inappropriate.

Source: www.quora.com

Five considerations for using Redis (naming)