Redis -- 前置知识

niceffking

已于 2024-02-01 01:34:18 修改

阅读量820

点赞数 23

分类专栏： Redis 文章标签： redis java 数据库缓存

于 2024-01-28 22:51:40 首次发布

本文链接：https://blog.csdn.net/niceffking/article/details/135895765

版权

Redis 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

学术之路无涯，学习是永无止境的探索。

简要

redis是存储数据在内存中, 定义变量就是在内存中, 但是redis是在分布式系统中, 才能真正发挥威力, 如果只是单机程序, 那么直接通过变量来存储数据的方式将是最优的选择.

redis是如何发挥威力的? 首先进程之间是具有隔离性的, 一个进程想要获取另外一个进程的变量, 由于隔离性是无法直接获取的, 需要进程之间的通信, 也就是通过网络的形式进行通信的, redis就是利用这一点进行了一个封装, 将内存中的变量分享给别的进程, 或者是别的主机的进程进行使用.

redis现在已经被非常多的人使用, 他通常被当做数据库, 缓存流引擎, 中间件等等.

不是有mysql吗? 为什么还需要redis? MySQL最主要的问题就是慢, 很多互联网多产品的性能要求是很高的. 如果要性能, 就需要使用除了MySQL的其他更高性能的技术, redis就是其中之一, redis是使用内存的作为数据库使用, 内存的速度是比外存的速度是快很多的.

下面是各种存储器性能对比:

Redis是很快的, 因为内存的原因, 但是正是因为如此, 他们使用的场景和条件还是有限制的.

它的劣势也很显然, 既然是内存存储的形式, 那么内存的成本肯定是被硬盘等存储的成本高的. MySQL相比来说具有更大的存储空间和更低的成本, mysql也提供了更多的增删改查的功能.

那么有没有一种又快成本又低的存储方式? 最简单的方法就是将两者结合, 典型的方案: Redis和Mysql结合, 也就是将最常用的数据存储在redis, 全部数据存储在mysql, 那么redis就相当于mysql的一个缓存,但是代价就是系统的复杂程度就大大提升了, 且如果数据发生修改, 那么就涉及到redis和mysql的数据同步问题. 这些都是我们接下来要学习的内容.

分布式系统

我们之前的学习都是基于单机架构, 所谓单机架构, 就是只有这一台服务器:

假设为一个电商网站, 其实这里的应用服务就是一个http服务器, 用户发送http请求, 然后应用服务提交请求, 提供数据库服务, 完成服务. 公司绝大部分公司的产品, 都是这种单机架构.

但是当用户量, 数据量非常大的时候, 一台主机的硬件资源(cpu,内存, 硬盘, 网络)是有限的, 一台主机不够用了, 就需要多个这样的单机架构, 引入更多的硬件资源, 构成一个分布式系统.

除了连接多台主机, 还可以在程序上进行优化, 也就是节流, 通过各种性能测试, 找出是哪个环节出现了瓶颈, 然后做出对应的优化. 但是这种方法对于程序员的水平要求较高.

更简单粗暴的方法那就是在硬件上面解决性能问题. 你可以换一个能处理更多线程的cpu, 更好的网卡, 更快的内存, 但是一个主机的极限性能仍然是存在上限的, 还不够的话那么就可以引入更多的主机.

当然不是新的机器买来就可以直接使用的, 在软件上还需要做出代码上的调整. 整体系统的复杂度就更高了, 复杂程度可能呈现一个指数级别增长, bug出现的概率可能更高. (也是属于很无奈了)

下面这个模型是应用服务和数据库服务分离:

应用服务器里面需要处理业务逻辑, 对cpu和内存有更高的要求, 存储服务器则需要更大的存储空间(硬盘空间>> 固态硬盘, 机械硬盘), 以此达到一个更高的性价比

引入更多的服务器:

应用服务器会消耗cpu, 但是如果cpu性能被消耗完了. 服务器就顶不住了, 此时引入另外一个服务器主机(也可能是多个), 就可以解决上述问题. 用户的请求先到达负载均衡器, 假设有1w个请求, 按照负载均衡的机制, 就让每个主机负责5000个请求(根据性能调节)

负载均衡器(就像一个公司领导负责员工的任务), 有很多个均衡的方法, 具体使用哪个方法, 需要根据场景来进行选择

负载均衡

负载均衡器对于请求量的承担能力, 要远超应用服务器的, 就比如我们刚才那个例子, 负载均衡负责分配工作.

软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

既然是有更多的web服务, 那么就意味着更多的web请求, 这么多的web请求, 对于存储服务器来说肯定是会带来更大的压力的. 数据库对于这个请求压力时更加敏感的.

为了解决这个问题, 使用节流的方法, 将数据库的读写进行分离:

此时的存储服务器变成量两台了, 一台是主(master)数据库, 一台从(slave)数据库. 写数据就往主数据库中写, 读取数据就从从数据库中读取, 同时我们定时的将主数据库中的数据同步到从数据库中(实际情况上, 读的操作是比写的操作多的) (因此主服务器一般是一个,从数据库可以有多个).