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

更新日期: 2019-07-26阅读: 2.3k标签: 架构

介绍

上个礼拜,我搭建了一个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应用而生。


链接: https://fly63.com/article/detial/4390

微内核架构在大型前端系统中的应用

架构和框架是独立的,本文仅仅是提出一种架构思路,而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念,可以很好的完成高复杂度的前端系统。

怎么判定web前端架构师的能力高低?

软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。传统软件架构描述的对象是直接构成系统的抽象组件,侧重于系统的抽象、拆分、组织方式等

成为一个顶尖架构师

架构师的一个重要职责是,确保团队有共同的技术愿景,以帮助我们向客户交付他们想要的系统。在某些场景下,架构师只需要和一个团队一起工作,这时他们等同于技术引领者。在其他情况下,他们要对整个项目的技术愿景负责,通常需要协调多个团队之间,甚至是整个组织内的工作。

C/S和B/S两种架构区别与优缺点分析

C/S 架构是一种典型的两层架构,其全程是Client/Server,即客户端服务器端架构,其客户端包含一个或多个在用户的电脑上运行的程序,而服务器端有两种,一种是数据库服务器端,客户端通过数据库连接访问服务器端的数据

架构/构建高可用的网站

目的为保证服务器硬件故障时依然可用,数据依然保持并能够访问,手段:数据和服务的冗余备份以及失效转移机制,有状态 :在服务端保留之前的请求信息,用以处理当前请求(例如:session)无状态 :没有特殊状态的服务

大型web系统架构详解

动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。

讲讲亿级PV的负载均衡架构

本来没想写这个题材的,为了某某童鞋能够更好的茁壮成长,临时写一篇负载均衡的。负载均衡,大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的?那这是怎么分的呢,ok,是根据osi七层网络模型来分的,例如nginx是工作在应用层

朱晔的互联网架构实践心得:品味Kubernetes的设计理念

Kubernetes(k8s)是一款开源的优秀的容器编排调度系统,其本身也是一款分布式应用程序。虽然本系列文章讨论的是互联网架构,但是k8s的一些设计理念非常值得深思和借鉴,本人并非运维专家,本文尝试从自己看到的一些k8s的架构理念结合自己的理解来分析 k8s在稳定性

大型网站核心架构要素

一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。性能是网站的一个重要指标,任何软件架构设计档案都必须考虑可能会带来的性能问题。

大型网站技术架构 构建高可用的网站 高可用的服务

本章介绍如何去构建高可用的服务,关键词:服务分级,超时设置,异步调用,服务降级,幂等性设计,一些架构设计中的常用方案,但是需要结合实际业务场景进行设计,没有一套方案能解决所有问题

点击更多...

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