Design method of Cache subsystem

How the cache subsystem is designed (cachable tag, memcache/redis support, XML config support, lru/lfu/local cache hit)

You must be familiar with this code:

Public list<userinfo> searchusers (string userName)
        {
            string cachekey=string. Format ("searchusers_{0}", 

userName);
            list<userinfo>  users = cache. Find (CacheKey) as 

list<userinfo>;
            if (users = null)
            {
                users = repository. Getusersbyusername (userName);
                Cache. Set (CacheKey, users);
            return users;
        }
    
Class Httpruntimecache
    {Public
        object Find (String key)
        {return
            httpruntime.cache[key];
        }
        public void Set (string key, object value)
        {
            Httpruntime.cache[key] = value;
        }
    }

This leads to the following issues:

Many unrelated cache codes are introduced into the business logic function, which causes the DDD model to be not pure

It is inconvenient to replace the cache provider

Adding cache redundancy mechanism is inconvenient

There's no way to use multiple caching systems at the same time

The cache large object has an exception, such as Memcache with a value limit of 1 m

There are a number of problems, so we need to introduce a caching subsystem to solve the above problems, the benefits:

DDD Model More Pure

The specific cache implementation mechanism can be very flexible, such as Httpruntimecache, Memcache, Redis can be used at the same time

Added cache redundancy mechanism, not because of a certain memcache or redis down machine cause the system is slow, in fact, the system will remain very fast (unless backup also down the situation)

Developers are more committed to the core business, not distracted

Cache location transparency, which is configured in the XML configuration file

solution, to use the technology of these 2 articles: C # agent Application-cachable and chat memcached applications.

The main ideas are divided into 2:

Model side: Embedding AOP methods through proxies to determine whether caching is needed, and caching value directly returns value; The write of cache value is written through an AOP post method, so there is no need to write code in business functions, and of course it supports code invocation.

Cache Core object: This object is to solve the consistent hash algorithm, cache value large object decomposition function, redundancy mechanism

The agent embedding AOP method, has already explained in this article the C # Proxy application-cachable, has the interest to look, here does not say, we will mainly look Cachecoordinator object's realization

The structure diagram is as follows: