redis cluster
是親生的群集方案,目前,在高可用和穩定性方面,都有了很大的進步。根據統計和觀察,採用redis cluster
架構的公司和社群越來越多,已經成為事實的標準。它的主要特點就是去中心化,無需proxy
代理。其中一個主要設計目標就是達到線性可擴展性(linear scalability)。
僅靠redis cluster
伺服器本身,並不能完成官方承諾的功能。廣義的redis cluster
應該既包含redis
伺服器,又包含客戶端實作例如jedis
等。它們是一個整體。
分散式儲存無非就是處理分片和副本。 對redis cluster
來說,核心概念就是槽(slot),了解了它,基本上就了解了叢集的管理方式。
當了解這些特性以後,維運上其實是更簡單了。我們先看下比較明顯的優缺點。
1、不再需要額外的Sentinel
集群,為使用者提供了一致的方案,減少了學習成本。
2、去中心架構,節點對等,叢集可支援上千個節點。
3、抽象化出了slot
概念,針對slot
#進行運作操作。
4、副本功能能夠實現自動故障轉移,大部分情況下無需人工介入。
1、客戶端要快取部分數據,實作Cluster
協議,相對複雜。
2、資料是透過非同步複製的,無法保證資料的強一致性。
3、資源隔離困難,經常流量不均衡,尤其是多個業務共用叢集的時候。數據不知道在哪裡,針對熱點數據,也無法透過專案優化
完成。
4、從庫是完全的冷備,無法分擔讀取操作,真是太太浪費了。需要做額外工作。
5、MultiOp
和Pipeline
支援有限,舊程式碼要是進行架構升級,要小心了。
6、資料遷移是基於key
而不是基於slot
的,過程較慢。
從槽到key
,定位過程明顯就是一個雙層的路由。
redis cluster
和常用的一致性hash
沒什麼關係,它主要採用了雜湊槽的概念。當需要在其中存取一個key
時,redis
客戶端會先對這個key
採用crc16
演算法算出一個值,然後對這個值進行mod
操作。
crc16(key)mod 16384
所以,每個key
都會落在其中的一個hash
插槽上。 16384 等同於2^14(16k),redis
節點發送心跳包時,需要把所有的槽資訊放在這個心跳包裡,所以要竭盡全力的優化,感興趣的可以看下為什麼預設的槽數量是16384 。
上面談到,redis cluster
共定義了 16384 個槽,所有的叢集運算都是圍繞著這個槽資料進行編碼。服務端使用一個簡單的陣列來儲存這些資訊。
對於判斷有無的操作,使用bitmap
來儲存是最節省空間的。 redis cluster
就是使用一個叫做slot
的陣列來保存目前節點是否持有了這個槽。
陣列的長度為 16384/8=2048 Byte
,那麼就可以使用 0 或 1 來識別本節點對某個槽是否擁有。
其實,只需要第一份資料ClusterState
也能完成操作,保存另一個維度的Slot
數組,能夠方便編碼和儲存。一個節點除了會將自己負責處理的插槽記錄在兩個地方(clusterNode結構的slots和numslots),它還會將自己的slots
陣列透過訊息傳送給叢集中的其他節點,以此來告訴其他節點自己目前擁有的槽。
當資料庫中的16384 個插槽都有節點在處理時,叢集處於上線狀態(ok);相反地,如果資料庫中有任何一個插槽沒有處理,那麼叢集處於下線狀態(fail )。
當客戶端向節點發送相關命令時,接收命令的節點會計算出命令要處理的key
屬於哪個槽,並檢查這個槽是否指派給了自己。如果不是自己的,會指引客戶端到正確的節點。
所以,客戶端連接叢集中的任一台機器,都能夠完成操作。
假如我們要組裝一個3分片的集群,每個分片都有一個副本。那麼總共需要的node
實例就有 3*2=6 個。 redis
可以透過指定設定檔的方式啟動,我們所做的工作就是修改設定檔。
複製6份預設的設定檔。
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-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
的速度特别的快。一般越快的东西,出问题的时候造成的后果越大。
不久之前,寫過一篇針對於redis
的規範:《Redis規範,這可能是最中肯的了》。規範和架構一樣,適合自己公司環境的,才是最好的,但會提供一些起碼的想法。
嚴格禁止的東西,通常都是前人踩坑的地方。除了這篇規範的內容,對於redis-cluster
,補充以下幾點。
1、redis cluster
號稱能夠支援1k個節點,但你最好不要這麼做。當節點數量增加到10,就能夠感受到叢集的一些抖動。這麼大的集群證明你的業務已經很牛x了,考慮一下客戶端分片吧。
2、一定要避免產生熱點,如果流量全部打到了某個節點,後果一般很嚴重。
3、大key
不要放redis
,它會產生大量的慢查詢,影響正常的查詢。
4、如果你不是作為存儲,快取一定要設定過期時間。佔著茅坑不拉屎的感覺是非常討厭的。
5、大流量,不要開aof
,開rdb
即可。
6、redis cluster
的操作,少用pipeline
,少用multi-key
,它們會產生大量不可預料的結果。
以上是Redis中怎麼安裝一個六節點集群的詳細內容。更多資訊請關注PHP中文網其他相關文章!