Redis基础知识及集群搭建.ppt

Redis基础基础知识及集群搭建知识及集群搭建张西强张西强2015年年2月月目录Redis基础知识基础知识Redis集群搭建1 12 2Redis简介简介Redis，典型的NoSQL数据库服务器，采用KEY-VALUE存储结构，可以作为服务程序独立运行于自己的服务器主机，同时作为内存数据库，不用IO读取硬盘数据，能够快速响应请求。Redis是什么？是什么？Redis有有什么特点？什么特点？支持持久化、支持多种数据结构、支持主从复制、免费与与关系型数据库比较关系型数据库比较redis由于其存储结构相对简单，因此并不能对复杂的逻辑关系提供很好的支持，然而在适用于Redis的场景中，我们却可以由此而获得效率上的显著提升。Redis的数据结构的数据结构作为NOSQL数据库之一的redis，除了支持基本key-value方式，还支持结构化存储，以适应各类应用场景：nString:字符串类型nList:链表类型nHashes:哈希类型nSet:集合类型nSorted-Sets有序集合类型字符串类型：字符串类型：StringString是最常用的一种数据类型，普通的key/value存储都可以归为此类。当然，也可以存储图片，视频等序列化对象，Value最多可以容纳的数据长度是512M。1.赋值：SETKEYVALUEMSETKEY1VALUE1KEYVALUE2SETBITKEYOFFSET1/02.取值：GETKEYMGETKEY1KEYGETBITKEYOFFSET3.字符串操作：STRLENKEYSETRANGEKEYOFFSETVALUESGETRANGEKEYSTARTEND4.数字操作：INCRKEYDECRKEYINCRBYKEYdecrement/DECRBYKEYdecrement5.其他：SETEXKEYSECONDSKEYVALUEStringLENBUFFREE链表类型：链表类型：ListList类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。1.赋值：LPUSH/RPUSHKEYV1V2VNLPUSHX/RPUSHXKEYVALUE2.取值：LPOP/RPOPKEYLRANGEKEYSTARTENDGETBITKEYOFFSET3.INDEX操作：LSETkeyindexvalueLINDEXKEYindex4.取长度：LLENKEY5.截取：LTRIMkeystartstop场景：LIST可以作为消息队列，LPUSH链表头作为生产者插入消息，RPOP作为消费者取得消息。哈哈希类型希类型：Hashes我们可以将Redis中的Hashes类型看成具有StringKey和StringValue的map容器。所以该类型非常适合于存储值对象的信息。1.赋值：HSETKEYFILEDVALUEHMSETKEYFILEDVALUEFILED1VALUE2.取值：HGETKEYHMGETKEYKEYHKEYSKEYHVALSKEYHGETALLKEY3.删除：HDELFILEDFILED4.取长度：HLEN5.存在判定：HEXISTSkeyfiled场景：AIOP中用户标签信息使用HASHMAP存储，存储结构为user:phonetag1val1tag2val2，AIOP传递客户手机号，即可通过HGETuser:phonetag1tag2取出标签值。集合集合类型类型：Sets在Redis中，我们可以将Set类型看作为没有排序的字符集合，就像什锦果冻，只是聚集在一起，没有顺序，这和List类型不一样，另外要注意Set集合中不允许出现重复的元素，而且Set支持多个Sets之间的差、并、交集操作。1.新增：SADDKEYM1M22.查询：SMEMEBERSKEYSPOPKEYSRANDMEMBERKEY3.删除：SREMKEYM1M2MN4.取长：SCARDKEY5.存在判定：SISMEMBERKEYMEMBER6.聚合运算：SDIFFKEY1KEY2SINTERKEY1KEY2SUINONKEY1KEY2场景：COC中将符合标签的用户进行聚类，存放到Set中，比如set1存放学生标签用户、set2存放低消费用户、set3存放非合约用户，那么取出可能购买小米的低消非合约学生用户群：1.SINTERSTOREasetset1set22.SDIFFasetset3有序集合中也不允许有重复数据，它比Set多了一个score，Redis正是通过score来为集合中的成员进行从小到大的排序。需要注意的是，尽管Sorted-Sets中的成员必须是唯一的，但是分数(score)却是可以重复的。1.查询：ZADDKEYSCORENMBR1SCORENMBRN2.删除：ZREMKEYMBR1MBR2MBRN3.取前几位/后几位：ZRANGEkeystartstopWITHSCORESZREVRANGEkeystartstopWITHSCORES4.统计数量：ZCOUNTkeyminmax5.取分数：ZSCOREkeymember场景：可以用于一个大型在线游戏的积分排行榜。每当玩家的分数发生变化时，可以执行ZADD命令更新玩家的分数，此后再通过ZRANGE命令获取积分TOPTEN的用户信息。当然我们也可以利用ZRANK命令通过username来获取玩家的排行信息。最后我们将组合使用ZRANGE和ZRANK命令快速的获取和某个玩家积分相近的其他用户的信息。有序有序集合集合类型类型：Sorted-Sets以上各类数据类型的操作全部是针对于KEY关联的value操作，redis也提供了单独对key值的操作匹配:KEYSpattern例如keys*列出所有key值删除：DELkeykey.例如dellist1删除链表1是否存在：EXISTSkey键值迁移：MOVEkeydb-移向数据库select01可选择数据库查看数据类型：TYPEkey设置超时：EXPIREkeyseconds/EXPIREATkeytimestamp取消超时：PERSISTkey其他操作其他操作Redis在设计之初就被定义为长时间不间断运行的服务进程，因此大多数系统配置参数都可以在不重新启动进程的情况下立即生效，我用到的有：Slaveofhostport修改主从关系Info当前系统信息shutdown关闭redisflushall清空所有keysflushdb清空当前数据库keyRedis主从复制的优势：1.支持一主多从2.支持级联复制：master-slave-slave，分载master同步压力3.支持非阻塞式数据同步：数据同步与对外服务能力分离，互不影响4.支持slave只读模式Redis主从复制主从复制主主从从复复制制流流程程1).RDB持久化：该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。优点：1.只有一份rdb文件，可随时备份2.比AOF文件小，加载效率高3.只提供fork子进程，不阻塞主进程，IO操作比较少2).AOF持久化:该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。优点：1.每改动同步数据安全性好2.APPEND方式追加日志，不会对旧日志文件产生影响3).无持久化：我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。4).同时应用AOF和RDB。Redis持久化持久化1).RDB持久化：Dump快照的机制：1).Redis先fork子进程。2).子进程将快照数据写入到临时RDB文件中。3).当子进程完成数据写入操作后，再用临时文件替换老的文件。redis.conf配置修改：save9001#在900秒后，如果至少有1个key发生变化，则dump内存快照。save30010#在300秒后，如果至少有10个key发生变化，则dump内存快照。save6010000#在60秒之后，如果至少有10000个key发生变化，则dump内存快照。（注释1：可以配置多个条件组成持久化策略）（注释2：fork进程开销大，数据量太大时，消耗cpu和内存资源，影响父进程不能及时响应请）2).AOF持久化：redis.conf配置修改appendonly yesappendfsyncalways#每次有数据修改发生时都会写入AOF文件。appendfsynceverysec#每秒钟同步一次，该策略为AOF的缺省策略。appendfsyncno#从不同步。高效但是数据不会被持久化。（注释：一般选择always每修改同步，保证数据安全）Redis持久化持久化2Redis作为内存数据库，所有数据都从内存中拿，省去读写磁盘的消耗（持久化是由fork子进程处理，主服务对外能力不受影响），响应速度极快。但我们不可能将所有的数据都读到内存中，所以内存资源显得非常可贵，我们就要优化存储结构，使得好钢用在刀刃上.Redis内存优化思考内存优化思考1.尽量使用hashCOC中每个客户会对应上千个标签，每个客户就是一个对象,我们如何存储它？phone序列化对象：tag1tag2tag3tagnkeyvaluePhone:tag1keyvaluephonekeyvaluev1Phone:tag2v2Phone:tagnvntag1v1tag2v2tagnvn序列化对象：序列化对象：要求在redis存储前对象进行序列化操作，每次取出后还要执行反序列化操作，开销太大；如果只想取对象的某一个值，都需要将整个对象取出，还要解决并发、数据一致性、加锁等复杂问题。K-V模式模式:phone字段冗余HASHMAP:phone字段只出现一次，避免数据冗余Redis内存优化思考续内存优化思考续1存储存储结构结构比较比较比较K-V结构与HASHMAP结构对内存的影响：前提假设COC有1千万用户对象，每个用户对象有1000个标签，Redis存储的phone_no格式为185XXXXXXXX。1.根据ASCII编码，每位数字占用单字节字符，每个phone_no占用11Byte.2.K-V结构中，存放一个完成对象，每个phone_no需要重复1000次，所以存放1千万个对象phone_no为1000*1千万，所占空间为：1000次*10000000个*11B/1024/1024=102.45G内存内存优化优化效果效果Redis内存优化思考续内存优化思考续22.根据业务场景，考虑使用BITMAP前面我们在讲String的时候提到过两个命令：setbitkeyoffset0/1和getbitkeyoffset，这两个命令是在位上进行0/1赋值和取值。假设还是1000W用户，每个用户有1000个0/1标签，我们可以使用bitmap来存放这些数据：10010110000010phone1tag1tag1000Setbitphone111Setbitphone199911000bit/8/1024/1024=0.000119MB所有标签总占用的内存为：0.000119MB*1000W=1.19GB,如果使用key-value结构（包括hashes），内存占用至少是它的8倍。Redis内存优化思考续内存优化思考续3只适合只适合01型标签型标签需要位移位与标签的字典表，属于额外开销，但相对而言需要位移位与标签的字典表，属于额外开销，但相对而言字典表字典表offset数字可共享数字可共享redis数字池，比直接存字符串要数字池，比直接存字符串要省空间。省空间。牺牲时间换牺牲时间换空间：空间：1.维护字典表维护字典表 2.入库需要对应转化入库需要对应转化 3.出出库计算也需要转换库计算也需要转换BITMAP使用总结使用总结本本次次redis基础知识中，我们介绍了基本的数据结构及常用基础知识中，我们介绍了基本的数据结构及常用命令、数据类型的场景举例、命令、数据类型的场景举例、redis主从复制机制、持久化主从复制机制、持久化机制、以及内存优化。机制、以及内存优化。无论无论是数据结构选择还是内存优化，都要结合具体的业务是数据结构选择还是内存优化，都要结合具体的业务场景和业务要求，没有通用的最佳推荐模式，只有最符合场景和业务要求，没有通用的最佳推荐模式，只有最符合需求的模式，所以我们需要我们不断尝试、不断优化。需求的模式，所以我们需要我们不断尝试、不断优化。Redis基础基础总结总结目录Redis基础知识Redis集群搭建1 12 2集群及集群目的集群及集群目的目的：目的：高可用、负载均衡、易扩展、数据安全、性能提升技术：技术：集群地址（虚拟IP）、网络通信(监控消息)功能：功能：负载均衡、读写分离、故障转移集群集群集群指的是将几台服务器集中在一起，实现同一业务Redis集群部署方案集群部署方案1方案1：haproxy+keepalived+redis集群 Redis集集群群架架构构redis服务器服务器haproxy服务器服务器Redis集群部署方案集群部署方案1REDIS：通过REDIS的配置文件，可以实现主从复制、读写分离的工作。HAPROXY：通过haproxy的配置文件，实现负载均衡，haproxy负载均衡算法有多种，一般采用轮询方式，当某台redis-salve故障时，haproxy会将其摘除。Keepalived：是一个基于VRRP协议来实现服务器高可用方案，可以利用其来避免haproxy单点故障,保证高可用。方案方案1redishaproxykeepalivedRedis部署目标部署目标Redis部署部署1机器1:redis主节点(10.1.49.53:6379)从节点(10.1.49.53:63791)从节点(10.1.49.53:63792)机器1:haproxy+keepalived机器2:从节点10.1.49.30:63793从节点10.1.49.30:63794机器2:haproxy+keepalived机器机器1:以以root用户创建以下目录用户创建以下目录部署环境进入进入/usr/local/src目录目录Redis下载：下载：wgethttp:/download.redis.io/releases/redis-2.8.9.tar.gzRedis部署部署2解压解压redis安装包：安装包：编译编译redis:Redis部署部署3复制配置文件，执行如下：复制配置文件，执行如下：修改修改redis.conf:bind设为10.1.49.53#redis服务跟该IP绑定dir设为/usr/local/redis/datapidfile/var/run/redis.piddbfilename设为dump.rdbdaemonize设为yesport6379修改修改 redis-slave1:bind10.1.49.53#绑定IPpidfile/var/run/redis-slave1.piddbfilenamedump-slave1.rdbdir/usr/local/redis/dataport63791slaveof10.1.49.536379#是10.1.49.536379的从存储daemonizeyes#后台开启守护进程slave-read-onlyyes#slave只读（注：不要覆盖原文件，找到相应的字段修改即可，其他保持原样）Redis部署部署4修改修改 redis-slave2:bind10.1.49.53pidfile/var/run/redis-slave2.piddbfilenamedump-slave2.rdbdir/usr/local/redis/dataport63792slaveof10.1.49.536379daemonizeyes启动启动slave的的redis服务：服务：机器机器2:机器2上的部署如同机器1，只要配置从服务器文件即可启动机器启动机器1上的上的redis-master可通过psef|grepredis查看服务是否启动Redis部署部署5验证：验证：首先确认已启动：机器1上：redis-serverredis.confredis-serverredis-slave1redis-serverredis-slave2机器2上：redis-serverredis-slave3redis-serverredis-slave4到现在已完成redis集群配置,且只有10.1.49.536379可写数据，其余slave机器只能读数据redis-cli-h10.1.49.53-p6379Info可以看到这样子就是成功了:注1：配置文件中默认主从复制是开启的，通过上图可以看到命令机器为master，下挂4个从服务器注2：查看我编写的redis启动关闭脚本redis该脚本放在/etc/init.d/中，通过serviceredisstart/stop使用Redis部署部署报错处理报错处理1.如果报下面的错，说明master的redis没有启动，启动它既可2.在2号机子上执行报错，请检查防火墙策略Haproxy部署目标部署目标Haproxy部署部署进入机器进入机器11.安装安装cd/usr/local/srctar-zxvfhaproxy-1.3.15.10cdhaproxy-1.3.15.10makeTARGET=linux26PREFIX=/usr/local/haproxymakeinstallPREFIX=/usr/local/haproxy注意：要查看linux系统的内核信息，要与TARGET匹配2.配置配置cd/usr/local/haproxy#haproxy 默认是没有配置文件的，需要自己手机创建默认是没有配置文件的，需要自己手机创建vihaproxy.cfg3.查看查看是否成功：是否成功：/usr/local/haproxy/sbin/haproxy-f/usr/local/haproxy/haproxy.cfg#启动ps-ef|grephaproxy#查进程访问110.1.49.53:8888/haproxyadmin机器1与机器2上的haproxy配置部署是一样的，通过keeplived采用单活方式对外提供服务Keepalived部署部署进入机器进入机器1cd/usr/local/src/wgethttp:/www.keepalived.org/software/keepalived-1.2.12.tar.gztar-zxvfkeepalived-1.2.12.tar.gzcdkeepalived-1.2.12./configuremake&makeinstall注：若这里报错提示没有装openssl，则执行yum-yinstallopenssl-devel安装，若还有其他的包没装，则执行yum命令进行安装cp/usr/local/etc/rc.d/init.d/keepalived/etc/rc.d/init.d/cp/usr/local/etc/sysconfig/keepalived/etc/sysconfig/mkdir/etc/keepalivedcp/usr/local/etc/keepalived/keepalived.conf/etc/keepalived/ln-s/usr/local/sbin/keepalived/usr/sbin/vi/etc/keepalived/keepalived.conf注1：此处注意与之前的字符之间必须有空格，否则无法正常调用，例如VI_1这样写，就在keepalived启动时无法建立VIP10.1.49.200vi/etc/keepalived/check_haproxy.sh注1：是esc下面的符号，不是单引号。另外if表达式注意空格，另外要注意/etc/keepalived/check_haproxy.sh必须赋予可执行权限：chmod777/etc/keepalived/check_haproxy.sh，否则会启动不起来Keepalived配置文件配置文件vrrp_scriptchk_haproxyscript/etc/keepalived/check_haproxy.shinterval2global_defsrouter_idLVS_DEVELvrrp_instanceVI_1stateBACKUP#备机MASTER主机interfaceeth0#绑定的网卡virtual_router_id53#与master保持一致，组号,同组能通知priority120#要比master低，选举的依据advert_int1authenticationauth_typePASSauth_type1111track_scriptchk_haproxyvirtual_ipaddress10.1.49.200#VIPcheck_haproxy.sh脚本如下：#!/bin/bash#A=ps-Chaproxy-no-header|wc-l#keepalived检查本机haproxy是否启动ifps-Chaproxy-no-header|wc-l-eq0;#haproxy进程是否为0thenechohaproxynotrunning,attempttostartup/usr/local/haproxy/sbin/haproxy-f/usr/local/haproxy/haproxy.cfg#如果为零则启动haproxysleep5ifps-Chaproxy-no-header|wc-l-eq0;#判定是否启动成功then/etc/init.d/keepalivedstopechohaproxystartfailure,stopkeepalivedelseechohaproxystartedsuccessfiFiKeepalived.confcheck_haproxy.shkeepalived验证验证机器机器1、2上分别执行上分别执行：/etc/rc.d/init.d/keepalivedstart通过通过 ip add，出现如下表示，出现如下表示VIP建立建立通过ps-ef|grephaproxy查看是否启动haproxy通过ps-ef|grepkeepalived查看是否启动keepalivedkeepalived验证验证通过tail-f/var/log/messages,出现以下信息为正确如果出现以下错误，请检查/etc/keepalived/check_haproxy.sh是否是可执行文件集群方案集群方案1验证验证主从复制验证：主从复制验证：在master中执行setkey1“test”，在slave1、slave2、slave3、slave4中执行getkey1,获得“test”,测试通过读写分离读写分离验证：验证：在各slave中执行setkey1“test”,报以下错误测试通过 (error)READONLY You cant write against a read only slave.负载均衡验证：负载均衡验证：redis-cli h 10.1.49.200 p 63790 get key1 得“test”,测试通过负载均衡高可用验证：负载均衡高可用验证：kill-9haproxy进程号，redis-cli h 10.1.49.200 p 63790 get key1 得“test”,测试通过扩展性验证：扩展性验证：slave3上执行slaveof10.1.49.3063798脱离master,再执行slaveof10.1.49.536379加入到master，说明slave可不宕机扩展验证方式验证方式Redis集群部署集群部署方案方案2方案2：redis官方Sentinel集群管理工具Sentinel1Sentinel2Sentinel3Sentinel4masterslaveslaveslave哨兵群Redis集群ping发布订阅Redis集群部署方案集群部署方案2Sentinel：负责对负责对redis群中的主从服务器监控、提醒和自群中的主从服务器监控、提醒和自动故障转移动故障转移。Redis群群：对外提供对外提供redis服务服务方案方案2Sentinel群群Redis群群Sentinel原理原理综述：综述：RedisSentinel是一个分布式系统，你可以在一个架构中运行多个Sentinel进程（progress），个数与redis集群中服务个数没有关联关系。这些进程使用流言协议（gossipprotocols)来接收关于主服务器是否下线的信息，并使用投票协议（agreementprotocols）来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。流言协议：流言协议：Sentinel服务通过ping命令来确认监控服务是否正常，当足够多数量的sentinel都确认监控的同一服务停止了（主观下线），则判定该服务停止（客观下线）。跟流言很相似，一个哨兵说看不到目标了，他会向其他哨兵询问是否看得到目标，足够多的哨兵说看不到目标，则说明目标消失。一般来说，足够多就是一半及以上。投票协议：投票协议：投票协议就像选举，sentinel群根据一定的规则，从redis群中选择一个新的主服务器，并使其他redis服务器作为新服务器的slave,并修改自身的配置文件原理原理Sentinel配置配置Sentinel集群部署很简单，而且它跟redis集群逻辑上是独立，可以启动任意多个（当然最少要两个才有效果）服务，只需要配置Sentinel.conf文件即可：port26378#sentinel服务端口daemonizeyes#开启守护进程logfile“/var/log/redis/sentinel1.log“#sentinel运行日志sentinelmonitormymaster10.1.49.5363792#监控主服务及判定客观下线所需要的最少主观下线sentinel服务数sentineldown-after-millisecondsmymaster60000#本sentinel服务多长时间收不到消息才能判定主观下线sentinelfailover-timeoutmymaster180000#故障转移判定超时间sentinelparallel-syncsmymaster1#故障转移后，允许最多几个slave可以同时从新服务器同步数据配置配置Sentinel问题及注意事项问题及注意事项配置文件自动生成内容配置文件自动生成内容：服务在配置文件中指定从服务器地址及其他sentinel服务地址，sentinel的发布订阅功能支持向所监控master服务发布和订阅消息，而消息中会包含从服务器地址、端口，其他sentinel的信息，sentinel拿到其他sentinel服务消息后，会写入自己的配置文件中。Failover时间：时间：当新master代替老master后，其他的slave会自动使用新master，同时向新master发布同步数据请求，所有slave同步完成后，这次故障转移才算完成。而本参数就是规定最多有几个slave可以同时进行数据同步，failover总时长是：（slaveCount%parallel-syncs+1）次*单位同步时长 parallel-syncs：从2中看出参数越小，故障转移时间越长。基础中提到过同步数据的fork子进程虽然不会阻塞服务，但是会占用内存，可能使主服务不能响应指令。所以本参数越大，同时不能响应指令的slave就越多，就越影响对外服务，甚至使对外服务能力中断。所以，配置参数是，我们要尽量减少故障转移时长，同时也要预留足够的slave对外提供服务。问题及注问题及注意事项意事项Sentinel部署部署环境环境Redis：主节点(10.1.49.53:6379)从节点(10.1.49.53:63791)从节点(10.1.49.53:63792)Sentinel：S(10.1.49.53:26379)S1(10.1.49.53:26378)53机机器器Redis：主节点(10.1.49.30:63793)从节点(10.1.49.30:63794)Sentinel：S(10.1.49.30:26379)S(10.1.49.30:26378)30机机器器配置文件配置文件Sentinel配置文件如右：1.根据实际情况修改port2.根据需要修改日志文件Sentinel部署部署2启动启动sentinel方法1：redis-sentinelsentinel.conf方法2：redis-serversentinel.conf-sentinel启动成功：psef|grepredis机机器器5330启动启动redis机机器器5330redis-serverredis.confRedis-serverredis-slave1Redis-serverredis-slave2Redis-serverredis-slave3Redis-serverredis-slave4Sentinel部署部署3观察日志观察日志命令1：1030603Feb18:52:35.231#Sentinelrunidis242ce4ede4b8d9100f2f761ec00fc2774bca9ad71030603Feb18:52:35.231#+monitormastermymaster10.1.49.536379quorum21030603Feb18:53:35.261#+sdownmastermymaster10.1.49.5363791030603Feb19:02:44.126*+sentinelsentinel10.1.49.30:2637810.1.49.3026378mymaster10.1.49.5363791030603Feb19:02:44.143#-sdownmastermymaster10.1.49.5363791030603Feb19:02:44.144*+sentinelsentinel10.1.49.53:2637810.1.49.5326378mymaster10.1.49.5363791030603Feb19:02:44.188*+sentinelsentinel10.1.49.30:2637910.1.49.3026379mymaster10.1.49.536379绿色：sentinel启动后监控master，6秒后未收到响应，判定客观下线（+sdown）红色：master启动后，sentinel发布消息至master，也收到其他sentinel发布的消息，将这些sentinel添加到配置文件，并开始监控。Sentinel们判定master活着，取消主观下线和客观下线状态。配置文件新增内容Sentinel部署部署4观察日志观察日志命令2：redis-cli-h10.1.49.53-p63791slaveof10.1.49.5363791030603Feb19:23:08.501*+slaveslave10.1.49.53:6379110.1.49.5363791mymaster10.1.49.536379说明：一个新的从服务器已经被Sentinel识别并关联（+slave）命令3：在53与30上执行slaveof10.1.49.5363791030603Feb19:26:29.324*+slaveslave10.1.49.53:6379210.1.49.5363792mymaster10.1.49.5363791030603Feb19:28:19.838*+slaveslave10.1.49.30:6379310.1.49.3063793mymaster10.1.49.5363791030603Feb19:28:19.838*+slaveslave10.1.49.30:6379410.1.49.3063794mymaster10.1.49.536379说明：redis集群已经启动，并纳入sentinel群监控Sentinel部署部署4观察日志观察日志1030603Feb19:36:22.681#+sdownmastermymaster10.1.49.5363791030603Feb19:36:22.715#+new-epoch11030603Feb19:36:22.721#+vote-for-leaderbac4d459c9c0cf6ba8394dc3b35855c4becac3ed11030603Feb19:36:22.739#+odownmastermymaster10.1.49.536379#quorum4/21030603Feb19:36:24.823#+switch-mastermymaster10.1.49.53637910.1.49.30637941030603Feb19:36:24.825*+slaveslave10.1.49.53:6379210.1.49.5363792mymaster10.1.49.30637941030603Feb19:36:24.973*+slaveslave10.1.49.53:6379110.1.49.5363791mymaster10.1.49.30637941030603Feb19:36:25.058*+slaveslave10.1.49.30:6379310.1.49.3063793mymaster10.1.49.30637941030603Feb19:36:25.067*+slaveslave10.1.49.53:637910.1.49.536379mymaster10.1.49.30637941030603Feb19:37:25.156#+sdownslave10.1.49.53:637910.1.49.536379mymaster10.1.49.3063794说明：master判定主观下线（+sdown），sentinel投票选举10.1.49.3063794为新master(+switch-master)，其他slave自动执行slaveof，故障转移成功命令4：redis-cli-h10.1.49.53-p6379shutdown命令5：redis-serverredis.conf1031003Feb19:44:11.924#-sdownslave10.1.49.53:637910.1.49.536379mymaster10.1.49.30637941031003Feb19:44:21.863*+convert-to-slaveslave10.1.49.53:637910.1.49.536379mymaster10.1.49.3063794说明：老master启动后被加入到redis集群，并将角色转换为slave,并不抢占主服务集群总结集群总结1.目前官方redis_cluster尚在开发之中，目前bate只实现了部分功能，业界采用的多是zookeeper、Keepalived结合主从复制，或者Twemproxy开源架构，淘宝、百度、京东等公司使用的自主封装的redis集群架构。2.方案1中进一步优化，通过双master热备，可以减少集群宕机风险；方案2中解决了master宕机问题，但是需要进一步封装，已达到负载均衡及对外透明。3.以上介绍的两个集群方案，都未能实现数据分片（sharding)，面对大数据时纵向扩展（scale out)受限。当前官方集群中已经提供能分片功能，与方案2结合以期达到“高可用、易扩展、读写分离、负载均衡”目标今天跟大家分享的是目前将已实现的集群架构，最后一页附带Twemproxy集群架构图，他是twitter提供的开源架构，当前新浪微博主体也采用该架构，在官方架构出来前，该架构还是比较好的选择：集群总结集群总结架构特点总结服务器资源：至少6台PC Server部署Redis主从，至少3台PC Server部署Twem