Twemproxy proxy Key-Value database SSDB for Distributed Data Storage

SSDB is a high-performance NoSQL database that supports a wide range of data structures. It is used to replace Redis or store billions of List data with Redis. It has been applied by many well-known enterprises. We use SSDB to migrate keys in existing redis to SSDB to break the existing redis120G Storage Limit (of course, it can be extended, but the calculation is as follows:

SSDB is a high-performance NoSQL database that supports a wide range of data structures. It is used to replace Redis or store billions of List data with Redis. It has been applied by many well-known enterprises. We use SSDB to migrate keys in the existing redis to the ssdb to break the GB Storage Limit of the existing redis (of course, it can be expanded, but the calculation is as follows:

SSDB is a high-performance NoSQL database that supports a wide range of data structures. It is used to replace Redis or store billions of List data with Redis. It has been applied by many well-known enterprises. We use SSDB to migrate keys in existing redis to SSDB to break the GB Storage Limit of existing redis (of course it can be extended, but the cost will be abandoned after calculation ).

Twemproxy is an open-source redis and memcache proxy server of twtter. Here we use the Twemproxy proxy to proxy the SSDB cluster for Distributed Data Storage, that is, shared.

1. node planning:

Twemproxy 192.168.0.100

Ssdb1 master 192.168.0.101

Ssdb1 slave 192.168.0.102

Ssdb2 master 192.168.0.103

Ssdb2 slave 192.168.0.104

2. Install SSDB

# Unzip the downloaded ssdb package $ unzip ssdb-master.zip # Install gcc, gcc-c ++, make and other tools # compile and install ssdb, it will be installed in $ cd ssdb-master $ make & make install # Under/usr/local/ssdb/to enter the installation directory $ cd/usr/local/ssdb/# Start ssdb -server $. /ssdb-server-dssdb. confssdb 1.8.2Copyright (c) 2012-2014 ssdb. io ## verify whether the startup is successful. If Port 8888 is listened on, $ netstat-alnut | grep 8888tcp 0 0 127.0.0.1: 8888 0.0.0.0: * LISTEN # client connection $. /ssdb-cli-p8888 ssdb (cli)-ssdb command line tool. copyright (c) 2012-2014 ssdb. io 'H' or 'help' forhelp, 'q' to quit. server version: 1.8.2ssdb 127.0.0.1: 8888 & gt;

3. Master/Slave configuration. ssdb1 is used as an example.

# Modify the configuration file of ssdb1 master, as shown below # ssdb-server config # MUST indent by TAB! # Relative to path of this file, directorymust existswork_dir =. /varpidfile =. /var/ssdb. pid server: ip: 192.168.0.101 port: 8888 # bind to public ip # ip: 0.0.0.0 # format: allow | deny: all | ip_prefix # multiple allows or denys is supported # deny: all # allow: 127.0.0.1 # allow: 192.168 # auth password must be at least 32 characters # auth: very-strong-password replication: binlog: yes # Limit sync spee D to * MB/s,-1: no limit sync_speed:-1 slaveof: # to identify a master even ifit moved (ip, port changed) # if set to empty or notdefined, ip: port will be used. # id: svc_2 # sync | mirror, default is sync # type: sync # ip: 127.0.0.1 # port: 8889 logger: level: debug output: log.txt rotate: size: 1000000000 leveldb: # in MB cache_size: 500 # in KB block_size: 32 # in MB write_buffer_size: 64 # in MB co Mpaction_speed: 1000 # yes | no compression: yes # modify the configuration file of ssdb1 slave, as follows # ssdb-server config # MUST indent by TAB! # Relative to path of this file, directorymust existswork_dir =. /varpidfile =. /var/ssdb. pid server: ip: 192.168.0.102 port: 8888 # bind to public ip # ip: 0.0.0.0 # format: allow | deny: all | ip_prefix # multiple allows or denys is supported # deny: all # allow: 127.0.0.1 # allow: 192.168 # auth password must be at least 32 characters # auth: very-strong-password replication: binlog: yes # Limit sync speed to * MB/s,-1: no limit sync_speed:-1 slaveof: # to identify a master even if itmoved (ip, port changed) # if set to empty or notdefined, ip: port will be used. id: svc_1 # sync | mirror, default is sync type: sync ip: 192.168.0.101 port: 8888 logger: level: debug output: log.txt rotate: size: 1000000000 leveldb: # in MB cache_size: 500 # in KB block_size: 32 # in MB write_buffer_size: 64 # in MB compaction_speed: 1000 # yes | no compression: yes

In this way, the configurations of ssdb1 master, ssdb1 slave, ssdb2 master, and ssdb2 slave are the same. Note that if you want to configure slave for an ssdb node that already has data, you do not need to copy basic data to the slave, unlike mysql, you only need to specify the master information in the slave configuration file. ssdb automatically copies and synchronizes the basic data.

All data in the SSDB database is sorted in order, so you can think of the whole database as a linked list. SSDB starts to Copy data from the header, one node at a time, and the cursor goes backwards. at this time, if a new Binlog exists, SSDB will first determine the position of the node corresponding to the Binlog in the linked list, whether it is in front of the cursor or after it? If it is before the cursor, The Binlog is sent to Slave for execution. if it is behind the cursor, it will be ignored directly, because the cursor will eventually move to the updated position. from this description, we can also know that the Server Load balancer in the Copy phase may not be able to know the updates on the Master immediately. when the cursor moves to the end of the linked list, the Copy process ends, and the master-slave synchronization process enters the Sync phase, that is, the instant (millisecond-level) update phase. More ssdb learnning can access the ssdb Project address: http://ssdb.io/zh_cn.

4. Install Twemproxy

# Install automake, libtool, xz $ install $ yum install automake libtool xz-y # install autoconf $ wget http://down1.chinaunix.net/distfiles/autoconf-2.69.tar.xz$ xz-d autoconf-2.69.tar.xz $ tar xf autoconf-2.69.tar-C/opt $ cd/opt autoconf-2.69 $. /configure $ make & make install # install Twemproxy $ git clone https://github.com/twitter/twemproxy.git$ cd twemproxy/$ autoreconf-fvi $. /configure $ make & make install # Place the Twemproxy configuration file under/etc/and $ mkdir/etc/nutcracker $ cp conf/nutcracker. yml/etc/nutcracker. yml

5. Configure Twemproxy

# Modify the configuration file $ vim/etc/nutcracker. yml beta: listen: 127.0.0.1: 22122 hash: fnv1a_64 hash_tag: "{}" distribution: ketama auto_eject_hosts: false timeout: 400 redis: true servers:-192.168.0.101: 8888: 1 server1-192.168.0.103: 8888: 1 server2

Configuration items:

Listen: 127.0.0.1: 22122 # Listening address and port

Hash: fnv1a_64 # hash Algorithm

Redis: true ## whether the backend proxy is redis

Servers: # shard Server LIST

Distribution: ketama # sharding algorithm, which includes ketama (Consistent hash), module (Modulo), and random (random ).

Auto_eject_hosts: false # Whether to automatically remove the node from the server list when the node fails to respond. When the node responds again, it is automatically added to the server list.

Hash_tag: "{}" # assume that an object in ssdb has multiple key attributes, for example, kora's name: kora:, kora's age: kora :, kora address loc: kora:. To ensure that these three attributes can be routed to the same shard on the backend, We need to specify hash_tag :"{::}", this avoids cross-partition retrieval when reading data.

6. Start Twemproxy.

# Start $ nutcracker-d-c/etc/nutcracker. yml-p/var/run/redisproxy. pid-o/var/log/redisproxy. log & # verify whether port 22122 is listened on $ netstat-alnut | grep 22122tcp 0 0 127.0.0.1: 22122 0.0.0.0: * LISTEN

7. Test the sharding Function

# Note: The Twemproxy proxy does not support ssdb-cli connection, but the ssdb protocol is consistent with the redis protocol. We can use the redis client to connect to the proxy, I have consulted the author of ssdb about this problem. I need to use redis-cli $. /redis-cli-p 22122127.0.0.1: 22122>

# Insert the following data into the proxy

650) this. width = 650; "src =" http://www.68idc.cn/help/uploads/allimg/151111/1212591923-0.jpg "title =" a1.png "alt =" wKiom1UzckKBDtqHAAFqK4wp_4c881.jpg "/>

# View data on the backend ssdb server1 with three keys

650) this. width = 650; "src =" http://www.68idc.cn/help/uploads/allimg/151111/1212595X2-1.jpg "title =" a2.png "alt =" wkiol1uzc5ub1_txaajyop_awra061.jpg "/>

# View data on the backend ssdb server1 with five keys

650) this. width = 650; "src =" http://www.68idc.cn/help/uploads/allimg/151111/1212592963-2.jpg "title =" a3.png "alt =" wKiom1UzckLy_pgTAAJALRpADoU610.jpg "/>

The Twemproxy proxy can implement the distributed storage of SSDB, but there is nothing to do with the online expansion of the SSDB distributed system. If you need to expand the existing distributed cluster, the simplest way is to create a desired cluster, then, the dual-write data is applied to the new and old clusters, and then the data in the old cluster is migrated to the new cluster through proxy. Note that the data is set only when no key exists in the new cluster, prevent old data from overwriting new data. After the data migration is complete, select an appropriate time to switch the application to the new cluster. Because the Twemproxy proxy is used, the switching process is transparent to front-end applications.