Memcached (vii) Failure mode and Standby node

For the failure model, you can look at the interpretation of the official memcached document Https://code.google.com/p/memcached/wiki/NewConfiguringClient#Failure,_or_Failover

To expand, the default policy for most clients is failover when one of the memcached nodes is hung up or due to other failed connections, which means finding the next available memcached node to continue to use. Data that is hung or nodes that are not connected will be transferred to other nodes, and the routing policy can be either round Robin or a consistent hash. Such a pattern works well in the event of a node unexpected failure to hang out, but the memached node is also entirely possible because of an accidental accident and temporarily hung up, such as you accidentally dropped the network cable and immediately connected, such as the engine room switch suddenly power failure and immediately resumed, assuming that before the failure, User A is about to update data to Node A, node A is accidentally disconnected, then the data is updated to the next valid node B, but node a recovers immediately, and the user reads the data from node A and reads the old data before the update (the new data is updated to the B node), which is very confusing to the user. You told me that the update was successful, but it was still the data before the update.

How to solve it? A simple solution is the so-called failure model, when a node is hung, it is not removed from the list of nodes, the request is not moved to the next valid node, but the request is simply set to fail, and in the context of the previous scenario, node A is accidentally disconnected when the user updates the data to Node A. Then the user's update request will not be transferred to Node B, but directly tell the user that the update failed, the user again query the data will bypass node A directly query back-end storage. This pattern is ideal for this node to be temporarily unavailable, and the request passes through the cache to the backend, but avoids the problem of old and new data.

Xmemcached supports the failure mode, as long as you set the Failuremode to True, simple example:

Java code

Xmemcachedclientbuilder Builder = ...    
    Set use Failure mode    
Builder.setfailuremode (TRUE);

In this mode, when a node is hung, requests to this node will throw the memcachedexception exception directly.

Not only that, xmemcached will also introduce the concept of standby node, you can set up a backup node of a memached node, when the node is hung up will forward the request to the backup node, will not simply throw out the exception, and will not be forwarded to other nodes. To use standby node, you must first set up the use of failure mode, an example:

Java code

Xmemcachedclientbuilder builder = new Xmemcachedclientbuilder (Addrutil    
                . Getaddressmap (" 192.168.1.99:11211,192.168.1.100:11211 192.168.1.101:11211,192.168.1.102:11211 "));    
Builder.setfailuremode (TRUE);

As you can see, the new server string format changes to Host:port,host:port Host:port,host:port format, separated by a space is a grouping of two nodes, separated by a comma is the master node and backup node, in the above example, we set the guest The node used by the user is 192.168.1.99 and 192.168.1.101, where 99 of the corresponding backup nodes are 100, and 101 of the backup nodes is 102. And we need to set the use of failure mode to true.

Failure mode plus the standby node can better solve the problem of old and new data, and can also prevent requests from penetrating cache to db, but the data synchronization between two nodes, xmemcached not ready to help you do, My advice is to use repcached this patch for replication.

Some friends may want to flush the data of the backup node before using the Backup node. To prevent the use of old data, request or can penetrate the cache to find the DB, and storage to the backup node, I carefully consider this scenario, measured or not ready to do automatic flush, mainly concurrency is difficult to deal with, And flush data This thing can be done by hand, according to my experience, do too transparent too automatic is not necessarily a good thing. You can manually flush the data of the backup node after the master node is restored.

From Iteye, Author: 85977328

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/webkf/tools/