Redis高可用,高性能,架构演进史

时间: 2019-07-26阅读: 272标签: 架构

介绍

上个礼拜,我搭建了一个mongo分片集群,发现分布式系统保证高可用和高性能的套路都差不多。高性能就是做分片(可以类比为分库分表,将数据分到不同服务器上),在Kafka中叫分区,在mongodb中叫shard,在HDFS上叫DataNode。而保证高可用的方式就是做交叉备份。然后我很好奇Redis是怎么部署的。

上测试环境查看集群的状态

info replication

输出如下,好吧,没有做高可用,一个master节点开跑。

# Replication
role:master
connected_slaves:0

一个Redis实例其实有很多问题,最起码Redis崩了就没法提供服务了,而且单机能够承载的QPS在上万到几万不等


replication(复制)

如果业务要承载的QPS在几十万,单机是不可能做到的,此时就可以用到复制。做一个主从架构,一主多从,master节点负责写,slave节点负责读,假如说一个节点可以承载的5w读QPS,那么两个节点就可以承载10w的读QPS,水平扩容非常方便。



master节点挂太多slave节点会有性能问题,此时就可以在slave节点上挂slave节点

redis replication的核心机制有如下几点

1.redis采用异步方式复制数据到slave node,不会block master node的正常工作
2.一个master node可以配置多个slave node,slave node也可以连接其他的slave node
3.slave node主要用来进行横向扩容,做读写分离,扩容的slave node可以提高读的吞吐量

主从复制的实现原理

1.slave连接master,发送SYNC命令; 
2.master接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令; 
3.master BGSAVE执行完后,向slave发送快照文件,并在发送期间继续记录被执行的写命令; 
4.slave收到快照文件后丢弃所有旧数据,载入收到的快照; 
5.master快照发送完毕后开始向salve发送缓冲区中的写命令; 
6.slave完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;


sentinel(哨兵)

主从架构有一个缺点就是如果master节点挂了,那么写服务是不可用的,因为slave节点默认是只读的,这时就重启master节点或者重新配置主从,有没有更好的方案呢?类似zookeeper的组件,能自动完成主从切换。在Redis中还真有,就是sentinel节点,当master节点发生故障能自动完成主从切换。


当master节点挂掉时,sentinel将一个slave节点变成maste节点,当原先的master节点可用时,以slave的角色加入集群。
一个高可用的系统是很忌讳有单点问题的。看到没,sentinel就是一个单点,如果sentinel挂了,主从切换也就没人做了。所以应该将sentinel也做成一个集群


哨兵的作用有如下几点

1.集群监控,负责监控redis master和slave进程是否正常工作
2.消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
3.故障转移,如果master node挂掉了,会自动转移到slave node上
4.配置中心,客户端初始化时,通过哨兵获得master地址,如果故障转移发生了,通知客户端新的master地址


redis cluster(集群)

主从+哨兵,只能保证Redis的高可用,并不能保证Redis的高性能,因为一个master节点并不能放海量数据,而且单个Redis的实例过大时,会导致rdb文件过大,当执行主从同步时时间过长。

如果想做到高性能该怎么办?分片啊,我一开始就提到了,都是一个套路。redis搞几个节点,每个节点存储一部分数据。可想而之,此时查询和插入都得按照一定的分片策略,总不能查询一个数据把所有的redis节点遍历一遍吧。而这种操作不应该放在客户端,中间件兴起了,常见的有codis,twemproxy



图片来自《Redis 深度历险:核心原理与应用实践》

客户端不连接具体的Redis,而是连接Codis,2个Codis节点保证高可用,和Mycat一个套路。

当然Redis作者也意识到这个问题了,redis cluster应用而生。


吐血推荐

1.站长广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入...

2.休闲娱乐: 直播/交友    优惠券领取   网页游戏   H5游戏

链接: http://www.fly63.com/article/detial/4390

软件架构师之路

软件架构师是一名软件开发专家,他可以进行高层设计选择并决定技术标准,包括软件编码标准,工具和平台。软件架构可以被抽象的分为几个层次,不同的层次对技能的要求不同。对层次有很多不同的划分

前端领域不需要架构师?

在传统桌面软件开发中,架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。在工程领域,我们凡是要做点什么事儿,都会有明确的目的性,这个目的性,一定是为了完成生产服务业务的。

实用的软件架构方法

软件架构就是软件的基本结构,它是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。

微前端架构:如何由内而外取代单体架构

如何利用微前端技术实现单体应用程序的现代化改造?在本篇教程中,我们将探讨如何将前端从单体架构当中剥离出来,并快速完成微前端架构迁移。本文作者将结合个人项目实践经验为大家介绍心得。

微服务架构陷阱:过渡设计和设计不足

在这篇文章里,我将简要地介绍在设计微服务架构时需要注意的问题。如果实施得当,就会获得自治能力和灵活性,但同时也会带来通信延迟和部署及托管成本。这篇文章并不是一个高级指南

网站架构优化性能

最初业务量不大,访问量小,此时的架构,应用程序、数据库、文件都部署在一台服务器上,有些甚至仅仅是租用主机空间, 将应用程序、数据库、文件各自部署在独立的服务器上

成为一个优秀架构师,你必须了解的 30 条设计原则

众所周知,架构师的角色,更偏向于策划、而非指挥,塑造、而非支配,其存在的意义,在于引导大家讨论、而非自己主宰一切。但是,具体应该如何执行呢?本文作者整理了 30 个公认的架构原则

创建软件架构时应该关注什么?

软件架构师的首要关注点不是系统的功能,而是软件的品质,软件品质关注点指明了功能呢必须以何种方式交付,才能被系统的利益相关人所接受。作为一个架构师,你应该了解软件产品利益人以及他们的关注点:

基于 NodeJS 的 serverless 架构实践

通过将 BFF 构建于 serverless 之上,将人工智能实验室(天猫精灵)数十个中后台应用整合到了一个统一入口。用云函数的方式取代了传统基于 NodeJS 的 BFF 层,提供了在一个站点下不同应用以及不同环境的快速切换能力

软件架构被高估,清晰简单的设计被低估

软件架构最佳实践、企业架构模式以及系统描述的正式方法都是非常重要且实用的工具,总会有合适的场景让它们发挥作用。但在设计系统时,请从简单始、以简单终,尽可能避免一切会无谓提高复杂度的架构与正式工具

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全