【原创】那些年用过的Redis集群架构（含面试解析）

引言

今天是2019年2月12号，也就是大年初八，我接到了高中同窗刘有码面试失利的消息。

他面试的时候，身份是某知名公司的小码农一枚，却由于不懂本身生产上Redis是如何部署的，致使面试失败！

人间惨剧，莫过于此。

接到他面试失利的消息，我差点发出猪同样的笑声，显然是平时太少关注孤独烟这个公众号！

我提笔6次，放笔6次，差点由于过于兴奋而无法编下去。最后仍是硬着头皮写下了本文!

所以,今天咱们来谈谈Redis集群这个话题，须要说明的是本文

• 适合人群：不知道本身生产redis集群架构，以及对Redis集群不了解的人
• 不适合群: 对本身生产Redis集群架构很是了解的人

本文预计分两个部分

• 第一部分:讲讲Redis集群架构的发展
• 第二部分:烟哥彩蛋环节，讲讲面试注意事项！

ps:烟哥彩蛋环节的内容，小白必背！必背！必背！

正文

老规矩，我仍是以按部就班的方式来说，我一共经历过三套集群架构的演进！

Replication+Sentinel

这套架构使用的是社区版本推出的原生高可用解决方案，其架构图以下！

这里Sentinel的做用有三个:

• 监控:Sentinel 会不断的检查主服务器和从服务器是否正常运行。
• 通知:当被监控的某个redis服务器出现问题，Sentinel经过API脚本向管理员或者其余的应用程序发送通知。
• 自动故障转移:当主节点不能正常工做时，Sentinel会开始一次自动的故障转移操做，它会将与失效主节点是主从关系 的其中一个从节点升级为新的主节点，而且将其余的从节点指向新的主节点。

工做原理就是，当Master宕机的时候，Sentinel会选举出新的Master，并根据Sentinel中client-reconfig-script脚本配置的内容，去动态修改VIP(虚拟IP)，将VIP(虚拟IP)指向新的Master。咱们的客户端就连向指定的VIP便可！
故障发生后的转移状况，能够理解为下图

缺陷:
(1)主从切换的过程当中会丢数据
(2)Redis只能单点写，不能水平扩容

Proxy+Replication+Sentinel

这里的Proxy目前有两种选择:Codis和Twemproxy。我经历这套架构的时间为2015年，当时我好像咨询过个人主管为啥不用Codis和Redis官网的Redis Cluster。缘由有二:

• 听说是由于Codis开源的比较晚，考虑到更换组件的成本问题。毕竟原本运行好好的东西，你再去换组件，风险是很大的。
• Redis Cluster在2015年仍是试用版，不保证会遇到什么问题，所以不敢尝试。

因此我没接触过Codis，以前一直用的是Twemproxy做为Proxy。
这里以Twemproxy为例说明，以下图所示

工做原理以下

• 前端使用Twemproxy+KeepAlived作代理，将其后端的多台Redis实例分片进行统一管理与分配
• 每个分片节点的Slave都是Master的副本且只读
• Sentinel持续不断的监控每一个分片节点的Master，当Master出现故障且不可用状态时，Sentinel会通知/启动自动故障转移等动做
• Sentinel 能够在发生故障转移动做后触发相应脚本（经过 client-reconfig-script 参数配置 ），脚本获取到最新的Master来修改Twemproxy配置

缺陷:
(1)部署结构超级复杂
(2)可扩展性差，进行扩缩容须要手动干预
(3)运维不方便

Redis Cluster

我经历这套架构的时间为2017年，在这个时间Redis Cluster已经很成熟了！大家在网上能查到的大部分缺点，在我接触到的时候基本已经解决!
好比没有完善的运维工具？能够参照一下搜狐出的CacheCloud。
好比没有公司在生产用过？我接触到的时候，百度贴吧，美团等大厂都用过了。
好比没有Release版？我接触到的时候距离Redis Cluster发布Release版已经好久。
并且毕竟是官网出的，确定会一直维护、更新下去，将来一定会更加成熟、稳定。换句话说，Redis不倒，Redis Cluster就不会放弃维护。因此，我推荐仍是这套架构!
以下图所示

工做原理以下

• 客户端与Redis节点直连,不须要中间Proxy层，直接链接任意一个Master节点
• 根据公式HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪一个分片上，而后Redis会去相应的节点进行操做

具备以下优势:
(1)无需Sentinel哨兵监控，若是Master挂了，Redis Cluster内部自动将Slave切换Master
(2)能够进行水平扩容
(3)支持自动化迁移，当出现某个Slave宕机了，那么就只有Master了，这时候的高可用性就没法很好的保证了，万一master也宕机了，咋办呢？ 针对这种状况，若是说其余Master有多余的Slave ，集群自动把多余的Slave迁移到没有Slave的Master 中。

缺点:
(1)批量操做是个坑
(2)资源隔离性较差，容易出现相互影响的状况。

烟哥彩蛋

在面试中若是碰到下列问题，如何应用上本篇的知识呢？先明确一点，我推荐的是Redis Cluster。
OK，开始举例说明

问题1:懂Redis事务么？
正常版：Redis事务是一些列redis命令的集合,blabla...
高调版: 咱们在生产上采用的是Redis Cluster集群架构，不一样的key是有可能分配在不一样的Redis节点上的，在这种状况下Redis的事务机制是不生效的。其次，Redis事务不支持回滚操做，简直是鸡肋！因此基本不用！

问题2:Redis的多数据库机制，了解多少？
正常版：Redis支持多个数据库，而且每一个数据库的数据是隔离的不能共享，单机下的redis能够支持16个数据库（db0 ~ db15）
高调版: 在Redis Cluster集群架构下只有一个数据库空间，即db0。所以，咱们没有使用Redis的多数据库功能！

问题3:Redis集群机制中，你以为有什么不足的地方吗？
正常版: 不知道
高调版: 假设我有一个key，对应的value是Hash类型的。若是Hash对象很是大，是不支持映射到不一样节点的！只能映射到集群中的一个节点上！还有就是作批量操做比较麻烦！

问题4:懂Redis的批量操做么？
正常版: 懂一点。好比mset、mget操做等，blabla
高调版: 咱们在生产上采用的是Redis Cluster集群架构，不一样的key会划分到不一样的slot中，所以直接使用mset或者mget等操做是行不通的。

问题5:那在Redis集群模式下，如何进行批量操做？
正常版:不知道
高调版:这个问题其实能够写一篇文章了，改天写。这里说一种有一个很简单的答法，足够面试用。即:
若是执行的key数量比较少，就不用mget了，就用串行get操做。若是真的须要执行的key不少，就使用Hashtag保证这些key映射到同一台redis节点上。简单来讲语法以下

对于key为{foo}.student一、{foo}.student2，{foo}student3，这类key必定是在同一个redis节点上。由于key中“{}”之间的字符串就是当前key的hash tags， 只有key中{ }中的部分才被用来作hash，所以计算出来的redis节点必定是同一个!

ps:若是你用的是Proxy分片集群架构，例如Codis这种，会将mget/mset的多个key拆分红多个命令发往不一样得redis实例，这里很少说。我推荐答的仍是redis cluster。

问题6:大家有对Redis作读写分离么？
正常版:没有作，至于缘由额。。。额。。。额。。没办法了，硬着头皮扯~
高调版:不作读写分离。咱们用的是Redis Cluster的架构，是属于分片集群的架构。而redis自己在内存上操做，不会涉及IO吞吐，即便读写分离也不会提高太多性能，Redis在生产上的主要问题是考虑容量，单机最多10-20G，key太多下降redis性能.所以采用分片集群结构，已经能保证了咱们的性能。其次，用上了读写分离后，还要考虑主从一致性，主从延迟等问题，徒增业务复杂度。

总结

本文讲了redis集群架构的演进，以及面试注意事项，但愿你们有所收获!