前言

我们学习redis之前，要先对redis和周边的场景了解，我们才能知其然知其所以然。

• 本篇文章主要和大家谈分布式架构的演变

1. 认识Redis

• Redis：

  Redis是一个开源的，进行内存级存储的通常是被用作是数据库、缓存、流处理引擎、消息中间件（消息队列）……

1. 存储数据—内存级

   存储数据的话直接将数据定义变量存储不就可以了吗？为什么还需要使用Redis呢？我们需要对业务场景进行分析：如果是单机的程序，那么我们将数据以变量的形式直接存储即可，这样的效率甚至高于使用Redis；但是如果是分布式架构（多台主句）的服务，就需要Redis出场了。因为进程是具有隔离性的，如果想要不同主机上的进程进行通信的话，更是需要网络服务。一般而言网络服务的速度更是小于硬件IO效率！
   Redis就是基于网络服务，将内存中的数据供同台主机的不同进程和不同主机的进程使用！！！

2. 作为数据库：

   我们了解比较多的数据库就有：Mysql。但是Mysql有一个最大的问题：数据的存储是在硬件磁盘上的（虽然有缓存），但是在很多场景下是无法满足产品的高性能需求的。但是Redis不一样了，Redis可以作为数据库使用，而且定性来说Redis数据库的访问速度一定是优于Mysql的。同时Redis也有一个致命的缺陷：由于在内存中的存储导致了Redis的存储空间是优先的！！！

   • 所以我们有一种方案：综合Redis和Mysql。

     我们可以将热数据（经常访问的数据）存储在Redis中，将一些不常用的数据存储在Mysql中。但是这样同时有一个难点：程序员控制Redis和Mysql的数据同步问题，系统的复杂程度大大提高！

2. 分布式构架

我们从单机架构上进行演变分析，一步一步更新分布式的架构
下面我以一个电商服务为例

2.1 单机架构

• 如下图：
  

• 单机架构：

  只有一台服务器，该服务器承担所有的功能。（数据存储功能可以交给Mysql，甚至我们也可以让自己的机器进行数据的存储）

• 弊端：

  这样的单机架构的缺点也明显：如果业务进行增长，数据用户的访问量和数据的存储量变大，一台主机可能会扛不住了。

• 一个事实：

  一台主机的资源（CPU、内存、硬盘……）是有限的。而服务器在被用户访问的时候都是会消耗一定的主机资源的，所以当某一时刻用户较多了有可能就导致主机的资源不够用。就会导致服务器处理用户请求的时间变长，甚至出错！

• 处理思路：

  1. 开源：提供更多的硬件资源。但是一台主机能扩展的资源也是有上限的（这取决于主板）所以如果当一台主机无法进行扩展了，那么就只能引入多台主机了。一旦引入了多台主机，我们就可以把系统称为：分布式系统。
  2. 节流：软件优化，算法优化，存储结构进行优化（对程序员要求较高）。

2.2 应用服务和数据库服务分离

• 如下图：

  

将应用服务和数据库服务分离的好处：

1. 对于应用服务来说，不用再内部处理对数据库的管理，只需要管理如何将请求交给数据库服务的主机即可。能够得到相较于之前更多的CPU资源、内存资源……
2. 对于数据库服务来说，可以拿到更大的硬件磁盘存储，能够获得更快的访问速度！！

• 但是这个架构仍然没有解决一个问题：

  当请求量较多的时候，我们的单台服务器主机是可能扛不住请求的，导致处理请求速度减慢……等等问题！

2.3 负载均衡式多服务主机

• 为了解决我们一台主机的请求量过多的问题，我们可以尝试着用多台主机来处理用户的请求，但是这也诞生了一个问题：有没有可能有一台主机被经常访问，而另外一台主机不常被访问？所以为了解决这个问题，在应用服务主机的上层，我们可以添加一个负载均衡机器，如下图：

  

  上面的主机不局限于2台

• 当用户对服务器进行访问的时候，用户的请求会优先访问上层的负载均衡器（也是一个服务器），将请求交给负载均衡器，负载均衡根据一定的算法，选择下层合适的主机，将用户的请求交给合适的主机处理。例如，在两台的情况下，1w的用户请求量，我们根据负载均衡的算法，可能下层的每台主机能够处理5k条用户请求！

• 这样就诞生了一个问题：上层的负载均衡服务器，不久承受了1w的访问量吗？

  但是，不用担心。因为上层的负载均衡服务的功能不在于处理实际的业务逻辑。从身份上，他更多的是一个“领导者”，向下层分派任务。所以作为负载均衡服务来说，他的承受访问的能力远远高于应用服务器的。

• 弊端：

  1. 对于上层来说：虽然能够处理的请求较多了，但是用户请求多了，负载均衡器仍然可能无法支持这样的工作，所以在这一层我们可以：引入更多的负载均衡器（引入多个机房）。

  2. 对于下层来说：虽然上层能够应付大量的请求了。但是下层的数据库服务呢？随着用户量的增多和请求的增多，下层的数据库服务总有捉襟见肘的时候。那么这个问题如何处理呢？

2.4 数据库服务的读写分离

上层能够处理大量请求了，但是下层的数据库服务可能扛不住这样的压力。

• 对于上层的用户请求来说：在实际的场景中，读数据的概率多大于写数据的概率。所以，我们可以将数据库服务的读写服务进行分离，如下图：

  
  如上图，我们可以将数据的读写功能进行不同主机的部署。其中注意：

  1. 用于写数据的服务，一般被称为：master(主)。

  2. 用于读数据的服务，一般被称为：slave(从)。

  而主从之间需要进行数据的同步问题。从服务器的数据要根据主服务器的数据变化进行更新。同时，从服务器可以有多个，我们也可以在下层采用多个读数据的服务，还是采用负载均衡的方式对读数据的请求进行处理。但是注意：主服务器只能有一个。

• 但是数据库服务有一个天然存在的问题：访问数据太慢了！那么我们应该如何解决呢？

2.5 冷热数据分离

注意：这里的冷热数据分离不是真正的分离，而是访问的位置是不同的！

• 一个事实：

  在100%的数据中，有20%的数据是热数据（经常被访问的数据），有80%的数据是冷数据（不经常被访问的数据）。二八原则。（不同场景之下是有差异的）

• 所以，在这样的情况下，我们可以将一部分被频繁访问到的数据存储在缓冲服务器中，如下图：

  

缓存为我们提供了访问数据的效率，但是同时也有一个问题，缓存是在内存中的，这就不可避免了一个问题：缓存能存储的数据是比较小的！（相较于磁盘的数据库服务）

• Redis就是扮演者这个缓存的角色！

在后续还有一系列的架构，例如：

1. 数据库集群架构。面对大量需要存储的数据量，对数据库进行分库分表的模式，不再依靠一个数据库/表。每个数据库服务器都可以存储一个/一部分数据库。甚至当一台主机的数据量非常大，大到一个表放不下的时候，我们还可以对表进行拆分。
2. 微服务架构。将不同的业务逻辑分离，例如上面的用户、商品、订单模块都可以分离开成为一个小模块，便于维护代码和代码的复用。

总结

• 不管上面任何一个结构，我们都需要依照实际的业务需求进行具体问题具体分析。没有一成不变的架构模式，一切技术都是为了上层业务服务的！例如：单台主机就能解决的业务场景，我们有必要进行微服务吗？完全没有必要！