How to improve redis cache hit rate

Introduction to cache hit rate

Hit: The required data can be obtained directly through the cache.

Missed: The desired data cannot be obtained directly through the cache, and you need to query the database again or perform other operations. The reason could be that it simply doesn't exist in the cache, or that the cache has expired.

Generally speaking, the higher the cache hit rate, the higher the benefits of using the cache, the better the application performance (the shorter the response time, the higher the throughput), and the stronger the ability to resist concurrency.

It can be seen that in high-concurrency Internet systems, cache hit rate is a crucial indicator.

How to monitor the cache hit rate

In memcached, run the state command to view the status information of the memcached service, where cmd_get represents the total number of get, get_hits represents the total number of hits, hit rate = get_hits/cmd_get.

Of course, we can also monitor the entire memcached cluster through some open source third-party tools, and the display will be more intuitive. Typical ones include: zabbix, MemAdmin, etc.

As shown in the figure: MemAdmin’s monitoring statistics of the hit rate of the memcached service

Similarly, you can run info in redis Use the command to view the status information of the redis service, where keyspace_hits is the total number of hits, keyspace_misses is the total number of misses, and hit rate = keyspace_hits/(keyspace_hits keyspace_misses).

The open source tool Redis-star can visualize redis service-related information in a chart. At the same time, zabbix also provides related plug-ins to monitor redis services.

Several factors that affect cache hit rate

In the previous chapter, we mentioned the importance of cache hit rate. Let’s analyze several factors that affect cache hit rate.

1. Business Scenarios and Business Requirements

Cache is suitable for business scenarios with "more reading and less writing". On the contrary, the significance of using cache is actually not great. The hit rate will be very low.

Business needs determine the timeliness requirements, which directly affects the cache expiration time and update strategy. The lower the timeliness requirement, the more suitable it is for caching. In the case of the same key and the same number of requests, the longer the cache time, the higher the hit rate will be.

Cache is very suitable for most business scenarios of Internet applications.

1. Cache design (granularity and strategy)

Generally, the smaller the cache granularity, the higher the hit rate. Let's give a practical example:

When caching a single object (for example: a single user information), we only need to update the cache or remove the cache when the data corresponding to the object changes. When caching a collection (for example: all user data), when the data corresponding to any object changes, the cache needs to be updated or removed.

There is another situation, assuming that other places also need to obtain the data corresponding to the object (for example, other places also need to obtain individual user information), if the cache is a single object, you can directly hit the cache. Otherwise, it cannot hit directly. This is more flexible and the cache hit rate will be higher.

In addition, the cache update/expiration policy also directly affects the cache hit rate. When the data changes, directly updating the cached value will have a higher hit rate than removing the cache (or letting the cache expire). Of course, the system complexity will also be higher.

1. Cache capacity and infrastructure

The cache capacity is limited, which can easily cause cache failure and elimination (most cache frameworks or middleware currently use the LRU algorithm ). At the same time, the selection of caching technology is also crucial. For example, using a local cache built into the application is more likely to cause a single-machine bottleneck, while using a distributed cache is easy to expand. Therefore, it is necessary to plan the system capacity and consider whether it is scalable. In addition, the efficiency and stability of different caching frameworks or middleware are also different.

1. Other factors

When a cache node fails, it is necessary to avoid cache invalidation and minimize the impact. This special situation also needs to be considered by the architect. A typical approach in the industry is to use a consistent Hash algorithm or node redundancy.

Some friends may have this misunderstanding: Since the business needs have high requirements on data timeliness, and the cache time will affect the cache hit rate, then the system should not use cache . In fact, this ignores an important factor-concurrency. Generally speaking, under the same cache time and key, the higher the concurrency, the higher the cache revenue will be, even if the cache time is short.

Methods to improve cache hit rate

From an architect's perspective, the application needs to obtain data directly through the cache as much as possible and avoid cache invalidation. This also tests the architect's ability. It requires comprehensive consideration and trade-offs in various aspects such as business requirements, cache granularity, cache strategy, and technology selection. Try to focus as much as possible on hot services that are accessed frequently and have low timeliness requirements, and improve the hit rate through cache preloading (warming), increasing storage capacity, adjusting cache granularity, and updating cache.

For applications with high timeliness (or limited cache space), large content span (or very random access), and low access volume, the cache hit rate may be very low for a long time. The cache has expired before it has even been accessed.

For more Redis-related technical articles, please visit the Redis Tutorial## column to learn!

The above is the detailed content of How to improve redis cache hit rate. For more information, please follow other related articles on the PHP Chinese website!