开发者社区> 玄学酱> 正文

2.客户端的挑战

简介:
+关注继续查看

《全面剖析Redis Cluster原理和应用》中,我们已经详细剖析了现阶段Redis Cluster的缺点:

  • 无中心化架构
    • Gossip消息的开销
    • 不停机升级困难
    • 无法根据统计区分冷热数据
  • 客户端的挑战
    • Cluster协议支持
    • 连接和路由表的维护开销
    • MultiOp和Pipeline支持有限
  • Redis实现问题
    • 不能自动发现
    • 不能自动Resharding
    • 无监控管理UI
    • 最终一致性和“脑裂”问题
    • 数据迁移以Key为单位,速度较慢
    • 数据迁移没有保存进度,故障时不能恢复
    • Slave“冷备”,不能缓解读压力

当然之前也说过了:“这与Redis的设计初衷有关,毕竟作者都已经说了,最核心的设计目标就是性能、水平伸缩和可用性”。但综合来看,要想在生产环境中使用Redis Cluster,我们还是有一些工作要做的。本文就从宏观层面上,列举一些架构优化的参考方案。


1.P2P架构副作用1.1 Gossip通信开销

Gossip消息的通信开销是P2P分布式系统带来的第一个副作用。有一篇关于Gossip通俗易懂的文章《Life in a Redis Cluster: Meet and Gossip with your neighbors》。Redis为集群操作的消息通信单独开辟一个TCP通道,交换二进制消息:

  • PING/PONG:Cluster的心跳,每个结点每秒随机PING几个结点。结点的选择方法是:超过cluster-node-timeout一半的时间还未PING过或未收到PONG的结点,所以这个参数会极大影响集群内部的消息通信量。心跳包除了结点自己的数据外,还包含一些其他结点(集群规模的1/10)的数据,这也是“Gossip流言”的含义。
  • MEET/PONG:只有MEET后的受信结点才能加入到上面的PING/PONG通信中。

关于Gossip的问题不可避免,我们只能通过参数调整和优化,在通信效率和开销之间找到一个平衡点。因为笔者还未搭建过大规模的Redis Cluster集群,关于集群的性能和参数调优还不能给出建议,留到积累足够经验再做整理吧。

1.2 不停机升级困难

以Nginx为例,修改配置甚至升级版本都不需要停机,Master会逐一启动新的Worker实例去替代旧的Worker。对于单机版的Redis,我们也可以用类似的方式实现的。但目前不知道Redis Cluster或者其他P2P分布式系统像Cassandra,是否有比较好的方案。

1.3 冷热数据无法区分

由于集群内结点都是对等的,所以像数据热度这种整体的统计数据就无处存放。当内存有限时,要想实现层次化存储,将冷数据Swap到慢存储如磁盘上时,就变得有些棘手了!

解决方法就是计算机界号称万能的“增加中间层”方法。增加一层Proxy,负责做数据统计、Swap甚至L1缓存。关于冷热数据的统计和处理,请参考《微博CacheService架构浅析》


2.客户端的挑战

Redis Cluster的引入会给客户端带来一些挑战。要么“勇敢面对”,通过引入最新的支持Cluster协议的Jedis客户端,再加以改造来应对这些挑战。要么增加Proxy,像防洪堤坝一样将危险隔离在外。

2.1 Cluster协议开发

对于Java,最主流的Jedis客户端已经早早开始支持Cluster协议了,但仔细看了一下,貌似处理集群中结点Failover时有些问题。Slave替换上来了,Jedis的确可以根据”MOVED”消息更新Slot与结点的对应关系,但是:

  • 原来Master结点的连接池没有处理
  • 结点IP列表没有更新,极端情况下有问题

不知道这算不算Jedis由来已久的问题了。因为之前Jedis就是只支持要么用分片连接池,要么用Sentinel连接池,没有两者的结合!还好有热心的程序员“出手相助”,详见《Jedis分片Sentinel连接池实验》。上面两个问题对应的源码看得不是很细,突然想到的这两个问题,要是说的不对还请指正!






本文作者:geelou
本文来自云栖社区合作伙伴rediscn,了解相关信息可以关注redis.cn网站。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
金融行业思科设备典型网络故障案例:76系列典型案例(一)
金融行业思科设备典型网络故障案例:76系列典型案例(一)
64 0
金融行业思科设备典型网络故障案例:76系列典型案例(三)
金融行业思科设备典型网络故障案例:76系列典型案例(三)
29 0
即时通讯安全篇(十一):IM聊天系统安全手段之传输内容端到端加密技术
本篇将围绕IM传输内容的安全问题,以实践为基础,为你分享即时通讯应用中的“端到端”加密技术。
192 0
前后端通讯:非敏感信息Cookie的"强化"之路
我们公司鉴权走的是JWT, 但是有些数据走Cookie更方便通讯, 纵观今天,网上一大把说Cookie不好的文章. 但是我们还是要用,那怎么安全一丢丢呢?
49 0
带你读《6G需求与愿景》第二章现有 5G 网络的分析与挑战2.3 5G 网络存在的不足与挑战(一)
《6G需求与愿景》第二章现有 5G 网络的分析与挑战2.3 5G 网络存在的不足与挑战
136 0
互联网后端架构演进及未来猜想
本文是纯粹的思考和讨论,尽可能客观的讨论相关架构。主要对后端 api 应用,以一种事后诸葛亮式的视角进行分析。
319 0
网络安全应急响应的回顾与展望
当前,世界各国纷纷将网络空间安全纳入国家安全战略,制定和完善网络空间安全战略规划和法律法规。我国高度重视网络空间安全,总书记曾明确提出“没有网络安全就没有国家安全”,而网络安全应急工作是网络安全的最后一道防线,完善网络安全应急标准体系,规范网络安全应急工作,提升应急能力,对于捍卫国家安全至关重要。
586 0
业内对 5G 的响应 | 带你读《5G时代的承载网》之五
自 2014 年 5 月 13 日三星电子宣布其已率先开发出了首个基于 5G 核心技 术的移动传输网络,并表示将在 2020 年之前进行 5G 网络的商业推广以来,关 于 5G 的话题如火如荼。
1324 0
从服务端视角看高并发难题
服务端处理请求需要耗费服务端的资源,比如能同时开启的进程数、能同时运行的线程数、网络连接数、cpu、I/O、内存等等,由于服务端资源是有限的,那么服务端能同时处理的请求也是有限的。高并发问题的本质就是:资源的有限性
889 0
以网游服务端的网络接入层设计为例,理解实时通信的技术挑战
本文参考并引用了部分腾讯游戏学院的相关技术文章内容,感谢原作者的分享。 1、前言 以现在主流的即时通讯应用形态来讲,一个完整的即时通讯IM应用其实是即时通信(英文简写:IM=Instant messaging)和实时通信(英文简写:RTC=Real-time communication)2种技术组合在一起的一整套网络通信系统。
3415 0
+关注
玄学酱
这个时候,玄酱是不是应该说点什么...
文章
问答
文章排行榜
最热
最新
相关电子书
更多
微信客户端怎样应对弱网络
立即下载
连接创造价值:云通信的2.0时代
立即下载
改善弱网络-探索移动互联网下弱网络处理方式
立即下载