本文
- 前言
- 认识Redis
- 单机架构
- 浅谈分布式系统
- 分布式是什么
- 数据库分离和负载均衡
- 引入缓存
- 数据库分库分表
- 引入微服务
- 念补充
- 小结
- Redis特性介绍
- 持久化
- 支持集群
- 高可用
- 快
- Redis的应用场景
- 总结
前言
在当今这个数据驱动的时代,应用的性能和可扩展性已成为衡量其成功的关键指标。当传统的单机架构面对日益增长的用户量和数据洪流而显得力不从心时,分布式系统便应运而生。然而,系统的分布式演进也带来了新的挑战:如何在多台服务器之间高效、快速地共享和访问数据?
这篇文章将带您认识一个在分布式世界中扮演着至关重要角色的技术——Redis。我们将从最基础的单机架构出发,一步步探索系统如何演进为复杂的分布式集群,并在这个过程中揭示Redis作为高性能内存数据库和缓存中间件的核心价值。无论您是刚入门的开发者,还是希望深化对系统架构理解的工程师,本文都将为您提供一个清晰的路线图,帮助您理解Redis为何能成为现代高性能应用不可或缺的基石。
认识Redis
在内存中进行数据存储
但是我们定义变量不是在内存中进行存储么,那么我们使用redis不是饶了个圈么?
redis是在分布式系统中,才能发挥作用
如果只是单机程序,直接通过变量存储数据的方法是比使用redis更优的选择
在分布式系统中定义变量肯定是不行的,因为进程是具有隔离性的,如果是分布式系统的话肯定是涉及到多个进程的,甚至说这多个进程是分布在不同的主机上,而你想共享别的进程的变量肯定是不行的
所以Redis是基于网络,将自己内存中的变量分享给别的进程,甚至给别的主机中的进程进行使用
mysql现在最大的问题在于,访问速度比较慢,数据在硬盘上
redis也可以作为数据库,在内存上的,速度快
计算机访问内存的速度比访问硬盘的速度快
定性的角度,可以知道redis快很多,但是很难定量衡量,因为mysql和redis具体功能和使用场景都不同
redis和mysql相比,最大的劣势,存储空间是有限的,内存比较小
从功能和存储空间的角度来说,还是mysql更胜一筹的
那么是否存在一个机制,让存储速度快,存储空间大呢
典型的方案就是将mysql和redis结合起来进行使用
用redis作为mysql的cache,将我们经常访问的数据使用redis进行存储,全量数据还是放在mysql中进行存储
代价就是系统的复杂程度大大提升了,如果数据发生成修改的话,还涉及到mysql和redis之间的同步问题
redis的初心,最初就是用来作为一个"消息中间件"的(消息队列)
分布式系统下的生产消费模型
但是当前很少会使用redis作为消息中间件,因为界内有更多专业的消息中间件
单机架构
单机架构,只有一台服务器,这个服务器负责所偶的工作
这里使用的服务器可以是mysql
mysql是一个客户端服务器结构的陈旭
本体是mysql服务器(存储和组织数据的部分)
绝大部分公司的产品都是这种单机架构
如果业务进一步增长了,用户量和数据量都水涨船高了,一台主机难以应付的时候,就需要引入更多的主机,引入更多的硬件资源
浅谈分布式系统
分布式是什么
一台主机的硬件资源是有上限的
硬件资源包括不限于下面几种:CPU、内存、硬盘、网络
服务器每次收到一个请求,都是需要消耗上述的一些资源的
如果同一时刻,处理的请求多了,此时就可能会导致某个硬件资源不够用了
无论是哪个方面不够用了,都可能会导致服务器处理请求的时间变长了,甚至于处理出错
如果我们真的遇到这样的服务器不够的情况,如何进行处理呢
1、开源 增加更多的硬件资源(但是一个主机上能增加的硬件资源也是有限的)
2、节流(软件上的优化)
一台主机扩展到极限了,但是还是不够,就只能引入多态主机了
一但引入多台主机,咱们的系统就可以成为是“分布式系统”
引入分布式,这是万不得已
系统的复杂程度会大大提高的
数据库分离和负载均衡
应用服务器,里面可能会包含很多的业务逻辑,可能会吃CPU和内存
数据库服务器,需要更大的硬盘空间,更快的访问速度,可以配置更大硬盘的服务器
引入更多的应用服务器节点,应用服务器可能比较吃CPU和内存,如果把CPU和内存吃没了,此时应用服务器就顶不住了,引入更多的应用服务器,就可以有效解决上述问题了
用户的请求先到达负载均衡器/网关服务器
假设有1w个用户请求,有2个应用服务器的话,此时按照负载均衡的方式,就可以让每个应用服务器承担5k的访问量
这个就和多线程其实很相似的
负载均衡器,对于请求量的承担能力,要远超过于应用服务器的
负载均衡器是领导,分配工作
应用服务器,是组员,执行任务
也可能请求量大道负载均衡器也扛不住了
那么我们就得引入更多的负载均衡器
增加应用服务器,确实能够处理更高的请求量
但是随之存储服务器,要承担的请求量也就更多了
实际的应用场景中,读的频率比写更高的
引入更多的从服务器
主服务器只有一个
同时从数据库通过负载均衡的方式,让应用服务器进行访问
通过这样降低单台服务器的压力
引入缓存
数据库天然问题,相应速度是更慢的!!
把数据区分"冷热",热点数据放到缓存中~缓存的访问速度往往比数据库快很多了
在数据库读写分离的基础上,这里引入了缓存服务器,存放一小部分热点数据(会频繁被访问的数据)
所以冷数据就是不会被频繁访问的数据
缓存要想快,就得付出代价
redis就是要作为缓存服务器
对应用服务器来说,绝大多数的请求都能从缓存服务器中找到答案,这就是我们的数据库服务器承担的压力变小了,并且我们的缓存服务器读取速度还快
缓存服务器帮助数据库服务器负重前行了
要想得到一个效果,就要付出一定的代价
数据库分库分表
引入分布式系统不光要应对更高的请求量(并发量),同时能应对更大的数据量
可能会出现,一台服务器已经存不下数据了,虽然一个服务器的存储量可以到几十个TB,即使如此也可能会存不下
一台主机存不下,就得需要多台主机了
针对数据库进行进一步的拆分
分库分表
本来是一个数据库服务器,这个数据库服务器上有多个数据库(指的是逻辑上的数据集合,create database创建的那个东西)
现在就可以引入多个数据库服务器,每个数据库服务器存储一个或者一部分数据库
如果某个表特别大,大到一台主机存不下,也可以针对表进行拆分
具体分库分表如何时间,还是要结合实际的业务场景来展开
业务至关重要
引入微服务
微服务架构
之前的应用服务器,一个服务器程序里面做了很多的业务,这就可能会导致这一个服务器的代码越来越复杂了,为了更方便于代码的维护,就可以把这样的一个复杂的服务器,拆分成更多的,功能更单一,更下的服务器,我们将这样小的服务器成为微服务
服务器的种类和数量就增加了
最开始引入负载均衡解决的问题是请求量更高的问题
后面引入的分库分表解决的是存储空间不足的问题
那么微服务本质上解决的是“人”的问题
当应用服务器变复杂了,那么势必就需要更多的人来维护了
当人多了,就需要配套的管理,把这些人组织好
因此就得划分组织结构,分成多个组,每个组配备领导进行管理
分成多个组之后,就需要进行分工了
按照功能,拆分成多组微服务,这样就有利于上述人员组织的结构的分配了
如果是小公司,就几个开发,那么就没必要搞微服务了
引入微服务,解决了人的问题,会有什么代价呢?
1、性能会下降(想保证性能不下降,只能引入更多的机器,更多的硬件资源)
拆出来更多的服务,多个功能之间更要依赖网络通信,
网络通信的速度很可能是比硬盘还慢的
2、系统复杂程度提高,可用性受到影响
服务器更多了,出现问题的概率更大了
这就需要一些列的手段保证系统的可用性
微服务的优势:
1、解决了人的问题
2、使用微服务,可以更方便于功能的复用
3、可以给不同的服务去进行不同的部署
念补充
分布式,引入多个主机/服务器,协同配合完成一系列的工作
主从是分布式系统中一种比较经典的结构
多个服务器节点,一个是主,另一个是从,从节点的数据主要从主节点这里同步过来~~
中间件和业务无关的服务(功能更通用的服务)
- 数据库
- 缓存
- 消息队列
吞吐和并发是衡量系统的处理请求的能力,衡量性能的一种方式
小结
1、单机架构(应用程序+数据库服务器)
2、数据库和应用分离
应用程序和数据库服务器分别放到不同主机上部署了
3、引入负载均衡:应用服务器=>集群
通过负载均衡器,把请求比较君均匀的分发给集群中的每个应用服务器
当整个系统中的某个主机挂了,其他主机仍然可以承担服务,提高了整个系统的可用性
4、引入读写分离,数据库主从结构
一个数据库节点作为主节点,其他n个数据库节点作为从节点
主节点负责写数据,从节点负责读数据
主节点需要把爱修改过的数据同步到从节点
5、引入缓存,冷热数据分离
进一步提升了服务器针对请求的处理能力
二八原则
6、引入分库分表,数据库能够进一步扩展存储空间
7、引入微服务,从业务上进一步拆分应用服务器
从后业务功能的角度,把应用服务器,拆分成更多的功能单一,更简单,更小的服务器
所谓的分布式系统,就是想办法引入更多的硬件资源
Redis特性介绍
Redis是一个在内存中存储数据的中间件,用于作为数据库,用于作为数据缓存
在分布式系统中能够大展拳脚
Redis的一些特定(优点)
Redis在内存中存储数据
mysql主要是通过"表"的方式来存储组织数据的“关系型数据库”
Redis主要是通过“键值对”的方式来存储数据的 非关系型数据库
针对Redis的操作,可以直接通过简单的交互式命令进行操作
也可以通过一些脚本的方式,批量执行一些操作
持久化
Redis 持久化
内存中的数据是易失的
Redis会把数据存储在硬盘上
内存为主,硬盘为辅
硬盘相当于对内存的数据备份一下
如果Redis重启了,就会在重启时加载硬盘中的备份数据,使Redis的内存恢复到重启前的状态
支持集群
Redis 作为一个分布式系统的中间件,能够支持集群是很关键的
这个水平拓展的意思即是“分库分表”
一个Redis 能存储的数据是有限的(内存空间有限)
引入多个主机,部署多个Redis
引入多个主机,部署多个Redis 节点,每个存储数据的一部分
高可用
高可用=>冗余/备份
Redis自身也是支持主从结构的
从节点就相当于主节点的备份了
快
1、Redis数据存在内存中,就比访问硬盘的数据库,要快很多
2、Redis的核心功能都是比较简单的逻辑—核心功能都是比较简单的操作内存的数据结构
3、网络角度上,Redis使用了IO多路复用的方式(epoll)—使用一个线程,管理很多个socket
4、Redis使用的是单线程模型,这样的单线程模型,减少了不必要的线程之间的竞争开销
多线程提高效率的前提是,CPU密集型的任务,使用多个线程可以充分的利用CPU多核资源
但是Redis得核心任务,主要就是操作内存的数据结构,不会吃很多的CPU
Redis的应用场景
- 实时的数据存储,将Redis当做数据库(通过键值对进行数据存储)
大多数情况下,考虑到数据存储,有限考虑的是“大”
但是仍然有一些场景,考虑的是“快”
- 作为缓存
2、将会话数据单独拎出来,放到一组独立的机器上存储(Redis)
分布式系统来说,服务器和服务器之间,有时候也需要使用到生产者消费者模型的
解耦合
削峰填谷
Redis也是已提供了消息队列的功能的
如果当前场景中,对于消息队列的功能依赖的不是很多
并且又不想引入额外的依赖了,Redis可以作为一个选择
Redis不能存储大规模数据
总结
本文深入探讨了Redis的背景、核心特性及其在现代分布式系统中的关键作用。核心要点总结如下:
Redis的核心定位:Redis是一个开源的、基于内存存储的键值对(Key-Value)非关系型数据库。它通过网络为分布式系统中的多个进程提供高速的数据共享服务,其访问速度远超于基于硬盘的传统数据库(如MySQL)。
分布式系统的演进与Redis的价值:随着业务量的增长,系统架构从简单的单机模式,逐步演进为应用与数据库分离、引入负载均衡、实现数据库读写分离的复杂结构。在这一过程中,为了解决数据库的访问瓶颈,引入Redis作为缓存层成为关键一步。通过将频繁访问的“热数据”放入Redis,可以极大减轻数据库的压力,并显著提升应用的响应速度。
Redis的核心特性:
速度快:数据存储在内存中,同时采用I/O多路复用和单线程模型,减少了不必要的上下文切换开销。
持久化:支持将内存数据异步写入硬盘,确保了数据在服务重启后不会丢失。
高可用与可扩展:通过主从复制(Master-Slave)架构保障高可用性,并通过集群模式实现水平扩展,以应对海量数据的存储需求。
丰富的数据结构:支持字符串、哈希、列表、集合、有序集合等多种数据类型,能灵活应对各种业务场景。
主要应用场景:
数据缓存:最核心的应用,作为MySQL等主数据库的缓存,分离冷热数据。
会话共享(Session Store):在分布式Web服务中,集中存储用户会话信息,解决负载均衡下的会话一致性问题。
实时数据存储:适用于对速度要求极高的场景,如排行榜、计数器等。
消息队列:可用于实现简单的生产者-消费者模型,进行服务间的解耦和流量削峰。
总而言之,Redis凭借其卓越的性能和灵活性,已成为构建高性能、高并发和高可用性分布式系统的关键中间件。理解Redis不仅是掌握一个工具,更是深入理解现代应用架构演进思想的重要一环。