Skip to main content

Cache Policy

Cache policies determine how data is stored and retrieved from a cache, which is a small and fast storage area that holds frequently accessed data to reduce the latency of accessing that data from a slower, larger, and more distant storage location, such as main memory or disk. Different cache policies are designed to optimize various aspects of cache performance, including hit rate, latency, and consistency. Here are some common types of cache policies:


Least Recently Used (LRU):


LRU is a commonly used cache replacement policy.

It evicts the least recently accessed item when the cache is full.

LRU keeps track of the order in which items were accessed and removes the item that has not been accessed for the longest time.

First-In-First-Out (FIFO):


FIFO is a simple cache replacement policy.

It removes the oldest item from the cache when new data needs to be stored, regardless of how frequently the items have been accessed.

Most Recently Used (MRU):


MRU removes the most recently accessed item when the cache is full.

This policy is the opposite of LRU, and it removes the item that has been accessed most recently.

Random Replacement:


This policy selects a random item to evict when the cache is full.

While simple, it doesn't consider the access history of the items in the cache.

Least Frequently Used (LFU):


LFU keeps track of how often items are accessed and removes the item with the lowest access frequency when the cache is full.

It may require additional data structures to maintain access counts for each item.

Most Frequently Used (MFU):


MFU removes the item with the highest access frequency when the cache is full.

Similar to LFU, it requires maintaining access counts.

Optimal (OPT):


OPT is a theoretical cache policy that always evicts the item that will not be used for the longest time in the future.

This policy provides the best possible cache hit rate but is impractical to implement because it requires knowledge of future access patterns.

Two-Queue (2Q):


2Q is a hybrid cache replacement policy that uses both LRU and LFU.

It maintains two separate queues for recent and frequently accessed items, attempting to balance between recency and frequency.

Clock (or Second-Chance):


This policy maintains a circular buffer of items and marks each item when it's accessed.

When an eviction is needed, it searches for the first unmarked (not accessed) item in the buffer and removes it.

Adaptive Replacement Cache (ARC):


ARC is a self-tuning cache replacement policy that dynamically adjusts the size of its four lists based on recent access patterns.

It aims to combine the benefits of LRU and LFU without requiring manual tuning.

The choice of cache policy depends on the specific use case and the access patterns of the data. Some policies may perform better than others in certain situations, so it's essential to consider the trade-offs between cache hit rate, complexity, and implementation overhead when selecting a cache policy.

Comments

Popular posts from this blog

How to create Annotation in Spring boot

 To create Custom Annotation in JAVA, @interface keyword is used. The annotation contains :  1. Retention :  @Retention ( RetentionPolicy . RUNTIME ) It specifies that annotation should be available at runtime. 2. Target :  @Target ({ ElementType . METHOD }) It specifies that the annotation can only be applied to method. The target cane be modified to:   @Target ({ ElementType . TYPE }) for class level annotation @Target ({ ElementType . FIELD }) for field level annotation @Retention ( RetentionPolicy . RUNTIME ) @Target ({ ElementType . FIELD }) public @ interface CustomAnnotation { String value () default "default value" ; } value attribute is defined with @ CustomAnnotation annotation. If you want to use the attribute in annotation. A single attribute value. Example : public class Books {           @CustomAnnotation(value = "myBook")     public void updateBookDetail() {         ...

Kafka And Zookeeper SetUp

 Kafka And Zookeeper SetUp zookeeper download Link : https://www.apache.org/dyn/closer.lua/zookeeper/zookeeper-3.8.3/apache-zookeeper-3.8.3-bin.tar.gz Configuration: zoo.conf # The number of milliseconds of each tick tickTime =2000 # The number of ticks that the initial # synchronization phase can take initLimit =10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit =5 # the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir =/tmp/zookeeper # the port at which the clients will connect clientPort =2181 4 char whitelist in command arguments 4lw.commands.whitelist =* Start ZooKeeper Server $ bin/zkServer.sh start Check zookeeper status dheeraj.kumar@Dheeraj-Kumar bin % echo stat | nc localhost 2181 stat is 4 character whitelisted argument  Check Kafka running status : echo dump | nc localhost 2181 | grep broker Responsibility of Leader in Zookeeper: 1. Distrib...