在Redis集群技术上,你不可错过的四大集成者

张冬洪 2017-11-03 09:52:32

作者介绍

张冬洪,Redis中国用户组发起人。多年Linux和数据库运维经验,专注于MySQL和NoSQL架构设计与运维以及自动化平台的开发;目前在微博主要负责Feed系统相关业务的核心数据库运维和业务保障工作。

前阵子有幸现场聆听了云栖大会Redis专场的分享,可以说是不虚此行:会上见到了Redis之父Salvatore Sanfilippo,Redis labs CTO Yiftach Shoolman,Redisson 联合创始人 Jack Gu,Codis 作者王乃峥以及阿里云Redis团队的众多技术大牛。演讲的内容干货也很多,这里稍作总结跟大家分享。

一、阿里云ApsaraCache

先介绍一下阿里云开源的飞天缓存ApsaraCache项目(https://github.com/alibaba/ApsaraCache),这是在社区2.8版基础上开始维护的分支,并backport了部分3.0分支的功能。

那与社区版Redis相比有哪些特点呢?阿里云技术专家白宸在演讲中做了很详细的介绍,先从架构上有一个整体的认识:

架构图:

特点:

与Redis相比,ApsaraCache的显著特点是与场景有关,与数据规模无关。其技术特点和优势,主要表现在:

  • 灾备深度加固,可以重构内核同步机制,解决了原生内核在弱网条件下容易复制中断导致的全量同步问题。(作者注:社区版2.8引入psync机制在一定程度上解决了类似问题)
  • 兼容Memcached协议,能支持双副本的Memcached,数据可持久化,提供更可靠的Memcached服务。(作者注:Memcached是一种in-memory KV 存储,实例重启数据丢失,极容易导致“雪崩”)
  • 短链接优化,使短链接场景下性能提升30%以上,对PHP短连接应用居多的应用提升效果明显。
  • AOF强化,避免AOF Rewrite频繁造成的主机稳定性瓶颈,且能精确到秒级的按时间点恢复。(作者注:单机上部署多个实例如同时触发bgsave或bgrewriteaof操作,在copy-on-write机制作用下,非常可能会导致服务器内存很快耗尽,从而导致Redis服务崩溃,微博也作了类似的改造,废弃掉了aof重写机制,增加了定时持久化操作的配置项cronsave,相当于一个定时任务)

独特的热升级机制,增加了热升级的功能,能够在3ms内完成一个实例的热更新。(作者注:这个功能可以避免由于升级造成的业务影响)

实例的可用性检测等。

除了上面的,在Redis Cluster上面,阿里云团队也做了很多的工作,比如:

1.集群支持select、pub/sub、blpop的能力;

2.对热key的感知和处理;

3.读写分离;

4.多数据中心的灾备以及稳定可靠的基于aof log的复制等。

二、Redis Enterprise

来自Redis labs的联合创始人&CTO YiftachShoolman先生在会上提到的一点非常有意思,根据similarweb.com的统计,在Redis使用者TOP5中,中国排第一,远超第二名美国,可见国内Redis用户群体之多。

另外,他还给大家普及了一下Redis的基础,比如Redis的数据结构。

Redis modules 这个功能,相信大家不陌生吧?就是Redis labs这个公司所提出的,并且在此基础上开发了很多的扩展功能,其中本文作者就翻译过其中几篇介绍的文章,比如有:ReJSON、Redis-ML、RediSearch等。

链接:

  • http://www.sohu.com/a/155063241_99937638
  • http://www.sohu.com/a/155010567_99937638
  • http://www.sohu.com/a/154690419_99937638

还讲了很多关于Redis labs产品相关的内容,最后讲到了Redis 企业版的优势,听上去他们真的做了很多的事情,有很多值得学习地方。如下:

三、Codis集群演化和Redis异步迁移

1、Codis集群演化

Codis作者spinlock9首先分享了Codis出现的背景和开发中的挑战,他们也跟大多公司一样,也经历过多次的技术选型上的迭代,也曾在Redis + Twemproxy和Redis Cluster进行过尝试,踩过坑,比如twitter 在2015年就不再贡献Twemproxy代码,它最大的缺点是一个静态的Sharding 策略,随着业务的增长也几乎没有办法进行动态的扩缩容。

而当时Redis Cluster也只是推出了beta版本,对于线上的业务存在风险。故最终确定在2014年酝酿要开发Codis,15年开始Release出来,会上他介绍了开发过程需要解决的问题,比如:

兼容所有语言的客户端

能支持GB到TB级别的水平扩展能力

也能提供Redis同样的高吞吐和低延迟的优势

高可用等

挑战:

Redis Cluster和Codis的特性比较:

需要特别提醒一下的是:Codis在3.2版本的时候就允许异步迁移,能够进行平滑的扩容缩容,这是比Redis Cluster进步的地方。

架构设计:

优缺点:

特性介绍

高吞吐

  • 指令流水
  • 实现效率 + 优化GC

并发多连接

  • 单连接 - Redis
  • 多连接 - SSD(RocksDB)

多DB支持

  • 默认16个DB

访问控制

  • 指令黑名单
  • SessionAuth - Proxy 独立配置
  • ProductAuth - Codis 集群共享

读写分离 - 跨机房优化(默认是关闭的)

  • 牺牲一致性
  • 写:写主
  • 读:同IP > 同IDC > 跨IDC (优先级策略)

高可用

  • Sentinel 替换了HA

他还讲述了未来的规划,提到了有如下几点:

  • 兼容Redis,升级到Redis4.2,做到最小修改,兼容分片策略等;
  • 完善Codis,完善K8S的支持,提升自动化部署程度、实现Transaction等,集成Sentinel功能等。

更大的挑战

  • 更大的副本容量:单副本100TB以上
  • 更高的集群吞吐:QPS 500 ~ 1000w/s
  • 更复杂的访问模式
  • 1)普通业务 - 低延迟
  • 2)数据平台 - 高吞吐
  • Codis + RocksDB
  • 开源方案Pika

2、Redis异步迁移

听到这里时,还以为上面是重点,结果不是,重点下面才真正开始。

Redis同步迁移存在的问题:

降低服务质量

  • 阻塞服务
  • 误触HA、丢失数据

限制数据规模

  • 实际建议<2MB(RESP限制<512MB)

迁移受网络质量(RTT)影响

  • 增加阻塞时间、降低迁移效率

增加错误处理难度

  • 错误恢复困难、人工介入困难

举个栗子:

那么上述的问题的解决思路是什么呢?他继续分享到:

指令分解

  • 单个复杂、耗时的操作,分解成多个简单、高效的指令
  • 分摊CPU分摊,单指令us级别
  • 支持AUTH、SELECT指令

异步IO + 指令流水

  • 连接复用
  • 流量控制 - 发送窗口
  • 批量迁移(Batch)

错误处理 - 脏数据处理

  • 主动清理
  • 过期清理

迁移状态机

  • 发送窗口初始化
  • 确定传输模式:简单 or 分片?
  • 连接初始化(start)
  • REPLACE语义
  • 发送分片(Chunked)
  • 临时TTL = RTT x 3
  • 迁移完成
  • 重置TTL
  • 标记完成(Done)
  • 异步删除 - BIO thread

访问冲突

  • 迁移间隙 - Key Missing
  • 迁移过程中 - 1)读 - 迁冲突; 2)写 - 迁冲突;3)Key Missing

四、Redisson

Redisson是什么?以及Redisson专业版有哪些特性和优点?Redisson联合创始人顾睿从Redisson使用上,举例“如何利用Redisson分布式化传统web项目”的分享,算是对之前内容的一个很好的补充和论证。(Redisson项目地址:https://github.com/redisson/redisson)

传统Web项目的基本架构

传统Web项目的典型特征

  • 非分布式
  • 非高可用
  • 非高并发

什么是分布式系统?

  • 网络 - 高度互联
  • 集群 - 多节点
  • 单一 - 透明化

分布式系统的特点

  • 开放性
  • 透明性
  • 扩展性
  • 并发性

分布式化的实现方式有哪些呢?

  • 架构细分
  • 服务化、模块化
  • 数据中心化
  • 事件驱动

分布式系统会遇到哪些挑战?

接着他分享了Redis以及Redisson的概念和特点的介绍,这里为了节省篇幅,省略N多文字,但为了后面的理解,多啰嗦一句:Redisson是操作最简单,功能最丰富的Redis智能客户端,为JVM提供基于Redis的高性能驻内存数据网格。那Redisson的智能化又是体现在哪些方面呢?

Redisson是如此智能的客户端,那相比其它的普通客户端又有怎样的差异和优势呢?

回到主题上,Redisson可以解决传统Web项目分布式化?那它是怎么做到的?当时由于时间的关系,Jack Gu只是从两个方面进行了讲解,相信能在更多的方面进行解决,这两个方面分别是从数据缓存的角度和分布式锁的角度进行分享。

Redisson映射

  • Redis基本结构:Redis Hash
  • Java 接口:java.util.Map、java.util.concurrent.ConcurrentMap
  • 缓存设计模式:Read Through、Write Through、Write Behind
  • 数据预热:Data Preload

防缓存穿透,在Redisson上做了一些改进:

Redisson映射数据缓存的两种方案:

在锁上Redisson又做了哪些改进来满足分布式的需求呢?

看着上面的简单描述,各种名词似曾相识吧?真正要用起来,还是需要花些时间慢慢消化的。Redisson在一定程度上减少了使用的复杂性,提高了业务性能,提升了开发效率,可以尝试一下。

特别说明:以上内容整理自云栖大会的分享,版权归演讲作者以及云栖大会所有。

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告