Redis's (18) Redis's support for horizontal expansion of cluster features, as well as slot-related operations

[A] The shortcomings of the master-slave cluster, the disadvantage of client fragmentation (1) master-slave + Sentinel Redis cluster, just the decision from the backup, data redundancy of a processing. However, there is still a limit on the expansion of storage space. Because the nodes in the cluster are all storing the same data. The capacity of a single node can determine the capacity of the entire cluster to store data. Cask effect. (2) client-side planning of the Shard (that is, the different keys stored on different nodes), including the client pre-shard technology, to solve the storage capacity is not limited by a single minimum storage node, but in the cluster node new join and node offline, will result in the data hit rate is not high, need manual re-planning, data transfer.   [two]redis3.0 version supports clustering (including storage capacity scaling, new node join or offline issue resolution. ) (1) Redis cluster, with the same performance as a single instance (2) can provide certain accessibility after the network partition and support for recovery of primary Database (3) exception cluster supports almost all the commands supported by the standalone instance, for commands involving multiple keys (mget), If each key is located in the same node, it can be supported normally, otherwise error. (4) In addition to the cluster has a limit, is only the default number NO. 0 database, if you use the Select command to switch the database, you will be prompted with an error.    [III] The reason for using 3.0 Redis (1) is good to support the expansion of fragmentation and storage capacity (2) Sentinel and cluster are two independent functions, single-point Sentinel can be regarded as a subset of clusters, when data fragmentation is not required, or is already in the client shard scene, Sentinel use is sufficient, single if required level (storage capacity expansion and data shards), the cluster is a good choice.   [four]redis3.0 more nodes of the cluster cluster (1) REDIS-TRIB.RB is to use the cluster meet command to make each node aware of the other nodes in the cluster, it is conceivable that if you want to add a new node to the cluster, It also needs to be implemented using the cluster meet command.  (2) Use command: CLUSTER MEET IP Port---> Cluster Add new Node A. ---> Send to new node: "CLUSTER MEET IP Port" command, IP and port are the address and port number of any node in the cluster, and a after receiving the command from the client, a handshake is made with Node B of the address and port number so that B is considered a member of the current cluster. When B and a handshake are successful, B uses the gossip protocol to notify node A about each node in the cluster. This way, even if there are multiple nodes in the cluster, it is only necessary to select any one of the meet nodes, so that the new node can eventuallyJoin the entire cluster.  [Five] What is a slot? (1) The calculation of the slot calculates the hash value using the CRC16 algorithm for the valid part of the key name of each key, and then takes the remainder to 16384. This allows each key to be assigned to a valid part of the 16,384-slot (2) Key Name:---> If the key name contains a {symbol, and there is a} symbol after the {symbol. And there is at least one character between {and}, the valid part refers to the content between {and}---> If the previous rule is not met, the entire key name is a valid part. For example: {user102}:last.name Key Name valid part is: user102      shangxiaofei The valid part of the key name is: shangxiaofei  [Five] How to assign a slot to a specified node. The allocation of slots is divided into the following scenarios. (1) The slot was not assigned before and now wants to assign to the specified node.  Link the server on the specified node and enter the command to assign the slot. ---> Command: CLUSTER addslots  slot1 slot2 .... [Slotn]--->REDIS-TRIB.RB also assigns operations to new nodes when the cluster is created by this command.  If the slot is already assigned to a node, it is prompted (error) that the Err Solts is already busy (2) slot before it is assigned and now wants to move to the specified node. ---> Use commands to see how slots are allocated.  CLUSTER SLOTS. ==> View slot Assignments ==> use REDIS-TRIB.RB for slot movement   ==> to view slot movement results     (3) manually move the slot No. 0 from the 6380 node back to the 6379 node--  The move command with no key in the slot: Clustre Setslot slot number node The run ID of the new nodes. ---> The migration of this command is based on the fact that there are no keys in the slots because the cluster setslot command migrates the slots and does not migrate along with the corresponding keys. This causes the client to be unable to find the non-migrated key in the specified node,   (4) will have a key to exist slot, from one node, move to another node, and move the key in the slot in the past---> manually get a slot there are those keys: CLUSTER Getkeysinslot slot number The number of keys to return---> after each key, use MigraThe TE command migrates it to the target node: MIGRATE destination node address destination node port Key Name database number timeout [Copy][replace]---> Where the Copy option does not remove the key from the current database, just copy a copy to the target database. ---> Where the Replace option, if the target has a key with the same name, overrides   three: If you implement Redis no-line migration data (1) Two command--->cluster setslot slot number migrating the new node's run ID--- >cluster Setslot Slot number importing the operation ID of the original node (2) Assume that the No. 0 slot is migrated from A to B---> performed in B: CLUSTER setslot 0 Importing A---> Execute in a: CLUSTER setslot 0 Migrating B---> Execute CLUSTER getkeysinslot 0 get the key list for slot 0th---> Execute the Migrate command for each key obtained in step three. Migrate it from A to B---> Execute clustre setslot 0 NODE B to complete the migration. &&: note: During the migration process, if the a node is accessed, if the key has not been migrated, then normal processing, if the migration has been completed, returns an Ask jump request, telling the client that the key is in B. Avoid temporary loss of keys during the migration process. Four: Gets the node corresponding to the slot. V: failback (1) Each node in a cluster periodically sends ping commands to other nodes. And to determine whether the target node has been offline by receiving a reply. (2) Randomly select 5 nodes every 1 seconds, and then select the node that has the longest response time to send the ping command.  (3) Failure recovery and sentinel mechanism are similar.  ---> Once Node A thinks that Node B is suspected of being offline, it propagates the message in the cluster, and all other nodes will log the message when they receive it. ---> When a node C in its group collects more than half of the nodes that think B is suspected, it marks B as offline and propagates the message to other nodes in the cluster, thus allowing B to go offline throughout the cluster. If the Downline node is the primary node, a slave node is elected from the corresponding node list to upgrade to the new master node. Election algorithm: And Sentinel in the election leader Sentinel algorithm consistent, based on the raft algorithm.  When the new master node is elected, execute slaveof on one to upgrade itself to the primary database. ---> If a primary database with at least one socket is offline and there is no corresponding recovery from the database, the entire cluster will default to the offline state and not be able to work. If you want to make the cluster work correctly in this case, you can modify the configuration Cluster-require-full-coverage to No (the default is YES)

Redis's (18) Redis's support for horizontal expansion of cluster features, as well as slot-related operations