Bagaimana untuk melaksanakan pembahagian data Redis

Pengenalan kepada Twemproxy

Twemproxy Twitter ialah perkhidmatan kluster redis yang paling banyak digunakan di pasaran. Memandangkan redis adalah satu benang, dan kluster rasmi tidak begitu stabil dan digunakan secara meluas. Twemproxy ialah mekanisme pembahagian proksi Sebagai proksi, Twemproxy boleh menerima akses daripada berbilang program, memajukannya ke setiap pelayan Redis di latar belakang mengikut peraturan penghalaan, dan kemudian kembali ke laluan asal. Penyelesaian ini menyelesaikan masalah kapasiti bawaan satu contoh Redis dengan baik. Sudah tentu, Twemproxy sendiri juga merupakan satu titik dan perlu menggunakan Keepalived sebagai penyelesaian ketersediaan tinggi (atau LVS). Melalui Twemproxy, berbilang pelayan boleh digunakan untuk mengembangkan perkhidmatan redis secara mendatar, yang boleh mengelakkan satu titik kegagalan dengan berkesan. Walaupun menggunakan Twemproxy memerlukan lebih banyak sumber perkakasan dan mempunyai kerugian tertentu dalam prestasi redis (kira-kira 20% dalam ujian twitter), ia agak menjimatkan kos untuk meningkatkan HA keseluruhan sistem. Malah, twemproxy bukan sahaja melaksanakan protokol redis, tetapi juga melaksanakan protokol memcached Apakah maksudnya? Dalam erti kata lain, twemproxy bukan sahaja boleh redis proksi, tetapi juga memcached proksi.

Kelebihan Twemproxy:

1) Mendedahkan nod akses kepada dunia luar mengurangkan kerumitan program.

2) Menyokong pemadaman automatik nod yang gagal Anda boleh menetapkan masa untuk menyambung semula nod dan memadamkan nod selepas menetapkan bilangan sambungan Kaedah ini sesuai untuk penyimpanan cache, jika tidak, kunci akan hilang.

3) Menyokong tetapan HashTag Melalui HashTag, anda boleh menetapkan dua KEYhash kepada contoh yang sama.

4) Berbilang algoritma cincang dan berat tika hujung belakang boleh ditetapkan.

5) Kurangkan bilangan sambungan langsung dengan redis: kekalkan sambungan yang panjang dengan redis, tetapkan nombor setiap sambungan redis antara ejen dan hujung belakang, dan belah secara automatik kepada berbilang kejadian redis pada hujung belakang.

6) Elakkan masalah satu titik: Berbilang lapisan proksi boleh digunakan secara selari, dan pelanggan secara automatik memilih yang tersedia.

7) Daya pemprosesan tinggi: penggunaan semula sambungan, penggunaan semula memori, permintaan sambungan berbilang, terdiri daripada saluran paip redis dan permintaan bersatu untuk redis.

Kelemahan Twemproxy:

1) Ia tidak menyokong operasi pada berbilang nilai, seperti mengambil subsimpang dan pelengkap set, dsb.

2) Operasi transaksi Redis tidak disokong.

3) Memori yang digunakan tidak akan dikeluarkan Semua mesin mesti mempunyai memori yang besar dan perlu dimulakan semula dengan kerap, jika tidak, ralat sambungan pelanggan akan berlaku.

4) Penambahan dinamik dan pemadaman nod tidak disokong dan mulakan semula diperlukan selepas mengubah suai konfigurasi.

5) Apabila menukar nod, sistem tidak akan mengagihkan semula data sedia ada Jika anda tidak menulis skrip anda sendiri untuk pemindahan data, beberapa kunci akan hilang (kunci itu sendiri wujud pada redis tertentu, tetapi kuncinya. telah dicincang) nod lain, menyebabkan "kehilangan").

6) Berat secara langsung mempengaruhi hasil cincangan kekunci menukar berat nod akan menyebabkan beberapa kunci hilang.

7) Secara lalai, Twemproxy berjalan dalam satu urutan, tetapi kebanyakan syarikat yang menggunakan Twemproxy akan menjalankan pembangunan sekunder sendiri dan menukarnya kepada berbilang benang.

Secara umumnya, twemproxy masih sangat dipercayai Walaupun terdapat kerugian dalam prestasi, ia masih berbaloi untuk masa yang lama dan digunakan secara meluas. Untuk maklumat lebih terperinci, sila rujuk kepada dokumentasi rasmi. Selain itu, twemproxy hanya sesuai untuk kelompok statik, dan tidak sesuai untuk senario yang memerlukan penambahan dinamik dan pemadaman nod dan pelarasan beban manual Jika kita menggunakannya secara langsung, kita perlu melakukan kerja pembangunan dan penambahbaikan. https://github.com/wandoulabs/codis Sistem ini berdasarkan twemproxy dan menambah fungsi seperti pemindahan data dinamik Penggunaan khusus memerlukan ujian lanjut.

Seni bina penggunaan Twemproxy

Jenis pertama: nod tunggal Twemproxy

ps: menjimatkan sumber perkakasan, tetapi terdedah kepada satu titik kegagalan.

Jenis kedua: Twemproxy yang sangat tersedia

PS: Separuh daripada sumber terbuang, tetapi nod sangat tersedia.

Jenis ketiga: pengimbangan beban Twemproxy

PS: Jika anda adalah senario aplikasi Redis atau Memcached berskala besar, anda boleh melakukan senario pengimbangan beban Twemproxy , iaitu, menambah nod LVS berdasarkan Twemproxy ketersediaan tinggi, dan menggunakan LVS (pelayan maya Linux) untuk melaksanakan pengimbangan beban Twemproxy ialah teknologi pengimbangan beban empat lapisan dan mempunyai keupayaan proksi yang sangat berkuasa. sila lihat bab LVS blog ini. Tetapi apabila anda menggunakan LVS, masalah dengan Twemproxy dan titik kegagalan tunggal timbul lagi Pada masa ini, anda perlu membuat ketersediaan yang tinggi untuk LVS. Menggunakan teknologi penghalaan OSPF, LVS juga boleh mencapai pengimbangan beban. Dan seni bina ini adalah seni bina yang sedang saya gunakan dalam kerja saya.

Selain itu, tidak kira kaedah seni bina di atas yang digunakan, masalah kegagalan tunggal Redis tidak dapat dielakkan, dan kegigihan Redis tidak dapat mengelakkan masalah kegagalan perkakasan. Jika anda mesti memastikan akses data Redis tidak terganggu, maka anda harus menggunakan mod Kluster Redis pada masa ini mempunyai sokongan yang baik untuk JAVA dan digunakan secara meluas dalam kerja.

Pasang Twemproxy

1

Sila tulis semula pernyataan berikut menjadi satu ayat: Klon repositori twemproxy ke mesin tempatan anda menggunakan arahan berikut: git clone https://github.com/twitter/twemproxy.git Selepas menulis semula: Gunakan arahan berikut pada komputer tempatan anda: git clone https://github.com/twitter/twemproxy.git untuk mengklon repositori twemproxy

2. Pasang Twemproxy

Twemproxy perlu menggunakan Autoconf untuk penyusunan dan konfigurasi. GNU Autoconf ialah alat untuk mencipta skrip konfigurasi untuk menyusun, memasang dan membungkus perisian di bawah cangkang Bourne. Autoconf tidak dihadkan oleh bahasa pengaturcaraan dan biasanya digunakan dalam C, C++, Erlang dan Objective-C. Skrip konfigurasi mengawal pemasangan pakej perisian pada sistem tertentu. Dengan menjalankan satu siri ujian, skrip konfigurasi menjana fail makefile dan pengepala daripada templat dan melaraskan pakej mengikut keperluan untuk menjadikannya sesuai untuk sistem tertentu. Autoconf, bersama Automake dan Libtool, membentuk Sistem Binaan GNU. Autoconf telah ditulis oleh David McKenzie pada musim panas 1991 untuk menyokong kerja pengaturcaraannya di Free Software Foundation. Autoconf telah memasukkan kod yang lebih baik yang ditulis oleh berbilang orang dan telah menjadi perisian kompilasi dan konfigurasi percuma yang paling banyak digunakan.

Mari mula menggunakan autoreconf untuk menyusun dan mengkonfigurasi twemproxy:

[root@www twemproxy]# autoreconfconfigure.ac:8: error: Autoconf version 2.64 or higher is required
configure.ac:8: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63
autoreconf: aclocal failed with exit status: 63
[root@www twemproxy]# autoconf --versionautoconf (GNU Autoconf) 2.63

menggesa bahawa versi autoreconf terlalu rendah Versi autoconf 2.63 digunakan di atas, jadi mari muat turun versi autoconf 2.69 untuk kompilasi. dan pemasangan. Ambil perhatian bahawa jika anda adalah CentOS6, maka versi lalai anda ialah 2.63. Jika anda ialah CentOS7, maka versi lalai anda hendaklah 2.69. Jika anda adalah Debian8 atau Ubuntu16, maka versi lalai anda juga hendaklah 2.69. Bagaimanapun, jika ralat dilaporkan semasa melaksanakan autoreconf, ini bermakna versi itu sudah lama dan perlu disusun dan dipasang.

Kompilasi dan pasang Autoconf

[root@www ~]# wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz[root@www ~]# tar xvf autoconf-2.69.tar.gz[root@www ~]# cd autoconf-2.69[root@www autoconf-2.69]# ./configure --prefix=/usr[root@www autoconf-2.69]# make && make install[root@www autoconf-2.69]# autoconf --versionautoconf (GNU Autoconf) 2.69

Kompil dan pasang Twemproxy

[root@www ~]# cd /root/twemproxy/[root@www twemproxy]# autoreconf -fvi[root@www twemproxy]# ./configure --prefix=/etc/twemproxy CFLAGS="-DGRACEFUL -g -O2" --enable-debug=full[root@www twemproxy]# make && make install

Jika autoreconf -fvi melaporkan ralat berikut, anda perlu memasang alat libtool dan perlu bergantung pada libtool (jika ia CentOS, gunakan yum terus Hanya pasang libtool. Jika ia Debian, hanya gunakan apt-get install libtool.)

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory contrib/yaml-0.1.4 to autoreconf
autoreconf: Entering directory `contrib/yaml-0.1.4'autoreconf: configure.ac: not using Autoconf
autoreconf: Leaving directory `contrib/yaml-0.1.4'
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
configure.ac:36: error: possibly undefined macro: AC_PROG_LIBTOOL
     If this token and others are legitimate, please use m4_pattern_allow.
     See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Twemproxy menambah fail konfigurasi

[root@www twemproxy]# mkdir /etc/twemproxy/conf[root@www twemproxy]# cat /etc/twemproxy/conf/nutcracker.ymlredis-cluster:
 listen: 0.0.0.0:22122
 hash: fnv1a_64
 distribution: ketama
 timeout: 400
 backlog: 65535
 preconnect: true redis: true server_connections: 1
 auto_eject_hosts: true server_retry_timeout: 60000
 server_failure_limit: 3
 servers:
   - 172.16.0.172:6546:1 redis01
   - 172.16.0.172:6547:1 redis02

Pengenalan kepada pilihan konfigurasi:

redis-cluster: Beri nama segmen konfigurasi ini, mungkin terdapat berbilang segmen konfigurasi;

dengar: Tetapkan IP dan port pemantauan;

cincang: fungsi cincang khusus, menyokong md5, crc16, crc32, finv1a_32, fnv1a_64, hsieh, murmur, jenkins, dsb. Lebih daripada sepuluh jenis, umumnya memilih fnv1a_64 , lalai juga ialah fnv1a_64;

Tulis Semula: Gunakan fungsi hash_tag untuk mengira nilai cincang kunci berdasarkan bahagian kunci tertentu. Hash_tag terdiri daripada dua aksara, satu adalah permulaan hash_tag, dan satu lagi adalah akhir hash_tag Antara permulaan dan akhir hash_tag ialah bahagian yang akan digunakan untuk mengira nilai hash kunci, dan hasil yang dikira akan. digunakan untuk memilih pelayan. Contohnya: jika teg_cincang ditakrifkan sebagai "{}", maka nilai cincang dengan nilai utama "pengguna:{pengguna1}:ids" dan "pengguna:{pengguna1}:tweet" adalah berdasarkan " user1" dan akhirnya akan dipetakan ke pelayan yang sama. Dan "user:user1:ids" akan menggunakan keseluruhan kunci untuk mengira cincang, yang mungkin dipetakan ke pelayan yang berbeza.

pengedaran: Tentukan algoritma cincangan ini menentukan cara kunci cincang di atas diedarkan pada berbilang pelayan lalai ialah pencincangan konsisten. ketama: Algoritma cincang konsisten ketama akan membina gelang cincang berdasarkan pelayan dan memperuntukkan julat cincang kepada nod pada gelang. Kelebihan ketama ialah selepas satu nod ditambah atau dipadamkan, nilai kunci cache dalam keseluruhan kluster boleh digunakan semula sepenuhnya. Modula: Modula adalah sangat mudah Ia mengambil modulo berdasarkan nilai cincang nilai kunci dan memilih pelayan yang sepadan berdasarkan hasil modulo. Rawak: rawak bermakna tidak kira apa cincangan nilai kunci, pelayan dipilih secara rawak sebagai sasaran operasi nilai kunci.

masa tamat: Tetapkan tamat masa twemproxy Apabila tamat masa ditetapkan, jika tiada respons diterima daripada pelayan selepas tamat masa, mesej ralat tamat masa SERVER_ERROR Tamat masa sambungan akan dihantar kepada klien

tunggakan: Panjang tunggakan TCP pemantauan (baris menunggu sambungan), lalai ialah 512.

prasambung: Tentukan sama ada twemproxy akan mewujudkan sambungan dengan semua redis apabila sistem dimulakan secara lalai, nilai Boolean; untuk Redis. Jika redis adalah benar, anda boleh bertindak sebagai proksi untuk kluster memcached (ini adalah satu-satunya perbezaan antara Twemproxy sebagai proksi kluster redis atau memcached

redis_auth: Jika bahagian belakang anda Redis mempunyai pengesahan); dihidupkan, maka Kata laluan pengesahan untuk redis_auth perlu ditetapkan

sambungan_pelayan: Bilangan sambungan antara twemproxy dan setiap pelayan redis lalai ialah 1. Jika lebih daripada 1, arahan pengguna boleh dihantar kepada sambungan yang berbeza, yang boleh menyebabkan pelaksanaan sebenar perintah itu tidak konsisten dengan yang ditentukan oleh pengguna (serupa dengan concurrency

auto_eject_hosts: Sama ada hendak mengeluarkan nod tersebut lalai adalah benar, tetapi perlu diperhatikan bahawa selepas nod dikeluarkan, kerana bilangan mesin berkurangan, kedudukan cincang mesin berubah, akan menyebabkan beberapa kekunci gagal dipukul, tetapi jika sambungan program tidak dihapuskan, ralat akan dilaporkan;

server_retry_timeout: Mengawal selang masa untuk sambungan pelayan, unit adalah milisaat, ia berkuat kuasa apabila auto_eject_host ditetapkan kepada benar, lalai ialah 30000 milisaat;

server_failure_limit：Redis连续超时的次数，超过这个次数就视其为无法连接，如果auto_eject_hosts设置为true，那么此Redis会被移除；

servers：一个pool中的服务器的地址、端口和权重的列表，包括一个可选的服务器的名字，如果提供服务器的名字，将会使用它决定server的次序，从而提供对应的一致性hash的hash ring。否则，将使用server被定义的次序，可以通过两种字符串格式指定’host:port:weight’或者’host:port:weight name’。一般都是使用第二种别名的方式，这样当其中某个Redis节点出现问题时，可以直接添加一个新的Redis节点但服务器名字不要改变，这样twemproxy还是使用相同的服务器名称进行hash ring，所以其他数据节点的数据不会出现问题（只有挂点的机器数据丢失）。

PS：要严格按照Twemproxy配置文件的格式来，不然就会有语法错误；另外，在Twemproxy的配置文件中可以同时设置代理Redis集群或Memcached集群，只需要定义不同的配置段即可。

启动twemproxy (nutcracker)

刚已经加好了配置文件，现在测试下配置文件：

[root@www twemproxy]# /etc/twemproxy/sbin/nutcracker -tnutcracker: configuration file 'conf/nutcracker.yml' syntax is ok

说明配置文件已经成功，现在开始运行nutcracker：

[root@www ~]# /etc/twemproxy/sbin/nutcracker -c /etc/twemproxy/conf/nutcracker.yml -p /var/run/nutcracker.pid -o /var/log/nutcracker.log -d选项说明:

-h, –help                #查看帮助文档，显示命令选项;-V, –version             #查看nutcracker版本;-c, –conf-file=S         #指定配置文件路径 (default: conf/nutcracker.yml);-p, –pid-file=S          #指定进程pid文件路径，默认关闭 (default: off);-o, –output=S            #设置日志输出路径，默认为标准错误输出 (default: stderr);-d, –daemonize           #以守护进程运行;-t, –test-conf           #测试配置脚本的正确性;-D, –describe-stats      #打印状态描述;-v, –verbosity=N         #设置日志级别 (default: 5, min: 0, max: 11);-s, –stats-port=N        #设置状态监控端口，默认22222 (default: 22222);-a, –stats-addr=S        #设置状态监控IP，默认0.0.0.0 (default: 0.0.0.0);-i, –stats-interval=N    #设置状态聚合间隔 (default: 30000 msec);-m, –mbuf-size=N         #设置mbuf块大小，以bytes单位 (default: 16384 bytes);

PS:一般在生产环境中，都是使用进程管理工具来进行twemproxy的启动管理，如supervisor或pm2工具，避免当进程挂掉的时候能够自动拉起进程。

验证是否正常启动

[root@www ~]# ps aux | grep nutcrackerroot     20002  0.0  0.0  19312   916 ?        Sl   18:48   0:00 /etc/twemproxy/sbin/nutcracker -c /etc/twemproxy/conf/nutcracker.yml -p /var/run/nutcracker.pid -o /var/log/nutcracker.log -d
root     20006  0.0  0.0 103252   832 pts/0    S+   18:48   0:00 grep nutcracker
[root@www ~]# netstat -nplt | grep 22122tcp        0      0 0.0.0.0:22122               0.0.0.0:*                   LISTEN      20002/nutcracker

Twemproxy代理Redis集群

这里我们使用第一种方案在同一台主机上测试Twemproxy代理Redis集群，一个twemproxy和两个Redis节点（想添加更多的也可以）。Twemproxy就是用上面的配置了，下面只需要增加两个Redis节点。

安装配置Redis

在安装Redis之前，需要安装Redis的依赖程序tcl，如果不安装tcl在Redis执行make test的时候就会报错的哦。

[root@www ~]# yum install -y tcl[root@www ~]# wget https://github.com/antirez/redis/archive/3.2.0.tar.gz[root@www ~]# tar xvf 3.2.0.tar.gz -C /usr/local[root@www ~]# cd /usr/local/[root@www local]# mv redis-3.2.0 redis[root@www local]# cd redis[root@www redis]# make[root@www redis]# make test[root@www redis]# make install

配置两个Redis节点

[root@www ~]# mkdir /data/redis-6546[root@www ~]# mkdir /data/redis-6547[root@www ~]# cat /data/redis-6546/redis.confdaemonize yes
pidfile /var/run/redis/redis-server.pid
port 6546bind 0.0.0.0
loglevel notice
logfile /var/log/redis/redis-6546.log

[root@www ~]# cat /data/redis-6547/redis.confdaemonize yes
pidfile /var/run/redis/redis-server.pid
port 6547bind 0.0.0.0
loglevel notice
logfile /var/log/redis/redis-6547.log

PS：简单提供两个Redis配置文件，如果开启了Redis认证，那么在twemproxy中也需要填写Redis密码。

启动两个Redis节点

[root@www ~]# /usr/local/redis/src/redis-server /data/redis-6546/redis.conf[root@www ~]# /usr/local/redis/src/redis-server /data/redis-6547/redis.conf[root@www ~]# ps aux | grep redisroot     23656  0.0  0.0  40204  3332 ?        Ssl  20:14   0:00 redis-server 0.0.0.0:6546              
root     24263  0.0  0.0  40204  3332 ?        Ssl  20:16   0:00 redis-server 0.0.0.0:6547

验证Twemproxy读写数据

首先twemproxy配置项中servers的主机要配置正确，然后连接Twemproxy的22122端口即可测试。

[root@www ~]# redis-cli -p 22122127.0.0.1:22122> set key vlaue
OK
127.0.0.1:22122> get key"vlaue"127.0.0.1:22122> FLUSHALL
Error: Server closed the connection
127.0.0.1:22122> quit

上面我们set一个key，然后通过twemproxy也可以获取到数据，一切正常。但是在twemproxy中使用flushall命令就不行了，不支持。

然后我们去找分别连接两个redis节点，看看数据是否出现在某一个节点上了，如果有，就说明twemproxy正常运行了。

[root@www ~]# redis-cli -p 6546127.0.0.1:6546> get key
(nil)
127.0.0.1:6546>

由上面的结果我们可以看到，数据存储到6547节点上了。目前没有很好的办法明确知道某个key存储到某个后端节点了。

如何Reload twemproxy？

Twemproxy没有为启动提供脚本，只能通过命令行参数启动。所以，无法使用对twemproxy进行reload的操作，在生产环境中，一个应用无法reload（重载配置文件）是一个灾难。当你对twemproxy进行增删节点时如果直接使用restart的话势必会影响线上的业务。所以最好的办法还是reload，既然twemproxy没有提供，那么可以使用kill命令带一个信号，然后跟上twemproxy主进程的进行号即可。

kill -SIGHUP PID

注意，PID就是twemproxy master进程。

Atas ialah kandungan terperinci Bagaimana untuk melaksanakan pembahagian data Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!