Distributed Redis Service: Codis

Codis Introduction

Codis It's a pea pod. A distributed Redis service developed and open-source by the infrastructure team can be seen as a Redis service with unlimited memory, with the ability to dynamically expand/shrink capacity.

Codis The ability to dynamically expand/shrink redis, increase or decrease the Redis instance to the client completely transparent, do not need to restart the service, do not need to worry about the business of Redis memory explosion problem.

Codis Architecture

Single Codis-proxy architecture

650) this.width=650; "src=" http://s4.51cto.com/wyfs02/M02/7F/14/wKiom1cSaeLSWXYbAAB3vhQLxio836.jpg "title=" 1.jpg " alt= "Wkiom1csaelswxybaab3vhqlxio836.jpg"/>

Multi-Codis-proxy architecture

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M02/7F/14/wKiom1cSbXyAdQEqAACEuL0vOuY587.png "title=" 2.png " alt= "Wkiom1csbxyadqeqaaceul0vouy587.png"/>

In the design of Codis, Codis-proxy is designed to be stateless, the client connection to any one codis-proxy is the same, so it is easier to more than one single codis-proxy to achieve high availability and horizontal expansion. A highly available architecture with multiple codis-proxy is recommended.

Codis the characteristics

Codis Shards

Codis using pre-sharding technology to achieve data fragmentation, the default is divided into 1024 slots (0-1023). For each key, the slot ID is determined by the hash algorithm CRC32 (key)%1024.

Slots is a virtual concept. Each slot will have one and must have a specific server group ID to indicate which server group the data for this slot is provided by. The migration of data is also in the smallest unit of slots.

Codis Data Migration

Codis supports data migration through Codis-server, which is a key to migrating data. Each time a key is migrated in the smallest unit, the main thread will not block. The operation of Redis is memory, batch write-once and multiple set is almost no difference, and this model also avoids the migration process of data update synchronization problem, because the migration of a key operation is atomic, for this redis-server, before the completion of this migration command, Does not respond to other requests, so the data is secured.

Redis migrating to Codis

Redis-port Tools

Codis provides a redis-port command-line tool that enables the migration of Redis clusters from data to Codis distributed Redis clusters. Redis-port has the following functions:

1. Static analysis of RDB files, including parsing and recovering RDB data to Redis

2 , dump RDB files from Redis, and dynamically synchronize data between Redis and Codis

Implementation steps

Implementing the Redis cluster migration to the CODIS cluster requires the following actions

1 , build up the Codis cluster, and Codis-proxy can run correctly

2 , run a redis-port for each Redis instance to import data to you codis. such as:

Nohup redis-port sync--ncpu=4--from=redis-server:6379 \

--target=codis-proxy:19000 >${port}.log 2>&1 &

Note:

Each redis-port is responsible for importing the corresponding Redis data into the Codis

No interference between multiple redis-port, unless there is a conflict on multiple Redis keys

a single redis-port can increase the speed at which the responsible data is migrated in parallel, specifying the number of parallel by-nohup

Import Speed limited by bandwidth and codis-proxy processing speed

3 , complete the data migration, point the service to the Codis cluster when appropriate, and turn the Redis cluster offline

Note:

When the original Redis cluster goes offline, it causes the Redis-port connection to disconnect and automatically exits

Highly Available

Codis-proxy Highly Available

Because the codis-proxy is stateless, it is easier to achieve high availability and scale-out,

For Java users, it is possible to use the designer's modified Jedis (Https://github.com/CodisLabs/jodis) to achieve Codis-proxy's high availability. It provides real-time access to the currently available proxy list by monitoring the registration information on ZK to ensure high availability, or load balancing by taking turns requesting all proxies. If you need an asynchronous request, you can use the Nedis that we developed based on Netty.

Redis Instance High Availability

For Codis-group Redis instances, when a group master fails, it should be clear to the administrator and manually upgrade the slave to master, as this involves issues such as data consistency. When a master in group fails, and one of the slave is upgraded to master, the other slave instances within that group do not automatically change state, and these slave still attempt to synchronize data from the Old master. This results in inconsistent data between the new master and slave in the group. Because the Redis slaveof command will discard all the data on the slave when it switches to master, it will consume the new master resource in full sync from the newly master, so it is recommended to manually operate it with Codis-configserver add < Group_id> <redis_addr> Slave.

Codis an open API enables automatic switching of master-slave tool-codis-ha, which detects a master failure, automatically downline it, and promotes a salve to master, but does not automatically refresh the status of other slave.

codis-ha usage

Go getgithub.com/ngaut/codis-ha

CD codis-ha

codis-ha--codis-config=localhost:18087--productname=test

Reference Documentation:

Codis User guide: https://github.com/CodisLabs/codis/blob/master/doc/tutorial_zh.md

Codis Design and implementation 2:http://0xffff.me/blog/2014/11/11/codis-de-she-ji-yu-shi-xian-part-2/

This article is from the "Chang Jie listen to the Wind People" blog, please make sure to keep this source http://kevinhao.blog.51cto.com/5204735/1764643

Distributed Redis Service: Codis