When can we use Ehcache cache (GO)

First, what is Ehcache?

Ehcache is one of Hibernate's level two cache technology, which can store the queried data in memory or disk, save the next query to query the database again, greatly reduce the database pressure.

Ii. What are the use scenarios of Ehcache

1, the first most important is the page cache.
Web page data sources are very extensive, mostly from different objects, and possibly from different db, so caching a page is a good idea.

2, the cache of common data
Some configuration information, such as some infrequently changing settings in the background, can be cached.

Third, the use of ehcache points of attention

1, relatively few update data table case
2, the concurrency requirements are not very strict circumstances
Caches in multiple application servers cannot be synchronized in real time.
3, the consistency requirement is not high under the circumstances
Because the Ehcache local cache is not a good way to solve the problem of cache synchronization between different servers, we use the centralized cache such as Redis, memcached and so on when the consistency requirement is very high.

Iv. how the Ehcache behaves in a clustered, distributed situation

There are two modes of synchronization in distributed situations:
1. RMI Multicast mode

Paste_image.png

Example:

<cacheManagerPeerProviderFactory        class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"        properties="peerDiscovery=automatic, multicastGroupAddress=localhost, multicastGroupPort=4446,timeToLive=255"/>

principle: When the cache changes, Ehcache sends RMI UDP multicast packets to the multicast IP address and port number.
defects: Ehcache multicast is done relatively elementary, the function is only basic implementation (such as a simple hub, two single network card server, the multicast synchronization between the no problem), for some complex environment (such as multiple servers, multiple addresses on each server, especially the cluster, there is a cluster address with multiple physical machines, Each physical machine with more than one virtual station sub-address, it is prone to problems.

2, the Peer way
principle: Peers require that each node's Ehcache point to a different N-1 node.

3. JMS Message Mode

Paste_image.png

principle: The core of this pattern is a message queue, each application node subscribes to a predefined theme, and when the node has an element update, it also publishes the update element to the topic. Each application server node obtains up-to-date data by listening for MQ, then updates its own Ehcache cache separately, Ehcache supports ACTIVEMQ by default, and we can implement similar KAFKA,RABBITMQ by customizing the components.

4. Cache Server Mode
principle: This mode will exist in the master-slave node.

Paste_image.png

BUG: The cache is prone to inconsistent data issues,

V. What is the bottleneck of using Ehcache

1, cache Drift (Drift): Each application node only manages its own cache, when updating a node, does not affect the other nodes, so the data may be out of sync.

2, database bottlenecks: for single-instance application, the cache can protect the database read storm, but in the cluster environment, each application node must keep the data up-to-date, the more nodes, The more expensive the database is to maintain such a situation.

Vi. How to use Ehcache in practical work

In my actual work, I'm more of a level two cache with Redis as a ehcache.
The first way:

Paste_image.png

Note:
This way the Redis cache server is updated more synchronously with the local cache through the Ehcache timer of the application server, and the disadvantage is that each server has a different timing ehcache time, so the time for each server to refresh the latest cache is not the same, resulting in inconsistent data. The consistency requirement is not high and can be used.

The second way:

Paste_image.png

Note:
By introducing the MQ queue, the Ehcache of each application server listens to MQ messages synchronously, so that the quasi-synchronous update data can be achieved to some extent, via MQ push or pull, but because of the network speed between different servers, Therefore, it is not possible to fully achieve strong consistency. The same is true with distributed coordination notification components such as zookeeper, based on this principle.

Summarize:
1, the advantage of using level two cache is to reduce the network transport overhead of cached data, when the centralized cache fails, the local cache such as Ehcache can still support the normal use of the application, increasing the robustness of the program. In addition, a level two cache policy can be used to prevent the cache penetration problem to some extent.

2, according to the CAP principle we can know that if you want to use strong consistency cache (according to their business decisions), centralized caching is the best choice, such as (redis,memcached, etc.).

Wen/Xiao Cheng story More (Jane book author)
Original link: http://www.jianshu.com/p/2cd6ad416a5a
Copyright belongs to the author, please contact the author to obtain authorization, and Mark "book author".

Distributed Domain Cap theory,
Consistency (consistency), data consistent update, all data changes are synchronized
Availability (availability), good response performance
Partition tolerance (partition fault tolerance) reliability

Theorem: Any distributed system can only meet two points at the same time, not three of them.
Advice: Architects should not waste their energy on how to design a perfect distributed system that satisfies the three, but should make a choice.

The acid model of a relational database has high consistency + availability and is difficult to partition:
Atomicity atomicity: All operations in a transaction must be completed or not completed.
Consistency consistency. At the beginning or end of a transaction, the database should be in a consistent state.
Isolation isolation layer. The transaction assumes that only it is operating the database itself and is unaware of each other.
Durability. Once the transaction is complete, it cannot be returned.
Cross-database transactions: 2PC (Two-phase commit), 2PC is the anti-scalability pattern (Pat Helland), which is anti-scalable, and JTA transactions in Java EE can support 2PC. Because 2PC is anti-pattern, try not to use 2PC, avoid using base.

Base model anti-acid model, completely different acid models, sacrificing high consistency for availability or reliability:
Basically available is basically available. Support partition failure (e.g. sharding fragmentation database)
Soft state Soft state can have a period of time out of sync, asynchronous.
Eventually consistent ultimately consistent, the final data is consistent, not always high consistency.

The main realization of base thought is
1. Partitioning the database by function
2.sharding fragments

Base idea mainly emphasizes the basic usability, if you need high availability, that is, pure performance, then with consistency or fault tolerance as the sacrifice, the base idea of the scheme has the potential to dig in performance.

Now that the NoSQL movement has enriched the base idea, it can be tailored to specific scenarios, such as ignoring consistency, getting high availability, and so on, NoSQL should have the following two genres:
1. Key-value storage, such as Amaze Dynamo, can flexibly select database products of different tendencies according to the cap three principle.
2. Domain model + distributed cache + Storage (QI4J and NoSQL motion), it is difficult to customize flexible distributed solutions according to the CAP three principle.

The two things in common: all are the alternative to relational database SQL, and as the data is distributed, any model can be persisted by itself, separating the data processing and storage, separating the read and write, and the storage can be asynchronous or synchronous, depending on the degree of consistency required.

What's different: Key-value storage products like NoSQL are the product box that meets the relational database header, and can be used in non-Java areas such as PHP Ruby, which is a product that you can use, while domain model + distributed cache + storage is a complex architecture solution, not a product, But this approach is more flexible and should be the architect's master.

Base pay attention to soft state, this state is a non-instantaneous status, is a no connection, or as short as possible the state of the connection, and acid is fastidious strong consistency, requires the real-time transaction hard state, which is a completely connection-oriented status. Strong consistency at the expense of performance and high availability, the current Jdon style is an architectural style that conforms to the base policy.

http://www.jdon.com/37625

When can we use Ehcache cache (GO)