JBossDataGrid cluster deployment and access

The cache mode for JDG deployment in a cluster includes the Local and Clustered modes. This project is deployed in multi-node Clustered mode. Data is replicated between subsets of multiple nodes instead of all nodes. Using subset replication can improve the fault tolerance efficiency, but it does not significantly affect scalability. When using Clustere

The cache mode for JDG deployment in a cluster includes the Local and Clustered modes. This project is deployed in multi-node Clustered mode. Data is replicated between subsets of multiple nodes instead of all nodes. Using subset replication can improve the fault tolerance efficiency, but it does not significantly affect scalability. When using Clustere

Cluster deployment

The cache mode of JDG includes Local mode and cluster mode. This project is deployed in multi-node Clustered mode. Data is replicated between subsets of multiple nodes instead of all nodes. Using subset replication can improve the fault tolerance efficiency, but it does not significantly affect scalability. JGroup should be configured before deployment in Clustered mode.

1. broadcast using UDP.

L applicable to large clusters (over 100 nodes );

L applicable to Invalidation and Replication modes;

L improve the efficiency of socket communication.

2. Use TCP broadcast.

It is more suitable for small-scale (less than 100 nodes) clusters in distribution mode, because TCP is more efficient in point-to-point communication.

The Clustered mode is divided into Invalidation, Replication, and Distribution modes.

Distribution Mode

The Distribution mode of JDG stores cached data on a subset node of the cluster, rather than storing data to each node. Data redundancy and fault tolerance are usually stored on more than one node.

In Distribution mode, consistent Hash algorithms are used to select data storage nodes from the cluster. Consistent Hash algorithms are configured to store cached data to multiple copies. The number of replicas must be set to balance performance and fault tolerance. Too many replicas will affect performance, and too few replicas will cause data loss when the node fails.

In Distribution mode, a put operation performs num_copies remote calls, And the get operation on any node performs at least one remote call. In fact, get operations may even execute num_copies remote calls, but they are parallel. If one is returned, the results will be returned to the caller.

Read consistency

Because the get operation obtains the number from multiple nodes in parallel and uses the first returned result, data inconsistency may occur when asynchronous mode is used. Note that this situation only occurs in the asynchronous call method. If it is synchronous, there will be no read inconsistency.

Configure cache containers and caches

When using JDG Cache, you must configure the Cache to be used in the standalone/configuration/clustered. xml configuration file. If the client accesses an unspecified Cache, the operation is considered invalid.

In ......Configure cache-container and distributed-cache. This project uses the distributed cache mode.

Node Add the Cache configuration node, the following is the default cache (default Cache configuration ):

In
 
  
......Configure cache-container and distributed-cache. This project uses the distributed cache mode. Node
  
   
Add the Cache configuration node, the following is the default cache (default Cache configuration ):
  
 

# Define the default cache expiration Policy. Not all configuration items above are required. For details about each node, see:

# Lifespan: Maximum lifetime of a cache entry, in milliseconds.-1 indicates that the cache entry never expires.

# Max-idle: Maximum idle time of the cache entry, in milliseconds.-1 indicates that the cache entry never expires. If the idle time exceeds this value, the entry is deemed to have expired.

# Interval: The execution interval (MS) for clearing expired entries from the cache ). If you want to completely disable the periodic recovery task, set it to-1.

# Define the default cache reclaim Policy

# Eviction: Specify the recycle policy. Available recycling policies include UNORDERED, FIFO, LIRS, and NONE ).

# Max-entries: specifies the maximum number of entries in the Cache instance.-1 indicates no restriction. The actual value is> = the minimum value of the power of 2 of the selected value

# Define a cache lock

# Isolation: defines the isolation level. Available isolation levels include NONE, READ_UNCOMMITED, READ_COMMITED, REPEATABLE_READ, and SERIALIZABLE. The default value is REPEATABLE_READ.

# Striping: locks are striped. If it is true, the shared lock pool is used to maintain all the entries to be locked. Otherwise, create a lock for each entry. Locking strip helps to control memory usage, but may reduce the system's concurrency capability.

# Acquire-timeout: Maximum timeout time for trying to obtain a specific lock.

# Concurrency-level: the concurrency level of the lock container. This value is adjusted based on the number of threads that interact with infinispan concurrently.

# Concurrent-updates: used only for non-transaction cache. If it is set to true (default value), the cache maintains data consistency when updating concurrency. The cluster mode brings additional RPC costs. If your application does not write data concurrently, disable this flag to improve performance.

# Define cache transactions

# Although the server cache supports transactions, there is currently no protocol available to support transactions.

Start JDG Cluster

JDG can be deployed on multiple nodes to form a cluster. Currently, our project uses the data cache service to use a distributed cluster with three default nodes. The nodeName of each node must be differentiated at startup, for example, named nodeA, nodeB, and nodeC respectively.

JDG is running in the JBoss container. JBoss is started at startup. If JBOSS is already running on the server, set Port offset at startup to avoid conflict.

To avoid conflicts with the JBoss server's JBOSS_HOME, define the environment variable JDG_HOME (for example, exportJDG_HOME =/usr/local/jboss-datagrid-server-6.1.0) and replace all JBOSS_HOME in bin/clustered. sh with JDG_HOME.

Take the nodeA node as an example (the JDG port for external access is 11222, and the following offset is 11322), the server ip address is 192.168.1.100, And the startup command is executed:

./clustered.sh-Djboss.socket.binding.port-offset=100 -Djboss.bind.address=192.168.1.100 -Djboss.node.name=nodeA

Client Access

Remote clients can use the REST, memcached, or HotRod protocols. Here we use the HotRod protocol, which is a binary protocol with good performance. It also provides automatic load balancing and failover.

Configuration File

The configuration file for client access to the cache server is named hotrod-client.properties by default. For definitions, see.

########### JDG server configuration ############## request balancing policy, default = org. infinispan. client. hotrod. impl. transport. tcp. roundRobinBalancingStrategy # infinispan. client. hotrod. request_balancing_strategy ### Server LIST, default = 127.0.0.1: 11222infinispan. client. hotrod. server_list = 192.168.1.100: 11322; 192.168.1.101: 11322; 192.168.1.102: 11322 # Whether to force the return value, default = false # infinispan. client. hotrod. force_return_values ## TCP_NO_DELAY, defau Lt = true # infinispan. client. hotrod. tcp_no_delay ### whether to send a PING request at startup to obtain the CLUSTER topology. default = true # infinispan. client. hotrod. ping_on_startup = # control the transmission mechanism used. Currently, only TCP and org are supported. infinispan. client. hotrod. impl. transport. tcp. tcpTransportFactory # infinispan. client. hotrod. transport_factory = # serialize aller used for serialization, default = org. infinispan. marshall. jboss. genericJBossMarshaller # if you want to reduce the transmission load, you can configure it as apacheavrow.aller # infini Span. client. hotrod. extends aller =## specify the custom AsyncExecutorFactory, default = org. infinispan. client. hotrod. impl. async. defaultAsyncExecutorFactory # infinispan. client. hotrod. async_executor_factory =## specify the size of the concurrent thread pool, default = 10 # infinispan. client. hotrod. default_executor_factory.pool_size = # specify the concurrent queue size, default = 100000 # infinispan. client. hotrod. default_executor_factory.queue_size = # version of the Hash function implementation and consistent Hash algorithm, which are related to the server version of HotRod # Infinispan. client. hotrod. hash_function_impl.1 ## number of bytes allowed in the cache of the serialization and deserialization keys to avoid array size adjustment, default = 64 # infinispan. client. hotrod. key_size_estimate ## number of bytes allowed in the cache of serialization and deserialization values to avoid array size adjustment. default = 512 # infinispan. client. hotrod. value_size_estimate ## socket read timeout, default = 60000 (60 seconds) infinispan. client. hotrod. socket_timeout = 50000 # socket connection timeout, default = 60000 (60 seconds) infinispan. client. hotrod. connect_timeout = 10000 # Specify the Protocol version used by the client. default = 1.1. Other values include 1.0 # infinispan. client. hotrod. protocol_version ### specify the number of Retries for an error, default = 10 # infinispan. client. hotrod. max_retries ############# connection pool configuration ############# specify the maximum number of connections for each server, negative value indicates no limit. The default value is-1 maxActive = 100 # specifies the number of global persistent connections allowed in the server group. negative value indicates no limit, default Value:-1 maxTotal = 100 # specify the maximum number of idle persistent connections for each server. negative value indicates no limit. Default Value:-1 maxIdle = 20 # specifies that when the connection pool is exhausted, how the server responds: #0-throwing an exception to the caller #1-blocking the caller until there is an idle connection #2-creating a new connection (not limited by maxActive) # The default value is 1 # whenExha UstedAction = 1 # Check the duration of each idle connection Eviction thread running interval. The default value is 2 minutes # timeBetweenEvictionRunsMillis = 120000 # How long does the connection in the idle pool need to be destroyed, A negative value indicates that no idle connection is destroyed. The default value is 30 minutes # minEvictableIdleTimeMillis = 1800000 # specifies whether idle connections are verified by sending a TCP packet to the server during execution of the Eviction thread, # connections that cannot be verified will be cleared from the pool # The default value is true # testWhileIdle = true # specify the minimum number of Idle threads available for each server. The default value is 1 # minIdle = 1.

Client Access Code

Import java.net. URL; import java. util. map; import org. infinispan. client. hotrod. remoteCache; import org. infinispan. client. hotrod. remoteCacheManager; import org. infinispan. client. hotrod. serverStatistics; public class Quickstart {public static void main (String [] args) {URL resource = Thread. currentThread (). getContextClassLoader (). getResource ("hotrod-client.properties"); RemoteCacheManager cacheContain Er = new RemoteCacheManager (resource, true); // obtain a remote Cache RemoteCache cache = cacheContainer. getCache ("myCache"); // put data to the cache, and then confirm whether the cache exists. put ("name", "paul"); if (cache. get ("name "). equals ("paul") {System. out. println ("Cache Hit! ");} Else {System. out. println (" Cache Miss! ") ;}// Delete cache data cache. remove (" name "); cacheContainer. stop ();}}

The above is the JBossDataGrid cluster deployment and access content. For more information, see PHP Chinese Network (www.php1.cn )!