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

认识 redis

redis 的重要功能

用来在内存中存储数据

---

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

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

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

---

对于存储数据来说，直接存在变量中，每每是更快速、更方便的选择，但是若放在分布式体系中，直接界说变量就不可了

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

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

redis 还被一些人当做数据库来使用
   常见的 MySQL 最大的题目在于：访问的速率比力慢。
在许多互联网产物中，对性能要求是很高的，“慢”有时间就是一个很大的题目
  redis 被当做数据库来使用的优点就在于：快，快许多

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

---

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）
  权衡体系的处理请求的能力，是权衡性能的一种方式
  

分布式体系

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

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

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

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

---

绝大部门的公司的产物都是这种单机架构。由于现在的计算机硬件发展速率好坏常快的，这就意味着哪怕我们只有一台主机，这一台主机的性能也好坏常高的，可以支持非常高的并发，非常大的数据存储
假如业务进一步增长，用户量和数据量都水涨船高，当一台主机难以应付的时间，就必要引入更多的主机，引入更多的硬件资源，就必要使用分布式体系了
为什么数据多了主机就难以应对 ？

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

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

---

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

• 开源
  

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

• 节流（软件上优化）
  

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

分布式体系

当一台主机扩展到极限了，但是还不够，就只能引入多台主机了
但不是说买来的新的机器直接就可以解决题目，也必要软件上做出对应的调解和适配。当引入多台主机了，我们的体系就可以称为“分布式体系”了
引入分布式体系是万不得已的，体系的复杂程度会大大大提高（指数增长），这样出现 bug 的概率就越高、加班的概率就越大、丢失年终奖的概率也随之提高

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。