Apache Ignite supports distributed transactional cache operations, and at the same time it is highly available. Supporting both ACID transactions and high availability is a big ask for any distributed data store. Distributed data stores follow the CAP theorem. Computer scientist Eric Brewer proposed the CAP theorem, and it says that a distributed data store cannot offer more than two of the following three capabilities:

• Consistency: You will always get the latest and greatest data. Suppose you have two nodes, A and B, and someone is updating a document/record in node B and you are reading that same record from node A. You should get the latest update made to the record in node B.
• Availability: You should always get a response; it may not be the latest data, but it should not throw an error.
• Partition tolerance: This means that if you remove the network...

Apache Ignite offers an out of the box clustering mechanism and APIs to perform various caching activities. This section is going to cover the following clustering features:

• Node discovery
• Node deployment
• Cluster grouping

Apache Ignite is designed to scale elastically by adding more nodes to the cluster. The addition of a new node or removal of a node is transparent to the cluster. It depends on inter-node communication and doesn't rely on a master node to maintain the cluster. As of version 2.5, Apache Ignite supports two types of node discovery:

• TCP/IP discovery
• ZooKeeper discovery

We will explore both of these discovery types.

The Apache Ignite caching API provides three caching modes to distribute cache elements:

• Local
• Partitioned
• Replicated

The local mode is similar to JVM caching using a HashMap. Data is local to the node and not distributed to any other nodes of the cluster. The following are the benefits of the local mode:

• Fastest data access as there is no need for network operations
• Fastest data modification

The main drawback of this approach is if there is more than one JVM that needs to access the same data, then more than one local cache will be created. A local cache is useful for read-only data access where the JVM doesn't need to update any cache elements. Still, a local cache is way better than hashmap...

Apache Ignite offers three strategies to access data from a distributed cache:

• Cache aside
• Read-through and write-through
• Write behind

In the cache aside strategy, the Apache Ignite cluster doesn't interact with the persistence storage; the application takes the responsibility to read data from the persistence storage and update the cache. First, the application looks up the cache for data if the data is available in the cache then returns it; otherwise, it goes to the persistence storage to fetch the data and updates the cache so that the next cache lookup can return the value from the cache. The following diagram represents the cache aside architecture:

The application updates the cache...

In this chapter, we looked at the Apache Ignite caching architecture. We started by explaining the CAP theorem for distributed data stores and how Apache Ignite can be tuned to use AP or CP. Apache Ignite has an efficient clustering API; we looked at the various clustering configurations such as node discovery, node deployment, and node grouping.

This chapter also explored the caching modes used to distribute data. We looked at local, partitioned, and replicated cache modes and how scalability, availability, and read/write performance can be tuned using the caching modes.

This chapter concluded with the caching strategies: cache aside, read-through and write-through, and write-behind. The next chapter will explain the data grid concept and explore the web session clustering technique.