阿里云
阿里云多端小程序中小企业获客首选
发表主题 回复主题
  • 29591阅读
  • 1回复

[技术交流]高效运维最佳实践(03):Redis集群技术及Codis实践

发帖
62
云币
250
}@@1N3nnxV  
gv `jeN  
本文转载自InfoQ
原文地址:http://www.infoq.com/cn/articles/effective-ops-part-03
X X{:$f+  
n$y1kD  
IaE};8a8  
<| |Lj  
高效运维最佳实践(03)
gb@Rx  
HT A-L>Cee  
Redis集群技术及Codis实践 GY,@jp|R  
*bn9j>|iv  
<S $Z  
[lS'GszA  
{xEX_$nv  
jR@-h"2*A  
po=*%Zs*T  
tl;?/  
K!|=)G3.`  
3I:DL#f  
“高效运维最佳实践”是InfoQ在2015年推出的精品专栏,由触控科技运维总监萧田国撰写,InfoQ总编辑崔康策划。 a9QaFs"  
Aplqx vth  
CvQ LF9|  
前言 z&<Rx[  
~l6e&J  
        如开篇文章所言,高效运维包括管理的专业化和技术的专业化。前两篇我们主要在说些管理相关的内容,本篇说一下技术专业化。希望读者朋友们能适应这个转换,谢谢。 Zu%_kpW  
Y141Twjvd  
$ }B"u;:SU  
互联网早在几年前就已进入Web 2.0时代,对后台支撑能力的要求,提高了几十倍甚至几百倍。在这个演化过程中,缓存系统扮演了举足轻重的角色。 iCAd7=o  
nkJ*$cT1o  
t T-]Vj.  
        运维进化到今天,已经不是重复造轮子的时代。所以,我们在架构优化和动化运维中,可以尽可能地选用优秀的开源产品,而不是自己完全从头再来(各种技术geek除外)。 ]Wd{4(b  
q6j]j~JxB  
]qVJ>  
        本文主要讨论Redis集群相关技术及新发展,关于Redis运维等内容,以后另开主题讨论。 7{<F6F^P  
_tjFb_}Q  
\SLYqJ~m  
        本文重点推荐Codis——豌豆荚开源的Redis分布式中间件(该项目于4个月前在GitHub开源,目前star已超过2100)。其和Twemproxy相比,有诸多激动人心的新特性,并支持从Twemproxy无缝迁移至Codis。 W:rzfO.`Z  
~d{E>J77j  
e1<28g  
        本文主要目录如下,对Redis比较了解的朋友,可跳过前两部分,直接欣赏Codis相关内容。 B|,6m 3.  
{B\.8)&8  
2"__jp:(  
        1. Redis常见集群技术 r.K4<ly-N  
          1.1 客户端分片 r4D66tF  
           1.2 代理分片 \re.KB#R  
           1.3 Redis Cluster 6_XX[.%  
        2. Twemproxy及不足之处 }FM<uBKW  
        3. Codis实践 `M7){  
           3.1 体系架构 w-\fCp )  
           3.2 性能对比测试 >F-J}P  
           3.3 使用技巧、注意事项 snEkei|0  
YRYrR|I  
B;K{Vo:C  
好吧,我们开始。 m   
klch!m=d  
#;mZ3[+i5  
vG\Wr.h0!=  
1. Redis常见集群技术 $%t{O[ (  
10[~ki-1;  
/(}V!0\?  
        长期以来,Redis本身仅支持单实例,内存一般最多10~20GB。这无法支撑大型线上业务系统的需求。而且也造成资源的利用率过低——毕竟现在服务器内存动辄100~200GB。 zJ9,iJyuD  
-y/?w*Cx  
4h~Oj y16&  
        为解决单机承载能力不足的问题,各大互联网企业纷纷出手,“自助式”地实现了集群机制。在这些非官方集群解决方案中,物理上把数据“分片”(sharding)存储在多个Redis实例,一般情况下,每一“片”是一个Redis实例。 d!gm4hQhl  
8F[j}.8q  
R K'( {1  
        包括官方近期推出的Redis Cluster,Redis集群有三种实现机制,分别介绍如下,希望对大家选型有所帮助。  (K?[gI  
s-C.+9  
=  Oq;  
1.1 客户端分片 '[juPI(!  
F2:7UNy,  
jr9ZRHCU  
        这种方案将分片工作放在业务程序端,程序代码根据预先设置的路由规则,直接对多个Redis实例进行分布式访问。这样的好处是,不依赖于第三方分布式中间件,实现方法和代码都自己掌控,可随时调整,不用担心踩到坑。 /kJ*WA?J  
`r]Cd {G  
5#fLGXP  
        这实际上是一种静态分片技术。Redis实例的增减,都得手工调整分片程序。基于此分片机制的开源产品,现在仍不多见。 3oKqj>  
-B4v1{An  
,\qo   
        这种分片机制的性能比代理式更好(少了一个中间分发环节)。但缺点是升级麻烦,对研发人员的个人依赖性强——需要有较强的程序开发能力做后盾。如果主力程序员离职,可能新的负责人,会选择重写一遍。 NF a ;  
=}q4ked /  
m+u>%Ys`  
        所以,这种方式下,可运维性较差。出现故障,定位和解决都得研发和运维配合着解决,故障时间变长。 @O3w4Zs  
4p-$5Fk8}  
8n73MF  
        这种方案,难以进行标准化运维,不太适合中小公司(除非有足够的DevOPS)。 r2<+ =INn  
Y"lxh/l$}  
,v6Jr3  
1.2 代理分片 b%_QL3 m6  
i5wA=K_  
ad~ qr n\  
        这种方案,将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求,根据路由规则,将这些请求分发给正确的Redis实例并返回给业务程序。 '&9 a%  
xH f9N?  
b1& {%.3[  
wM yPR_  
M"FAUqz`  
-w2g a1  
H\b5]q %  
        这种机制下,一般会选用第三方代理程序(而不是自己研发),因为后端有多个Redis实例,所以这类程序又称为分布式中间件。 ~::R+Lh(  
<.' cCY  
'qP^MdoE%~  
        这样的好处是,业务程序不用关心后端Redis实例,运维起来也方便。虽然会因此带来些性能损耗,但对于Redis这种内存读写型应用,相对而言是能容忍的。 cwD0 ~B  
k}O|4*.BT  
$e;!nI;z  
        这是我们推荐的集群实现方案。像基于该机制的开源产品Twemproxy,便是其中代表之一,应用非常广泛。 5\'%zZ,l  
q+:(@w6  
HcVPJuD  
1.3 Redis Cluster c,-x}i0c  
3Mcz9exY  
lxmS.C  
        在这种机制下,没有中心节点(和代理模式的重要不同之处)。所以,一切开心和不开心的事情,都将基于此而展开。 BJq}1mn*  
=;a4 Dp  
FEZ6X  
        Redis Cluster将所有Key映射到16384个Slot中,集群中每个Redis实例负责一部分,业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求,如果所需数据不在该实例中,则该实例引导客户端自动去对应实例读写数据。 ."^dJ |fN  
B~aOs>1 S]  
ChW0vIL`  
        Redis Cluster的成员管理(节点名称、IP、端口、状态、角色)等,都通过节点之间两两通讯,定期交换并更新。 T7T!v  
FKx9$B  
2at?9{b  
        由此可见,这是一种非常“重”的方案。已经不是Redis单实例的“简单、可依赖”了。可能这也是延期多年之后,才近期发布的原因之一。 "@?|Vv,vn  
iR_Syk`G*A  
G9a%N  
        这令人想起一段历史。因为Memcache不支持持久化,所以有人写了一个Membase,后来改名叫Couchbase,说是支持Auto Rebalance,好几年了,至今都没多少家公司在使用。 '; dW'Uwc  
u7C{>  
/SKr.S61e  
        是个令人忧心忡忡的方案。为解决仲裁等集群管理的问题,Oracle RAC还会使用存储设备的一块空间。而Redis Cluster,是一种完全的去中心化…… A{J1 n  
:fYwFD( 9  
y;Zfz~z  
        本方案目前不推荐使用,从了解的情况来看,线上业务的实际应用也并不多见。 pzax~Vp  
Fp6Y Y  
7, 13g)  
2. Twemproxy及不足之处 g Oj5c  
4@V] zfu^Q  
eq+o_R}CS  
        Twemproxy是一种代理分片机制,由Twitter开源。Twemproxy作为代理,可接受来自多个程序的访问,按照路由规则,转发给后台的各个Redis服务器,再原路返回。 (rG1_lUDu  
QBw ZfX  
cGc|n3(  
        这个方案顺理成章地解决了单个Redis实例承载能力的问题。当然,Twemproxy本身也是单点,需要用Keepalived做高可用方案。 tN{t-xUgk  
eE{L>u  
cO RMR!  
        我想很多人都应该感谢Twemproxy,这么些年来,应用范围最广、稳定性最高、最久经考验的分布式中间件,应该就是它了。只是,他还有诸多不方便之处。 m3(T0.j0P  
huoKr  
P{Z71a5  
        Twemproxy最大的痛点在于,无法平滑地扩容/缩容。 ?R]y}6 P$  
_o?(t\B9{  
Y+ Z9IiS7  
        这样导致运维同学非常痛苦:业务量突增,需增加Redis服务器;业务量萎缩,需要减少Redis服务器。但对Twemproxy而言,基本上都很难操作(那是一种锥心的、纠结的痛……)。 z;C=d(|nN  
M&ij[%i  
Vrj1$NL%  
或者说,Twemproxy更加像服务器端静态sharding。有时为了规避业务量突增导致的扩容需求,甚至被迫新开一个基于Twemproxy的Redis集群。 3NN'E$"3  
CdDd+h8  
]pV1T  
Twemproxy另一个痛点是,运维不友好,甚至没有控制面板。 0#[f2X62B  
!ix<|F5  
D i'u%r  
Codis刚好击中Twemproxy的这两大痛点,并且提供诸多其他令人激赏的特性。 dn\F!  
i5KwYoN  
>NRz*h#  
3. Codis实践 1bJ]3\  
B#6pQp$  
~Ex.Yp8.  
        Codis由豌豆荚于2014年11月开源,基于Go和C开发,是近期涌现的、国人开发的优秀开源软件之一。现已广泛用于豌豆荚的各种Redis业务场景(已得到豌豆荚同学的确认,呵呵)。 ING_:XpnJ  
5; PXF  
0['"m^l0S  
        从3个月的各种压力测试来看,稳定性符合高效运维的要求。性能更是改善很多,最初比Twemproxy慢20%;现在比Twemproxy快近100%(条件:多实例,一般Value长度)。 &U~r}=  
R-Q1YHUQM  
jN%p5nZ^EK  
3.1 体系架构 v$m[#&O^V?  
p$nK@t}  
+%Y c4  
        Codis引入了Group的概念,每个Group包括1个Redis Master及至少1个Redis Slave,这是和Twemproxy的区别之一。这样做的好处是,如果当前Master有问题,则运维人员可通过Dashboard“自助式”切换到Slave,而不需要小心翼翼地修改程序配置文件。 [u9JL3  
n<:d%&^n  
=/g$bZ  
        为支持数据热迁移(Auto Rebalance),出品方修改了Redis Server源码,并称之为Codis Server。 >I& jurU#  
cvUut^CdK  
Nr24[e G>d  
        Codis采用预先分片(Pre-Sharding)机制,事先规定好了,分成1024个slots(也就是说,最多能支持后端1024个Codis Server),这些路由信息保存在ZooKeeper中。 _ML~c&9jv  
Ww96|m  
P$3=i`X!nw  
6 r.H8  
So=nB} b[?  
1_NG+H]x9  
^+as\  
        ZooKeeper还维护Codis Server Group信息,并提供分布式锁等服务。 D*cyFAF  
.ts0LDk0f  
rj,K`HD  
3.2 性能对比测试 A!{.|x[S44  
`(,*IK a  
[2'm`tZL  
        Codis目前仍被精益求精地改进中。其性能,从最初的比Twemproxy慢20%(虽然这对于内存型应用而言,并不明显),到现在远远超过Twemproxy性能(一定条件下)。 qo6LC>Qg  
(]Ye[j^"7  
a_{io`h3&  
        我们进行了长达3个月的测试。测试基于redis-benchmark,分别针对Codis和Twemproxy,测试Value长度从16B~10MB时的性能和稳定性,并进行多轮测试。 4Oy.,MDQP  
R6!cK[e]4  
}r}RRd  
        一共有4台物理服务器参与测试,其中一台分别部署codis和twemproxy,另外三台分别部署codis server和redis server,以形成两个集群。 r]8x;v1  
[v0ri<sm  
q#99iiG1  
        从测试结果来看,就Set操作而言,在Value长度<888B时,Codis性能优越优于Twemproxy(这在一般业务的Value长度范围之内)。 TF=k(@9J?  
<!~1{`n%9J  
c6,s+^^  
G#e9$!  
d1V^2Hb?  
/o~qC<7  
d&|z=%9xl  
        就Get操作而言,Codis性能一直优于Twemproxy。 :}@C9pqr2  
Tr8AG>  
;8*XOC;[  
"x(>Sj\%I  
7m:|u*ij2~  
f]tv`<Q7  
+M'aWlPg,  
3.3 使用技巧、注意事项 k0|`y U  
fvcW'T}r  
"1XXE3^^  
        Codis还有很多好玩的东东,从实际使用来看,有些地方也值得注意。 q=6Cc9FN  
e1 x^PT  
GilQtd3\  
        1)无缝迁移Twemproxy CmEpir{}(  
出品方贴心地准备了Codis-port工具。通过它,可以实时地同步 Twemproxy 底下的 Redis 数据到你的 Codis 集群。同步完成后,只需修改一下程序配置文件,将 Twemproxy 的地址改成 Codis 的地址即可。是的,只需要做这么多。 d,c8Hs8  
jR{-  
Ap5}5 ewM  
        2)支持Java程序的HA b TLMd$  
Codis提供一个Java客户端,并称之为Jodis(名字很酷,是吧?)。这样,如果单个Codis Proxy宕掉,Jodis自动发现,并自动规避之,使得业务不受影响(真的很酷!)。 /?KtXV>]  
{=UFk-$=  
sm 's-gD  
        3)支持Pipeline $hkq>i \  
Pipeline使得客户端可以发出一批请求,并一次性获得这批请求的返回结果。这提升了Codis的想象空间。 O 'k+7y  
XE_ir Et  
EL^8zyg%%  
        从实际测试来看,在Value长度小于888B字节时,Set性能迅猛提升; Q6"uK  
LHh5 v"zjG  
P$Z}  
V0K16#}1gM  
~xGoJrF\  
XJqTmj3   
IY=/` g  
        Get性能亦复如是。 &V'519vmoZ  
00ofHZ  
L}'Yd'  
%2f//SZ:  
%$@1FlqX;  
[r)e P({  
!p9)CjQ"  
        4)Codis不负责主从同步 N0i!l|G6  
        也就是说, Codis仅负责维护当前Redis Server列表,由运维人员自己去保证主从数据的一致性。 5?WYsj"  
vCw<G6tD  
7A5p["?Z  
        这是我最赞赏的地方之一。这样的好处是,没把Codis搞得那么重。也是我们敢于放手在线上环境中上线的原因之一。 BZK2$0  
HPrq1QpK  
R}8XRe  
        5)对Codis的后续期待? ^/HW$8wEi  
        好吧,粗浅地说两个。希望Codis不要变得太重。另外,加pipeline参数后,Value长度如果较大,性能反而比Twemproxy要低一些,希望能有改善(我们多轮压测结果都如此)。
本帖最近评分记录: 1 条评分 云币 +1
xiaofanqie 云币 +1 您的无私奉献精神值得我们学习!向您致敬! 2015-04-14
级别: 荣誉会员
发帖
1326
云币
32448
只看该作者 沙发  发表于: 2015-04-14
您的无私奉献精神值得我们学习!向您致敬!
发表主题 回复主题
« 返回列表上一主题下一主题

限100 字节
批量上传需要先选择文件,再选择上传
 
验证问题: ECS是阿里云提供的什么服务? 正确答案:云服务器
上一个 下一个
      ×
      全新阿里云开发者社区, 去探索开发者的新世界吧!
      一站式的体验,更多的精彩!
      通过下面领域大门,一起探索新的技术世界吧~ (点击图标进入)