Redis Cluster

What is Redis?
  • Re : Remote
  • Di : Dictionary
  • S   : Server

  • Redis is open source.
  • Redis can store/serve data as key-value pairs.
For example:                Name   :     Yasiru    
in this example Name is the key and Yasiru is the value.This can use as a database. For write a data we can use the code SET "age" "25" . For read the data we can use the code Get "Name" .
  • Redis is a No-SQL-database. It use data structures to store data.  
It has 5  primary data structures. They are String, Lists, Sets, Stored Sets, Hashes. It has 3 extra data structures. They are bitmaps, hyperloglogs, geospatial indexes.
  • Redis interaction with data is command based.
  • Redis store data in cache memory. There for it makes super fast. However there is an option to write data in disk.
Why we use Redis?
  • Redis is super fast. You can see the performance of the Redis by the chart given below. 

  • Redis is simple and Flexible
  • No need of defining any tables, rows,columns
  • No insert, selects, update, delete
  • Simple and straight-forward data read and write

  • Durable 
  • Has option to write data on disk 
  • Data writ options are configurable 
  •  Can be used as a Caching System or a full fledged DB
What is Redis Cluster?
  • Horizontally scalable: We can add nodes. We can increase more and more capacity.  
  • Auto data sharding: Redis cluster can partition the data and split it among the nodes in automatic way. 
  • Fault tolerant: When node is loose,  server can go down. But we can continue the operations and no data lost. That is mean highly available.
  • Decentralized cluster management system.: It is not a single node. It is like a orchestrates. Every node participate. 
What we can get from Redis cluster?
  • The ability to automatically split your dataset among multiple nodes.
  • The ability to continue operations when a subset of the nodes are experiencing failures or are unable to communicate with the rest of the cluster.
How Redis manage storage in a distributed concept? 
The key space is split into 16384 slots, effectively setting an upper limit for the cluster size of 16384 master nodes (however the suggested max size of nodes is in the order of ~ 1000 nodes).
Each master node in a cluster handles a subset of the 16384 hash slots. The cluster is stable when there is no cluster reconfiguration in progress (i.e. where hash slots are being moved from one node to another). When the cluster is stable, a single hash slot will be served by a single node (however the serving node can have one or more slaves that will replace it in the case of net splits or failures, and that can be used in order to scale read operations where reading stale data is acceptable).
The base algorithm used to map keys to hash slots is the following (read the next paragraph for the hash tag exception to this rule):
HASH_SLOT = CRC16(key) mod 16384
The CRC16 is specified as follows:
  • Name: XMODEM (also known as ZMODEM or CRC-16/ACORN)
  • Width: 16 bit
  • Poly: 1021 (That is actually x16 + x12 + x5 + 1)
  • Initialization: 0000
  • Reflect Input byte: False
  • Reflect Output CRC: False
  • Xor constant to output CRC: 0000
  • Output for "123456789": 31C3
14 out of 16 CRC16 output bits are used (this is why there is a modulo 16384 operation in the formula above).
In our tests CRC16 behaved remarkably well in distributing different kinds of keys evenly across the 16384 slots.

Note: A reference implementation of the CRC16 algorithm used is available in the Appendix A of this document.


 How it handles the failover?
Redis sentinel is the high availability solution offered by Redis. In case of a failure in your Redis cluster, Sentinel will automatically detects the point of failure and bring the cluster back to stable mode without any human intervention.

How it  utilize the peformance?

In Redis Cluster nodes don't proxy commands to the right node in charge for a given key, but instead they redirect clients to the right nodes serving a given portion of the key space.
Eventually clients obtain an up-to-date representation of the cluster and which node serves which subset of keys, so during normal operations clients directly contact the right nodes in order to send a given command.
Because of the use of asynchronous replication, nodes do not wait for other nodes' acknowledgment of writes (if not explicitly requested using the WAIT command).
Also, because multi-key commands are only limited to near keys, data is never moved between nodes except when resharding.
Normal operations are handled exactly as in the case of a single Redis instance. This means that in a Redis Cluster with N master nodes you can expect the same performance as a single Redis instance multiplied by N as the design scales linearly. At the same time the query is usually performed in a single round trip, since clients usually retain persistent connections with the nodes, so latency figures are also the same as the single standalone Redis node case.
Very high performance and scalability while preserving weak but reasonable forms of data safety and availability is the main goal of Redis Cluster.


Comments

Post a Comment