Redis-集群与高可用

1- 水平分区 VS 垂直分区

分区是分割数据到多个Redis实例的处理过程,因此每个实例只保存key的一个子集。有两种分区方式:水平分区、垂直分区。

1.1 分区的优势与不足
  1. 优势

通过利用多台计算机内存的和值,允许我们构造更大的数据库。
通过多核和多台计算机,允许我们扩展计算能力;通过多台计算机和网络适配器,允许我们扩展网络带宽

  1. 不足

涉及多个key的操作通常是不被支持的:

  • 当两个set映射到不同的redis实例上时,你就不能对这两个set执行交集操作。
  • 涉及多个key的redis事务不能使用。
  • 当使用分区时,数据处理较为复杂,比如你需要处理多个rdb/aof文件,并且从多个实例和主机备份持久化文件。
  • 增加或删除容量也比较复杂。redis集群大多数支持在运行时增加、删除节点的透明数据平衡的能力,但是类似于客户端分区、代理等其他系统则不支持这项特性。
1.2 水平分区

水平分区是根据一些规则把同一业务单元的Key拆分到不同的Redis实例上。

  1. 按Range水平分区

最简单的分区方式是按范围分区,就是映射一定范围的对象到特定的Redis实例
比如,ID从0到10000的用户会保存到实例R0,ID从10001到 20000的用户会保存到R1,以此类推
。这种方式是可行的,并且在实际中使用,不足就是要有一个区间范围到实例的映射表。这个表要被管理,同时还需要各种对象的映射表,通常对Redis来说并非是好的方法。优点:规则简单、数据均衡性较好、比较容易扩展;缺点:请求的负载不一定均衡,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大。

  1. 对Key哈希水平切分

按照Key进行Hash,支持任意类型的Key,然后对得到的Hash值进行取模运算,分配到不同Redis实例上。优点:规则简单、数据均衡性较好、请求均匀性较好;缺点是:不容易扩展,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移。

1.3 垂直分区

垂直分区就是把一个Redis实例上的不同业务单元的Key拆分到不同的Redis实例上。

2- 持久化

Redis持久化方案主要有RDB和AOF,两者毫无关系,完全独立运行。

2.1 RDB文件

RDB是整个内存数据的压缩过的某一时刻的Snapshot快照,可以配置复合的触发RDB写的条件,默认是1分钟内改了1万次,或5分钟内改了10次,或15分钟内改了1次。

  1. RDB写入时,会连内存一起Fork出一个新进程,遍历新进程内存中的数据写文件,这样就解决了些Snapshot过程中又有新的写入请求进来的问题。

  2. RDB会先写到临时文件,完了再Rename,这样外部程序对RDB文件的备份和传输过程是安全的。而且即使写新快照的过程中Server被强制关掉了,旧的RDB文件还在。

  3. 可配置是否进行压缩,压缩方法是字符串的LZF算法,以及将string形式的数字变回int形式存储。

  4. 停止RDB保存规则的方法:redis-cli config set save “”

2.2 AOF文件

操作日志,记录所有有效的写操作,等于mysql的binlog,格式就是明文的Redis协议的纯文本文件。

  1. 一般配置成每秒调用一次fdatasync将kernel的文件缓存刷到磁盘。当操作系统非正常关机时,文件可能会丢失不超过2秒的数据。 如果设为fsync always,性能很低,只剩几百TPS。如果设为no,靠操作系统自己的sync同步,Linux系统一般30秒一次。

  2. AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件,最后再rename), 遍历新进程的内存中数据,每条记录的Set语句。默认配置是当AOF文件大小是上次rewrite后大小的一倍,且文件大于64M时触发。

  3. Redis协议,如set mykey hello, 将持久化成*3 $3 set $5 mykey $5 hello, 第一个数字代表这条语句有多少元,其他的数字代表后面字符串的长度。这样的设计,使得即使在写文件过程中突然关机导致文件不完整,也能自我修复,执行redis-check-aof即可。

2.3 RDB vs AOF

综上:

  1. RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。

  2. 因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。

  3. 如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本简单load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。

  4. 如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。

3- 高可用与故障切换

Master-Slave复制与Fail-Over来实现真正的高可用

3.1 Master-Slave复制

slave可以在配置文件、启动命令行参数、以及redis-cli执行SlaveOf指令来设置自己是奴隶,设置 Slaveof no one,slave会立马变身master;Slave只可以接收客户端的读请求,兼有负载均衡的功能

  1. 复制速度:测试表明同步延时非常小,Master指令一旦执行完毕就会立刻写AOF文件和向Slave转发,除非Slave自己被阻塞住了。

  2. 复制过程:先执行一次Master快照RDB的全同步 — slave请求Master的一个RDB Snapshot文件,slave接收完毕后,清除掉自己的旧数据,然后将RDB载入内存。**再进行增量同步 **— master作为一个普通的client连入slave,将所有写操作转发给slave,没有特殊的同步协议

详细步骤:
1) 在Slave启动并连接到Master之后,它将主动发送一个SYNC命令。
2)此后Master将启动后台存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕后,Master将传送整个数据库文件到Slave,以完成一次完全同步。
3) 而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。
4)此后,Master继续将所有已经收集到的修改命令,和新的修改命令依次传送给Slaves,Slave将在依次执行这些数据修改命令,从而达到最终的数据同步。
5)如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行。

  1. 特点
  • 同一个Master可以同步多个Slaves。
  • Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。
  • Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间,客户端仍然可以提交查询或修改请求。
  • SlaveServer同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据。
  • 为了分载Master的读操作压力,Slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由Master来完成。即便如此,系统的伸缩性还是得到了很大的提高。
  • Master可以将数据保存操作交给Slaves完成,从而避免了在Master中要有独立的进程来完成此操作。
  1. 潜在的问题
    Slave从库在连接Master主库时,Master会进行内存存盘生成快照,然后把整个快照文件发给Slave,也就是没有象MySQL那样有复制位置的概念,即无增量复制,这会给整个集群搭建带来非常多的问题。比如Slave由于网络或者其它原因与Master断开了连接,那么当 Slave进行重新连接时,需要重新获取整个Master的内存快照,Slave所有数据跟着全部清除,然后重新建立整个内存表,一方面Slave恢复的时间会非常慢,另一方面也会给主库带来压力。
3.2 Fail-Ove(sentinel)

Redis-sentinel是2.6版开始加入的另一组独立运行的节点,提供自动Fail Over的支持

3.2.1 发现 master/slave及其他sentinel
  1. master地址在sentinel.conf里, sentinel会每10秒一次向master发送INFO,知道master的slave有哪些。
  1. 如果master已经变为slave,sentinel会分析INFO的应答指向新的master。
  2. 另外,sentinel会在master上建一个pub/sub channel,名为”sentinel:hello”,通告各种信息,sentinel们也是通过接收pub/sub channel上的sentinel的信息发现彼此,因为每台sentinel每5秒会发送一次自己的host信息,宣告自己的存在。
3.2.2 监测与切换过程:
  1. Sentinel每秒钟对所有master,slave和其他sentinel执行Ping,redis-server节点要应答。
  1. 如果某一台Sentinel没有在30秒内(可配置得短一些哦)收到上述正确应答,它就会认为master处于sdown状态(主观Down),它向其他sentinel询问是否也认为该master倒了(SENTINEL is-master-down-by-addr );
  2. 如果quonum台(默认是2)sentinel在5秒钟内都这样认为,就会认为master真是odown了(客观Down)。
  3. 此时会选出一台sentinel作为Leader执行fail-over, Leader会从slave中选出一个提升为master(执行slaveof no one),然后让其他slave指向它(执行slaveof new master)。
3.3 Redis高可用与故障转移架构设计

基于Sentinel + master/slave



上面虽然在server端完成了故障转移,但是对于客户端程序来说,Master切换后client并不知道新Master的IP地址,一种办法是client在访问Server之前都要询问一下Sentinel,获取Master的最新IP。但是明显获取一次数据需要访问两次,网络资源还是比较宝贵的,有一种对client无感更经济实惠的切换方法:VIP漂移。

基于Sentinel + master/slave + VIP漂移

VIP方案是,redis系统对外始终是同一ip地址,当redis进行故障转移时,需要做的是将VIP从之前的redis服务器漂移到现在新的主redis服务器上。

故障前

当前redis系统中主redis的ip地址是192.168.56.101,那么VIP(192.168.56.250)指向192.168.56.101,客户端程序用VIP(192.168.56.250)地址连接redis,实际上连接的就是当前主redis,这样就避免了向sentinel发送请求。


故障后

当主redis宕机,进行故障转移时,192.168.56.102这台服务器上的redis提升为主,这时VIP(192.168.56.250)指向192.168.56.102,这样客户端程序不需要修改任何代码,连接的是192.168.56.102这台主redis。

如何实现VIP漂移?

  1. 以使用redis sentinel的一个参数client-reconfig-script,这个参数配置执行脚本,sentinel在做failover的时候会执行这个脚本。
  1. 漂移VIP也可以使用keepalived软件来实现。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容

  • 1.1 资料 ,最好的入门小册子,可以先于一切文档之前看,免费。 作者Antirez的博客,Antirez维护的R...
    JefferyLcm阅读 16,962评论 1 51
  • 本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍。之后概...
    kelgon阅读 60,924评论 24 626
  • ## Generated by install_server.sh ## # Redis configuratio...
    依然饭太稀阅读 1,968评论 0 5
  • 思念无果,大雨滂沱 喜你为疾,药石无医
    女匪阅读 182评论 0 0
  • 最好听的一句,就像某个一本正经的人讲了一个冷笑话逗笑了所有人,而他自己却不笑:-D
    梧桐小羽阅读 165评论 0 0