【redis】认识redis和分布式系统

认识 redis

redis 的主要功能

用来在内存中存储数据

定义变量不就是在内存中存储数据吗？为什么还需要 redis 来向内存中存储数据？这不是绕了一个圈嘛？

• redis 是在分布式系统中才能发挥威力
• 如果只是单机程序，直接通过变量存储数据的方式，是比使用 redis 更优的选择

由于我们现在很多的系统都是分布式的系统，在分布式系统中，若想让多个服务器都共享同一份数据，又想这个数据存在于内存中，此时使用 redis 就是一个可选的选择了

对于存储数据来说，直接存在变量中，往往是更快速、更方便的选择，但是若放在分布式系统中，直接定义变量就不行了

• 因为你定义的变量是在你当前服务器进程中的一块空间
• 进程具有隔离性，每个进程之间都是被隔离开的，进程 A 无法读取进程 B 中的数据
• 如果是在分布式系统下，肯定会涉及到多个进程，甚至是在不同的主机上的多个进程，此时你想直接访问其他内存中的变量，这件事就变得困难起来了 redis 就是针对上述的功能点进行了封装，既然没法突破进程的隔离性直接进行访问，那就使用“进程间通信“，网络 就是其最主流方案

网络既可以让同一个主机间的进程进行通信，而且还可以让不同主机之间的进程进行通信，因此，redis 就相当于是基于网络，能够把自己内存中的的变量给别的进程、甚至别的主机的进程进行使用

实现数据库

redis 还被一些人当做数据库来使用

常见的 MySQL 最大的问题在于：访问的速度比较慢。 在很多互联网产品中，对性能要求是很高的，“慢”有时候就是一个很大的问题

redis 被当做数据库来使用的优点就在于：快，快很多

• 核心在于它是用内存存储数据的，而 MySQL 的数据是在硬盘上的
• 计算机访问内存的速度比访问硬盘的速度快几千上万倍

image.png|491

redis 和 MySQL 相比，最大的劣势是：存储空间是有限的

• 虽然有不少的互联网产品，对性能要求是很高的，就需要访问速度很快
• 但更多的互联网产品对于性能的要求没那么高，同时又希望用更低的成本存更多的数据，显然 MySQL 是更好的选择，同时 MySQL 相比于 redis 来说，提供了更丰富的功能

实现缓存

那有没有存储空间又大，访问速度又快的方案呢？

• 典型的方案就是把 redis 和 MySQL 结合起来
• 把热点数据（经常访问的数据）就用 redis 来存储，把全量数据就用 MySQL 来存储
• “二八原则”，20% 的热点数据能满足 80% 的访问需求

这就是缓存的机制，不过这样系统的复杂程度就会大大提高。而且，如果数据发生修改，还会涉及到 redis 和 MySQL 之间的数据同步问题

实现消息中间件

redis 的初心，就是作为一个“消息中间件”（消息队列），实现分布式系统下的生产者消费者模型 但当前很少会直接使用 redis 作为消息中间件，因为业界中有更多更专业的消息中间件可以使用

基础概念

• 应用（Application）/系统（System） 一个应用，就是一个/组服务器程序
• 模块（Module）/组件（Component） 一个应用，里面有很多的功能，每个独立的功能，就可以称为是一个模块/组件
• 分布式（Distributed） 引入多个主机/服务器，协同配合完成一系列的工作（物理上的多个主机）
• 集群（Cluster） 通过多个服务器/主机，去协同配合完成一系列的工作（逻辑上的多个主机，一个服务器上部署多个服务器程序，这些服务器程序之间也是通过网络进行通信，看上去也是和多个主机没什么区别，但在硬件上还是一个主机）
• 主（Master）/从（Slave） 分布式系统中，一种比较典型的结构。比如现在有多个服务器节点，其中一个是主，另外的是从。这个时候从节点就是主节点的跟班（从节点的数据要从主节点同步过去），
• 中间件（Middleware） 一组和业务无关的服务（功能更通用的服务，数据库、缓存、消息队列…）

评价指标

• 可用性（Availability） 系统整体可用的时间÷总的时间（这个结果越高越好） 一个系统的第一要务
• 响应时长（Response Time RT） 衡量服务器的性能，越小越好，和具体服务器要做的业务密切相关
• 吞吐（Throughput）vs 并发（Concurrent） 衡量系统的处理请求的能力，是衡量性能的一种方式

分布式系统

千万不要把所谓的“分布式”想的太复杂，太高大上…

单机架构

image.png|591

此处假定是一个“电商网站”，用户通过网络访问这个服务器，其分为两个部分：

1. 应用服务：我们写的服务器程序
   • 就是说用户打开这个网站，页面上要能显示商品信息，点进去能看到详情，能下单… 这些预计的功能就是通过这个“应用服务器/HTTP服务器这样的程序”来支撑的
   • C++ 里面的 cpp-hyyplib
   • Java 里面的 Spring
   • 这俩都是用来写 HTTP 服务器的
2. 数据库服务：
   • 用来存储这个网站中大量的数据
   • 可以使用 MySQL
     • MySQL 是一个“客户端-服务器“结构的程序，本体是 MySQL 服务器（存储和组织数据的部分）
     • 上面的 HTTP 应用服务服务器作为客户端，去读写数据库服务

• 当用户现在查看商品列表，那么应用服务器（HTTP 服务器） 就会发送请求给 MySQL 服务器，然后 MySQL 查找数据之后将数据返回给应用程序，最后应用程序通过 HTTP 协议，最终将信息返回给用户

绝大部分的公司的产品都是这种单机架构。因为现在的计算机硬件发展速度是非常快的，这就意味着哪怕我们只有一台主机，这一台主机的性能也是非常高的，可以支持非常高的并发，非常大的数据存储

如果业务进一步增长，用户量和数据量都水涨船高，当一台主机难以应付的时候，就需要引入更多的主机，引入更多的硬件资源，就需要使用分布式系统了

为什么数据多了主机就难以应对 ？

一台主机的硬件资源是有上限的，包括但不限于一下几种：

• CPU
• 内存
• 硬盘
• 网络
• … 服务器每次收到一个请求，都是需要消耗上述的一些资源的~~ 如果同一时刻处理的请求多了，此时就可能会导致某个硬件资源不够用了，无论是那个方面不够用了，都可能会导致服务器处理请求的时间变长，甚至于处理出错

如果我们真的遇到了这样的服务器不够用的场景，我们可以：

1. 开源

• 简单粗暴，直接增加更多的硬件资源（什么不够补什么）
• 不过一个主机上面能增加的硬件资源也是有限的，取决于主板的扩展能力

1. 节流（软件上优化）

• 针对程序进行优化，优化代码（各凭本事）
• 通过性能测试，找到是哪个环节出现了瓶颈，再对症下药
• 操作起来很难！对程序员的水平要求比较高

分布式系统

当一台主机扩展到极限了，但是还不够，就只能引入多台主机了

但不是说买来的新的机器直接就可以解决问题，也需要软件上做出对应的调整和适配。当引入多台主机了，我们的系统就可以称为“分布式系统”了

引入分布式系统是万不得已的，系统的复杂程度会大大大提高（指数增长），这样出现 bug 的概率就越高、加班的概率就越大、丢失年终奖的概率也随之提高