建设政务门户网站的基本意义,网站建设所要花费的资金,百度云官网入口,自动链接 wordpress引言 今天#xff0c;我接到了高中同学刘有码面试失利的消息。 他面试的时候#xff0c;身份是某知名公司的小码农一枚#xff0c;却因为不懂自己生产上Redis是如何部署的#xff0c;导致面试失败#xff01; 人间惨剧#xff0c;莫过于此。 接到他面试失利的消息#x…引言 今天我接到了高中同学刘有码面试失利的消息。 他面试的时候身份是某知名公司的小码农一枚却因为不懂自己生产上Redis是如何部署的导致面试失败 人间惨剧莫过于此。 接到他面试失利的消息我差点发出猪一样的笑声显然是平时太少关注Java技术架构头条号 我提笔6次放笔6次差点因为过于兴奋而没法编下去。最后还是硬着头皮写下了本文! 因此,今天我们来谈谈Redis集群这个话题需要说明的是本文 适合人群不知道自己生产Redis集群架构以及对Redis集群不了解的人不适合群: 对自己生产Redis集群架构非常了解的人 本文预计分两个部分 第一部分:讲讲Redis集群架构的发展第二部分:烟哥彩蛋环节讲讲面试注意事项 正文 老规矩我还是以循序渐进的方式来讲我一共经历过三套集群架构的演进 ReplicationSentinel 这套架构使用的是社区版本推出的原生高可用解决方案其架构图如下 这里Sentinel的作用有三个: 监控:Sentinel 会不断的检查主服务器和从服务器是否正常运行。通知:当被监控的某个Redis服务器出现问题Sentinel通过API脚本向管理员或者其他的应用程序发送通知。自动故障转移:当主节点不能正常工作时Sentinel会开始一次自动的故障转移操作它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点并且将其他的从节点指向新的主节点。工作原理就是当Master宕机的时候Sentinel会选举出新的Master并根据Sentinel中client-reconfig-script脚本配置的内容去动态修改VIP(虚拟IP)将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可 故障发生后的转移情况可以理解为下图 缺陷: (1)主从切换的过程中会丢数据 (2)Redis只能单点写不能水平扩容 ProxyReplicationSentinel 这里的Proxy目前有两种选择:Codis和Twemproxy。我经历这套架构的时间为2015年当时我好像咨询过我的主管为啥不用Codis和Redis官网的Redis Cluster。原因有二: 据说是因为Codis开源的比较晚考虑到更换组件的成本问题。毕竟本来运行好好的东西你再去换组件风险是很大的。Redis Cluster在2015年还是试用版不保证会遇到什么问题因此不敢尝试。 所以我没接触过Codis之前一直用的是Twemproxy作为Proxy。 这里以Twemproxy为例说明如下图所示 工作原理如下 前端使用TwemproxyKeepAlived做代理将其后端的多台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_SLOTCRC16(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}.student1、{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-20Gkey太多降低Redis性能.因此采用分片集群结构已经能保证了我们的性能。其次用上了读写分离后还要考虑主从一致性主从延迟等问题徒增业务复杂度。转载于:https://www.cnblogs.com/CQqf2019/p/11205245.html
