Heycache2 cache, no storage engine, just glue.

Design Philosophy:

 

* In essence, this is something that is used to bond various cache engines and adds some small advanced features that are not implemented by yourself,
* Only package various current cache structures and implement some practical features to ensure compatibility
*
* Deterministic features: cache reference mechanism and distributed expiration notification mechanism
*
* Uncertain features: Remote dependency, multi-level buffer mechanism,
*
* Completed features: basic functions, reference mechanism, distribution expiration notification,
*
* Unfinished features: Multi-Level buffer mechanism, independent of any Cache Engine validity check
*
* -- Feature introduction --
*
* Distribution expiration notification: a large part of the cached data has a much larger read ratio than the write ratio, that is, the so-called high hit rate. In this way, we hope, directly buffer the processes on each local node to reduce
* Communication costs during read operations increase the response speed. During write operations, each local node sends a notification to the Central Notification Server and then distributes the notification to each node, make it invalid, leading to the cache
* Reload to synchronize the cache versions of each node.
*
* Multi-level cache: A New Concept is that when the data of a key is set to cache, it is not actually cached. Just find a place to store the key and its set and get times, SET it to the File Cache for 2nd times,
* SET to memory or remote memcached for 3rd Times, which can effectively improve the cache hit rate and solve the low hit rate problem caused by full-site scanning by search engines.
*
* No dependency on any Cache Engine validity check: For file caching, you can pack and store the cache, read and unpack it, Verify validity, and so on, and finally determine whether the cache is valid by logic, whether to delete or return.
*
* Reference Mechanism: some caches have the same content, but multiple keys are required. The main goal is to solve this problem.
*
* Remote dependency: with distributed notification, this feature is somewhat flawed. The original goal was to create a local TABLE to store the cached KEY and dependency conditions. When the condition is triggered, the remote server is notified,
* The node may be further notified that the cache is invalid.
*

 

This is basically the case, code open source, BSD, http://code.google.com/p/heycacher2/

 

It is still a basic version that will be continuously improved and implemented, but it has already passed the basic stress test. If you are interested, you can join us and make a fortune.