Codis架构笔记

标签: 分布式 架构 | 发表时间:2016-03-28 09:11 | 作者:那谁
出处:http://www.codedump.info

Codis是起源于豌豆荚的redis Proxy项目,其主要目的是为了解决redis使用中的两个痛点:

  1. 难以动态的平行扩展增加新的redis服务.
  2. 难以运维管理.

它主要的架构是这样的:

主要包括几个组件:

  1. dashboard:主要用于管理服务,主要通过ZK向codis-proxy下发命令,比如新增/减少服务器.
  2. zookeeper:用于集群服务之间同步配置.
  3. codis-proxy:代理层,实现了大部分redis协议命令,对客户端而言与一个真正的redis服务没有太大区别.同时监听ZK的命令,如果有配置的变更就更新自己内部的配置信息,收到redis命令之后根据ZK下发的配置找到对应的redis服务转发命令.
  4. redis:经过修改过的redis服务,主要新增了用于数据迁移用的命令.换言之,为了支持动态变更redis服务,是不能使用原生的redis服务的.

proxy层由于使用了ZK来同步配置,所以是无状态的可以进行平行扩展的.一般而言,要实现一个集群服务的分布式,归根到底本质上有两种方式:

  1. smart-client方式:将分布式逻辑放在client,client层自己感知数据的分布情况.这种方式优点是性能不会有太大的损耗,缺点在于提供服务的同时也需要提供对应的客户端库给用户,让使用者对这个分布式逻辑完全透明,另外对已有的不能修改协议的服务如redis/memcached等显然不适合这种方式了.已知的项目这样做的有tair,aerospike.
  2. proxy方式:将分布式逻辑放在代理层,接收到请求之后由这个代理层负责路由请求到对应的服务上去.优点是不用提供和修改客户端协议,缺点是经过多一层转发势必造成性能的损耗.

Codis使用的Proxy方式,根据他们提供的测试数据,比twemproxy的性能低20%左右.

来谈里面最核心的变更服务器时需要做的迁移数据和相应的一致性问题如何处理.

codis将所有的数据预分配为1024个slot,做一次典型的数据迁移,其最小单位就是一个slot,其流程大致是这样的(以下文字主要来自Codis作者huangdongxu的博客):

  1. 由dashboard通过ZK向所有proxy下发一个pre_migrate命令,如pre_migrate slot_1 to group 2.
  2. 当所有proxy都收到并且回复了pre_migrate命令时,标记slot_1的状态为 migrate,服务该slot的server group改为group2, 同时codis-config向group1的redis机器不断发送 SLOTSMGRT 命令, target参数是group2的机器, 直到group1中没有剩余的属于slot_1的key.
  3. 迁移过程中, 如果客户端请求 slot_1 的 key 数据, proxy 会将请求转发到group2上, proxy会先在group1上强行执行一次 MIGRATE key 将这个键值提前迁移过来. 然后再到group2上正常读取
  4. 迁移完成, 标记slot_1状态为online

这是一个典型的两阶段提交的流程,首先通知所有的proxy准备迁移了,然后再开始数据的迁移.需要注意的问题是,此时的选择了怎样的数据一致性模型以及如何保证这一点的?

Codis使用的是强一致性的数据模型,而不是类似Dynamo那样的当发现有不一致的数据都返回给使用者由使用者来解决冲突的方式.具体策略是:

  1. 在pre_migrate阶段,proxy如果收到这个slot的请求,会block住直到migrate状态了才开始处理.
  2. 在migrate阶段,如果新的处理该slot的proxy接收到了该slot的请求,首先会同步一份该slot的数据过来,再返回给客户端.

可以看到,无论哪个阶段,只要处理到了正在处理的slot,这样的处理都势必造成请求的处理变慢,整个服务的可用性降低,这也是没有办法的事情,具体看业务而定,是否需要更看重可用性还是一致性了.

总体来看,codis并不是有太大难度的项目,毕竟最难的两个部分ZK和Redis是使用已有的项目,但是由于解决了最开始的两大痛点,这个项目由此流行起来.尤其是加上了dashboard之后,方便了使用和管理,使得这个项目更像是一个完全闭环的产品,我觉得这个思路值得借鉴.

相关 [codis 架构 笔记] 推荐:

Codis架构笔记

- - codedump
Codis是起源于豌豆荚的redis Proxy项目,其主要目的是为了解决redis使用中的两个痛点:. 难以动态的平行扩展增加新的redis服务.. dashboard:主要用于管理服务,主要通过ZK向codis-proxy下发命令,比如新增/减少服务器.. zookeeper:用于集群服务之间同步配置..

Instagram 架构分析笔记

- Yousri - DBA Notes
Instagram 团队上个月才迎来第 7 名员工,是的,7个人的团队. 作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张. 不得不说,这真他妈是个业界奇迹. 几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Technologies,披露了 Instagram 架构的一些信息,足够勾起大多数人的好奇心.

系统架构师笔记(二)

- - CSDN博客Web前端推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 七、架构权衡分析法:ATTM(Architecture Tradeoff Analysis Method). 评价软件架构的一种综合全面的方法. 这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标.

系统架构师笔记(一)

- - CSDN博客架构设计推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 1、性能:系统的响应能力,即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数. 架构设计策略:增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等).

《大型网站技术架构》 笔记 - 架构篇

- - 码蜂笔记
第四章 瞬时响应:网站的高性能架构. 性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准. 性能测试的指标有:响应时间、并发数、吞吐量、性能计数器. 网站性能优化的目的,除了改善用户体验的响应时间,还要尽量提升系统吞吐量,最大限度利用服务器资源. 4.2 Web 前端性能优化. 主要手段有优化浏览器访问、使用反向代理、CDN加速等.

各大网站架构总结笔记(续)

- zhouding - 博客园-首页原创精华区
前段时间给大家介绍过各大网站架构总结笔记(MySpace、Flickr、YouTube、PlentyOfFish、WikiPedia),喜欢架构的朋友可以去看看. 这两天,我又陆续从互联网上整理了几个优秀网站的架构信息,并将部分文章整理到了自己的另一个博客,今天把它们拿出来分享给大家,希望能给大家带来一点启发,另外,欢迎一起讨论,有比较好的架构信息大家也可以拿出来一起分享一下:).

读书笔记:网站架构之安全篇

- - CSDN博客架构设计推荐文章
PS:本文为《大型网站技术架构 & 核心原理与案例分析(李智慧 著)》一书的读书笔记. *:全球约70%的Web应用攻击来自XSS攻击和SQL注入,此外还包括CSRF,Session劫持等. 1、XSS攻击:跨站点脚本攻击(Cross Site Script). *:黑客通过在网页文件嵌入恶意JavaScript脚本,在用户打开网页时,该脚本控制浏览器进行恶意操作.

笔记

- 毛毛 - 游戏人生
我关于写代码的一些琐碎的看法. 之前没有把 Paul Graham 的 <黑客与画家> 一书读完, 上周就从同事那里把书带回家, 也一直没读, 到这周才有时间读完. 很久没有更新了 (一看时间, 整整 5 个月), 顺便把这篇写了几个月的感想放出来.. 这本书前面 8 章讲述的内容, 大多是我并不太感兴趣的, 比如财富, 比如创业.

Textmate笔记

- Sean Lee - Reborn
过去在Windows上还真的没有怎么太在意文本编辑器(也跟自己不是职业程序员有点关系吧. ),近来常在Mac上使用Textmate,真觉得一款好的文本编辑器实在非常必要. Textmate售价$58,很多人觉得贵,不过它真的不错. 为Finder加上“Open in textmate”按钮. 作者Henrik的主页上有详细的介绍.