近千节点的Redis集群运维来自优酷蓝鲸的经验总结Word格式文档下载.docx
- 文档编号:13563896
- 上传时间:2022-10-11
- 格式:DOCX
- 页数:4
- 大小:20.33KB
近千节点的Redis集群运维来自优酷蓝鲸的经验总结Word格式文档下载.docx
《近千节点的Redis集群运维来自优酷蓝鲸的经验总结Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《近千节点的Redis集群运维来自优酷蓝鲸的经验总结Word格式文档下载.docx(4页珍藏版)》请在冰豆网上搜索。
以下是从节点正常的主从同步流程日志:
17:
22:
49.763*MASTER&
lt;
-&
gt;
SLAVEsyncstarted17:
49.764*NonblockingconnectforSYNCfiredtheevent.17:
49.764*MasterrepliedtoPING,replicationcancontinue...17:
49.764*Partialresynchronizationnotpossible(nocachedmaster)17:
49.765*Fullresyncfrommaster:
c9fabd3812295cc1436af69c73256011673406b9:
174522475324717:
23:
42.223*MASTER&
SLAVEsync:
receiving1811656499bytesfrommaster17:
24:
04.484*MASTER&
Flushingolddata17:
25.646*MASTER&
LoadingDBinmemory17:
27:
21.541*MASTER&
Finishedwithsuccess17:
28:
22.818#MASTERtimeout:
nodatanorPINGreceived...17:
22.818#Connectionwithmasterlost.17:
22.818*Cachingthedisconnectedmasterstate.17:
22.818*ConnectingtoMASTERxxx.xxx.xxx.xxx:
xxxx17:
22.818*MASTER&
22.819*NonblockingconnectforSYNCfiredtheevent.17:
22.824*MasterrepliedtoPING,replicationcancontinue...17:
22.824*Tryingapartialresynchronization(requestc9fabd3812295cc1436af69c73256011673406b9:
1745240101942).17:
22.825*Successfulpartialresynchronizationwithmaster.以上日志是以从节点的视角呈现的,因为以从节点的角度更能反映主从同步流程,所以以下的分析也以从节点的视角为主。
日志很清楚的说明了Redis主从同步的流程,主要步骤为:
从节点接收RDB文件从节点清空旧数据从节点加载RDB文件到此一次全量主从同步完成。
等等日志中“Connectionwithmasterlost”是什么鬼,为什么接下来又进行了一次主从同步。
“Connectionwithmasterlost”的字面意思是从节点与主节点的连接超时。
在Redis中主从节点需要互相感知彼此的状态,这种感知是通过从节点定时PING主节点并且主节点返回PONG消息来实现的。
那么当主节点或者从节点因为其他原因不能及时收到PING或者PONG消息时,则认为主从连接已经断开。
问题又来了何为及时,Redis通过参数repl-timeout来设定,它的默认值是60s。
Redis配置文件(redis.conf)中详细解释了repl-timeout的含义:
#Thefollowingoptionsetsthereplicationtimeoutfor:
##1)BulktransferI/OduringSYNC,fromthepointofviewofslave.#2)Mastertimeoutfromthepointofviewofslaves(data,pings).#3)Slavetimeoutfromthepointofviewofmasters(REPLCONFACKpings).##Itisimportanttomakesurethatthisvalueisgreaterthanthevalue#specifiedforrepl-ping-slave-periodotherwiseatimeoutwillbedetected#everytimethereislowtrafficbetweenthemasterandtheslave.##repl-timeout60我们回过头再来看上边的同步日志,从节点加载RDB文件花费将近三分钟的时间,超过了repl-timeout,所以从节点认为与主节点的连接断开,所以它尝试重新连接并进行主从同步。
部分同步这里补充一点当进行主从同步的时候Redis都会先尝试进行部分同步,部分同步失败才会尝试进行全量同步。
Redis中主节点接收到的每个写请求,都会写入到一个被称为repl_backlog的缓存空间中,这样当进行主从同步的时候,首先检查repl_backlog中的缓存是否能满足同步需求,这个过程就是部分同步。
考虑到全量同步是一个很重量级别并且耗时很长的操作,部分同步机制能在很多情况下极大的减小同步的时间与开销。
重同步问题通过上面的介绍大概了解了主从同步原理,我们在将注意力放在加载RDB文件所花费的三分钟时间上。
在这段时间内,主节点不断接收前端的请求,这些请求不断的被加入到repl_backlog中,但是因为Redis的单线程特性,从节点是不能接收主节点的同步写请求的。
所以不断有数据写入到repl_backlog的同时却没有消费。
当repl_backlog满的时候就不能满足部分同步的要求了,所以部分同步失败,需要又一次进行全量同步,如此形成无限循环,导致了主从重同步现象的出现。
不仅侵占了带宽,而且影响主节点的服务。
解决方案至此解决方案就很明显了,调大repl_backlog。
Redis中默认的repl_backlog大小为1M,这是一个比较小的值,我们的集群中曾经设置为100M,有时候还是会出现主从重同步现象,后来改为200M,一切太平。
可以通过以下命令修改repl_backlog的大小:
//200Mredis-cli-hxxx-pxxxconfigsetrepl-backlog-size209715200内存碎片首先对于绝大部分系统内存碎片是一定存在的。
试想内存是一整块连续的区域,而数据的长度可以是任意的,并且会随时发生变化,随着时间的推移,在各个数据块中间一定会夹杂着小块的难以利用的内存,所以在Redis中内存碎片是存在的。
在Redis中通过infomemory命令能查看内存及碎片情况:
#Memoryused_memory:
4221671264/*内存分配器为数据分配出去的内存大小,可以认为是数据的大小*/used_memory_human:
3.93G/*used_memoryd的阅读友好形式*/used_memory_rss:
4508459008/*操作系统角度上Redis占用的物理内存空间大小,注意不包含swap*/used_memory_peak:
4251487304/*used_memory的峰值大小*/used_memory_peak_human:
3.96G/*used_memory_peak的阅读友好形式*/used_memory_lua:
34816mem_fragmentation_ratio:
1.07/*碎片率*/mem_allocator:
jemalloc-3.6.0/*使用的内存分配器*/对于每一项的意义请注意查看注释部分,也可以参考官网上info命令memory部分。
Redis中内存碎片计算公式为:
mem_fragmentation_ratio=used_memory_rss/used_memory可以看出上边的Redis实例的内存碎片率为1.07,是一个较小的值,这也是正常的情况,有正常情况就有不正常的情况。
发生数据迁移之后的Redis碎片率会很高,以下是迁移数据后的Redis的碎片情况:
used_memory:
4854837632used_memory_human:
4.52Gused_memory_rss:
7362924544used_memory_peak:
7061034784used_memory_peak_human:
6.58Gused_memory_lua:
39936mem_fragmentation_ratio:
1.52mem_allocator:
jemalloc-3.6.0可以看到碎片率是1.52,也就是说有三分之一的内存被浪费掉了。
针对以上两种情况,对于碎片简单的分为两种:
常规碎片迁移碎片常规碎片数量较小,而且一定会存在,可以不用理会。
那么如何去掉迁移碎片呢?
其实方案很简单,只需要先BGSAVE再重新启动节点,重新加载RDB文件会去除绝大部分碎片。
但是这种方案有较长的服务不可用窗口期,所以需要另一种较好的方案。
这种方案需要Redis采用主从结构为前提,主要思路是先通过重启的方式处理掉从节点的碎片,之后进行主从切换,最后处理老的主节点的碎。
这样通过极小的服务不可用时间窗口为代价消除了绝大大部分碎片。
RedisCluster剔除节点失败RedisCluster采用无中心的集群模式,集群中所有节点通过互相交换消息来维持一致性。
当有新节点需要加入集群时,只需要将它与集群中的一个节点建立联系即可,通过集群间节点互相交换消息所有节点都会互相认识。
所以当需要剔除节点的时候,需要向所有节点发送clusterforget命令。
而向集群所有节点发送命令需要一段时间,在这段时间内已经接收到clusterforget命令的节点与没有接收的节点会发生信息交换,从而导致clusterforget命令失效。
为了应对这个问题Redis设计了一个黑名单机制。
当节点接收到clusterforget命令后,不仅会将被踢节点从自身的节点列表中移除,还会将被剔除的节点添加入到自身的黑名单中。
当与其它节点进行消息交换的时候,节点会忽略掉黑名单内的节点。
所以通过向所有节点发送clusterforget命令就能顺利地剔除节点。
但是黑名单内的节点不应该永远存在于黑
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 节点 Redis 集群 来自 蓝鲸 经验总结