Bagaimana untuk memasang kluster enam nod dalam Redis

Pengenalan

redis cluster ialah penyelesaian kluster asli Pada masa ini, ia telah mencapai kemajuan yang besar dari segi ketersediaan dan kestabilan yang tinggi. Mengikut statistik dan pemerhatian, semakin banyak syarikat dan komuniti menggunakan seni bina redis cluster, yang telah menjadi standard de facto. Ciri utamanya ialah desentralisasi dan tidak memerlukan proxyejen. Salah satu matlamat reka bentuk utama adalah untuk mencapai skalabiliti linear.

Hanya bergantung pada redis cluster pelayan itu sendiri tidak dapat memenuhi fungsi yang dijanjikan secara rasmi. Dalam erti kata yang luas, redis cluster hendaklah merangkumi kedua-dua redis pelayan dan pelaksanaan pelanggan seperti jedis, dsb. Mereka adalah keseluruhan.

Storan teragih tidak lebih daripada menangani serpihan dan replika. Untuk redis cluster, konsep teras adalah slot Jika anda memahaminya, anda akan memahami kaedah pengurusan kluster.

Kebaikan dan Kelemahan

Selepas memahami ciri ini, operasi dan penyelenggaraan sebenarnya akan menjadi lebih mudah. Mari kita lihat kelebihan dan kekurangan yang lebih jelas dahulu.

Kelebihan

1. Tiada kluster Sentinel tambahan diperlukan, memberikan pengguna penyelesaian yang konsisten dan mengurangkan kos pembelajaran.

2. Seni bina terpencar, nod adalah peer-to-peer dan kluster boleh menyokong beribu-ribu nod.

3. Abstrak konsep slot dan lakukan operasi operasi dan penyelenggaraan pada slot.

4. Fungsi replika boleh merealisasikan kegagalan automatik, tanpa campur tangan manual dalam kebanyakan kes.

Kelemahan

1. Pelanggan perlu menyimpan beberapa data dan melaksanakan protokol Cluster, yang agak rumit.

2. Data disalin secara tak segerak, dan ketekalan data yang kukuh tidak boleh dijamin.

3. Pengasingan sumber sukar dan trafik sering tidak seimbang, terutamanya apabila berbilang perniagaan berkongsi kelompok. Saya tidak tahu di mana data itu, dan untuk data panas, ia tidak boleh dilengkapkan melalui 专项优化.

4. Pangkalan data hamba benar-benar siap sedia dan tidak boleh berkongsi operasi baca Ia benar-benar membazir. Kerja tambahan diperlukan.

5, MultiOp dan Pipeline mempunyai sokongan terhad Jika anda ingin meningkatkan seni bina kod lama, berhati-hati.

6. Penghijrahan data adalah berdasarkan key bukannya slot dan prosesnya lebih perlahan.

Prinsip Asas

Dari slot ke key, proses penentududukan jelas sekali adalah penghalaan dua lapisan.

Penghalaan utama

redis cluster tiada kaitan dengan konsistensi yang biasa digunakan hash Ia terutamanya menggunakan konsep slot cincang. Apabila key perlu diakses, klien redis akan terlebih dahulu mengira nilai menggunakan algoritma key menggunakan algoritma crc16 dan kemudian melakukan operasi mod pada nilai ini.

crc16(key)mod 16384

Jadi, setiap key akan mendarat di salah satu slot hash. 16384 bersamaan dengan 2^14 (16k) redis Apabila nod menghantar paket degupan jantung, ia perlu meletakkan semua maklumat slot dalam paket degupan jantung ini, jadi segala usaha mesti dilakukan untuk mengoptimumkannya. anda boleh melihat sebab nombor lalai slot ialah 16384.

Prinsip mudah bahagian pelayan

Seperti yang dinyatakan di atas, redis clustermentakrifkan sejumlah 16384 slot dan semua operasi kelompok dikodkan di sekitar data slot ini. Pelayan menggunakan tatasusunan mudah untuk menyimpan maklumat ini.

Untuk operasi menentukan sama ada terdapat, menggunakan bitmap untuk menyimpan adalah yang paling menjimatkan ruang. redis cluster ialah menggunakan tatasusunan yang dipanggil slot untuk menyimpan sama ada nod semasa memegang slot ini. Panjang tatasusunan

ialah 16384/8=2048 Byte, maka anda boleh menggunakan 0 atau 1 untuk mengenal pasti sama ada nod ini memiliki slot tertentu.

Malah, hanya sekeping data pertama ClusterState diperlukan untuk menyelesaikan operasi Menyimpan tatasusunan Slot dimensi lain boleh memudahkan pengekodan dan penyimpanan. Selain merekod slot, ia bertanggungjawab untuk memproses di dua tempat (slot dan numslot struktur clusterNode), nod juga akan menghantar tatasusunan slots sendiri ke nod lain dalam kelompok melalui mesej untuk memberitahu nod lain Slot yang anda milik sekarang.

Apabila semua 16384 slot dalam pangkalan data sedang diproses oleh nod, kluster berada dalam keadaan dalam talian (ok); jika mana-mana slot dalam pangkalan data tidak diproses, kluster berada dalam keadaan luar talian (gagal).

Apabila klien menghantar arahan yang berkaitan kepada nod, nod yang menerima arahan akan mengira slot mana key yang akan diproses oleh perintah itu dimiliki, dan semak sama ada slot ini diperuntukkan kepada dirinya sendiri. Jika ia bukan milik anda, ia akan mengarahkan klien ke nod yang betul.

Jadi, pelanggan boleh melengkapkan operasi dengan menyambung ke mana-mana mesin dalam kelompok.

Memasang gugusan 6-nod

Persediaan

Andaikan kita ingin memasang gugusan 3-serpihan, dengan satu replika untuk setiap serpihan. Maka jumlah kejadian node yang diperlukan ialah 3*2=6. redisIa boleh dimulakan dengan menentukan fail konfigurasi Apa yang kami lakukan ialah mengubah suai fail konfigurasi.

Salin 6 salinan fail konfigurasi lalai.

for i in {0..5}
do
cp redis.conf  redis-700$i.conf
done

修改其中的配置文件内容，拿redis-7000.conf来说，我们要启用它的cluster模式。

cluster-enabled yes
port 7000
cluster-config-file nodes-7000.conf

nodes-7000.conf会保存一些集群信息到当前节点，所以需要独立。

启动&关闭

同样的，我们使用脚本来启动它。

for i in {0..5}
do
nohup ./redis-server redis-700$i.conf &
done

为了演示，我们暴力把它关闭。

ps -ef| grep redis | awk '{print $2}' | xargs kill -9

组合集群

我们使用redis-cli进行集群的组合。redis将自动完成这个过程。这一系列的过程，是通过发送指令给每个节点进行组合的。

./redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

几个高级原理

节点故障

集群中的每个节点都会定期地向集群中的其他节点发送ping消息，以此来检测对方是否在线，如果接收ping消息的节点没有在规定的时间内返回pong消息，那么发送ping消息的节点就会将接收ping消息的节点标记为疑似下线（PFAIL）。

如果在一个集群里面，半数以上节点都将某个主节点 x 报告为疑似下线，那么这个主节点x将被标记为已下线（FAIL），将x标记为FAIL的节点会向集群广播一条关于 x 的FAIL消息，所有收到这条FAIL消息的节点都会立即将 x 标记为FAIL。

大家可以注意到这个过程，与 es 和 zk 的节点判断类似，都是半数以上才进行判断，所以主节点的数量一般都是奇数。由于没有最小组群配置，理论上会有脑裂（暂时并未遇到过）。

主从切换

当一个节点发现自己的主节点进入fail状态，将会从这个节点的从节点当中，选出一台，执行slaveof no one命令，变身为主节点。

新的节点完成自己的槽指派以后，会向集群广播一条pong消息，以便让其他节点立即知道自己的这些变化。它告诉别人：我已经是主节点了，我已经接管了有问题的节点，成为了它的替身。

redis内部对集群的这些管理，大量使用了已经定义好的这些指令。所以这些指令不仅仅供我们从命令行使用，redis自己内部也用。

数据同步

当一台从机连接到master之后，会发送一个sync指令。master在收到这个指令后，会在后台启动存盘进程。执行完毕后，master将整个数据库文件传输到slave，这样就完成了第一次全量同步。

接下来，master会把自己收到的变更指令，依次传送给slave，从而达到数据的最终同步。从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

数据丢失

redis cluster中节点之间使用异步复制，并没有类似kafka这种ack的概念。节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升，完成这个过程注定了需要时间。在发生故障的过程中就容易存在窗口，导致丢失写入的数据。比如以下两种情况。

一、命令已经到到master，此时数据并没有同步到slave，master会对客户端回复ok。如果这个时候主节点宕机，那么这条数据将会丢失。redis这样做会避免很多问题，但对一个对数据可靠性要求较高的系统，是不可忍受的。

二、由于路由表是在客户端存放的，存在一个时效问题。如果分区导致一个节点不可达，提升了某个从节点，但原来的主节点在这个时候又可以用了（并未完成failover）。如果客户端的路由表没有及时更新，那么写入错误的节点可能导致数据丢失。

所以redis cluster在通常情况下运行的很好，在极端情况下某些值丢失问题，目前无解。

复杂的运维

redis cluster的运维非常的繁杂，虽然已经进行了抽象，但这个过程依然不简单。有些指令，必须在详细了解它的实现原理之后，才能真正放心的去用。

扩容会用到的一些命令。在实际使用的过程中，可能需要多次频繁地输入这些命令，且输入的过程中还要监视它的状态，所以基本上是不可能人工跑这些命令的。

运维的入口有两个。一个是使用redis-cli连接任意一台，然后发送cluster打头的命令，这部分命令大多数是对槽进行操作。 在开始组合集群时，就是反复调用这些命令进行的具体逻辑执行。

另外一个入口是使用redis-cli命令，加上--cluster参数和指令。这种形式主要是用来管控集群节点信息 ，比如增删节点等。所以推荐使用这种方式。

redis cluster提供了非常复杂的命令，难于操作和记忆。推荐使用类似CacheCloud的工具进行管理。

下面是几个例子。

通过向节点 A 发送 CLUSTER MEET 命令，客户端可以让接收命令的节点 A 将另一个节点 B 添加到节点 A 当前所在的集群里面：

CLUSTER MEET  127.0.0.1 7006

通过cluster addslots命令，可以将一个或者多个槽指派给某个节点负责。

127.0.0.1:7000> CLUSTER ADDSLOTS 0 1 2 3 4 . . . 5000

设置从节点。

CLUSTER REPLICATE <node_id>

redis-cli —cluster

redis-trib.rb是官方提供的Redis Cluster的管理工具，但最新版本已经推荐使用redis-cli进行操作。

向集群中添加新节点

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7007 --cluster-replicas 1

从集群中删除节点

redis-cli --cluster del-node 127.0.0.1:7006 54abb85ea9874af495057b6f95e0af5776b35a52

迁移槽到新的节点

redis-cli --cluster reshard 127.0.0.1:7006 --cluster-from 54abb85ea9874af495057b6f95e0af5776b35a52 --cluster-to 895e1d1f589dfdac34f8bdf149360fe9ca8a24eb  --cluster-slots 108

类似的命令还有很多。

create：创建集群 check：检查集群 info：查看集群信息 fix：修复集群 reshard：在线迁移slot rebalance：平衡集群节点slot数量 add-node：添加新节点 del-node：删除节点 set-timeout：设置节点的超时时间 call：在集群所有节点上执行命令 import：将外部redis数据导入集群

其他方案概览

主从模式

redis最早支持的，就是M-S模式，也就是一主多从。redis单机qps可达到 10w+，但是在某些高访问量场景下，依然不太够用。一般通过读写分离来增加slave，减少主机的压力。

既然是主从架构，就面临着同步问题，redis主从模式的同步分为全同步和部分同步。当刚创建一个从机的时候，不可避免的要进行一次全量同步。等全量同步结束之后，进入增量同步阶段。这个和redis cluster是没什么区别的。

这种模式还是比较稳定的，但要额外做一些工作。用户需要自行开发主从切换的功能，也就是使用哨兵去探测每个实例的健康状况，然后通过指令进行集群状态的改变。

当集群规模增大，主从模式会很快遇到瓶颈。所以一般会采用客户端hash的方法进行扩展，包括类似于memcached的一致性哈希。

客户端hash的路由可能会很复杂，通常会通过发布jar包或者配置的方式维护这些meta信息，这也给线上环境增加了很多不确定性。

不过，通过加入类似ZK主动通知的功能，将配置维护在云端，可以显著降低风险。笔者曾经维护过的几千个redis节点，就是用这种方式进行管理的。

代理模式

代码模式在redis cluster出现之前，非常流行，比如codis。代理层通过把自己模拟成一个redis，接收来自客户端的请求，然后按照自定义的路由逻辑进行数据分片以及迁移，而业务方不需要改动任何代码。除了能够平滑的进行扩容，一些主从切换、FailOver的功能也在代理层完成，客户端甚至可以没有任何感知。这类程序又称为分布式中间件。

一个典型的实现如下图，背后的redis集群甚至可以是混合的。

但这种方式的缺点也是显而易见的。首先，它引入了一个新的代理层，在结构上、运维上都显复杂。需要进行大量的编码，比如failover、读写分离、数据迁移等。另外，proxy层的加入，对性能也有相应的损耗。

多个proxy一般使用lvs等前置进行负载均衡的设计，如果proxy层的机器很少而后端redis的流量很高，那么网卡会成为主要的瓶颈。

Nginx也可以作为redis的代理层，比较专业的说法叫做Smart Proxy。这种方式较为偏门，如果你对nginx比较熟悉，不失为一种优雅的做法。

使用限制和坑

redis的速度特别的快。一般越快的东西，出问题的时候造成的后果越大。

Tidak lama dahulu, saya menulis spesifikasi untuk redis: "Spesifikasi Redis, ini mungkin yang paling berkaitan". Spesifikasi adalah sama seperti seni bina Yang sesuai dengan persekitaran syarikat anda adalah yang terbaik, tetapi beberapa idea asas akan disediakan.

Perkara yang dilarang sama sekali adalah tempat yang telah dipijak oleh pendahulunya. Sebagai tambahan kepada kandungan spesifikasi ini, untuk redis-cluster, perkara berikut ditambah.

1. redis cluster mendakwa boleh menyokong 1k nod, tetapi lebih baik anda tidak melakukan ini. Apabila bilangan nod meningkat kepada 10, anda boleh merasakan sedikit kegelisahan dalam kelompok. Kelompok yang besar itu membuktikan bahawa perniagaan anda sudah sangat baik.

2. Pastikan anda mengelakkan kawasan panas Jika semua trafik mencecah nod tertentu, akibatnya biasanya serius.

3. Jangan letak key dalam redis yang besar, ia akan menjana sejumlah besar pertanyaan perlahan dan menjejaskan pertanyaan biasa.

4. Jika anda tidak menggunakannya sebagai storan, cache mesti menetapkan masa tamat tempoh. Perasaan menduduki tandas dan tidak mengambil najis adalah sangat menjengkelkan.

5 Untuk trafik yang besar, jangan dayakan aof, hanya dayakan rdb.

6. Gunakan kurang redis cluster dan kurang pipeline untuk operasi multi-key, kerana ia akan menghasilkan banyak hasil yang tidak dapat diramalkan.

Atas ialah kandungan terperinci Bagaimana untuk memasang kluster enam nod dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!