Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • Redis Cluster Specification-12

    Uploaded by

    Kajaruban Surendran
    27 views1 page
    The document discusses how Redis clients interact with Redis clusters. When a client sends a query to a node, the node checks if it is responsible for serving the key or keys in the query. If not, it responds with a MOVED error including the hash slot and IP/port of the node that can serve the query. The client then reissues the query to the specified node. Over time, clients build up a map of hash slots to nodes to directly address the right nodes without redirections.

    Original Description:

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    The document discusses how Redis clients interact with Redis clusters. When a client sends a query to a node, the node checks if it is responsible for serving the key or keys in the query. If not, it responds with a MOVED error including the hash slot and IP/port of the node that can serve the query. The client then reissues the query to the specified node. Over time, clients build up a map of hash slots to nodes to directly address the right nodes without redirections.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    Download as pdf or txt
    27 views1 page

    Redis Cluster Specification-12

    Uploaded by

    Kajaruban Surendran
    The document discusses how Redis clients interact with Redis clusters. When a client sends a query to a node, the node checks if it is responsible for serving the key or keys in the query. If not, it responds with a MOVED error including the hash slot and IP/port of the node that can serve the query. The client then reissues the query to the specified node. Over time, clients build up a map of hash slots to nodes to directly address the right nodes without redirections.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    Download as pdf or txt
    of 1

    A Redis client is free to send queries to every node in the cluster, including slave nodes.

    The node will analyze the query, and if it is acceptable (that is, only a single key is
    mentioned in the query, or the multiple keys mentioned are all to the same hash slot) it
    will lookup what node is responsible for the hash slot where the key or keys belong.
    If the hash slot is served by the node, the query is simply processed, otherwise the
    node will check its internal hash slot to node map, and will reply to the client with a
    MOVED error, like in the following example:

    GET x

    -MOVED 3999 127.0.0.1:6381

    The error includes the hash slot of the key (3999) and the ip:port of the instance that
    can serve the query. The client needs to reissue the query to the specified node's IP
    address and port. Note that even if the client waits a long time before reissuing the
    query, and in the meantime the cluster configuration changed, the destination node will
    reply again with a MOVED error if the hash slot 3999 is now served by another node.
    The same happens if the contacted node had no updated information.
    So while from the point of view of the cluster nodes are identified by IDs we try to
    simplify our interface with the client just exposing a map between hash slots and Redis
    nodes identified by IP:port pairs.
    The client is not required to, but should try to memorize that hash slot 3999 is served by
    127.0.0.1:6381. This way once a new command needs to be issued it can compute the
    hash slot of the target key and have a greater chance of choosing the right node.
    An alternative is to just refresh the whole client-side cluster layout using the CLUSTER
    NODES or CLUSTER SLOTS commands when a MOVED redirection is received.
    When a redirection is encountered, it is likely multiple slots were reconfigured rather
    than just one, so updating the client configuration as soon as possible is often the best
    strategy.
    Note that when the Cluster is stable (no ongoing changes in the configuration),
    eventually all the clients will obtain a map of hash slots -> nodes, making the cluster
    efficient, with clients directly addressing the right nodes without redirections, proxies or
    other single point of failure entities.
    A client must be also able to handle -ASK redirections that are described later in this
    document, otherwise it is not a complete Redis Cluster client.

    Cluster live reconfiguration


    Redis Cluster supports the ability to add and remove nodes while the cluster is running.
    Adding or removing a node is abstracted into the same operation: moving a hash slot

    You might also like