【Redis_Day1】分布式系统和Redis

单机架构

单机架构：只有一台服务器，这个服务器负责所有的工作。

在一个B/S架构下的网站项目中，如果该项目是由单机系统运行的，则应用服务和和数据库服务都只由一台服务器负责。（应用服务->后端程序员写的一个http服务器程序。数据库服务->用数据库存储数据）

如果业务进一步增长->用户量和数据量都水涨船高->一台主机难以应付时，就需要引入更多的主机,引入更多的硬件资源一起处理业务。

分布式系统：引入多台主机，协同配合完成一系列工作。->系统的复杂程序大大提高（引入分布式是万不得已）

分布式系统

应用/数据分离架构

最简单的分布式系统，是让两台服务器共同处理工作，一台处理应用服务，一台处理数据库服务。

其中，应用服务器工作时要处理更多的业务逻辑，可以配置性能更高的cpu和内存。
数据库服务器需要更大的硬盘空间，更快的数据访问速度，可以配置容量尽可能大的硬盘，甚至是SSD硬盘（固态硬盘）。

应用服务通过网络访问数据。

最简单的分布式系统就是基于应用数据分离架构的。

应用服务器集群架构

一般，应用服务器更加消耗cpu和内存资源，当cpu和内存资源被消耗的快用尽的时候，可以引入更多的应用服务器一起处理业务。同时在应用服务器的上一层引入负载均衡器。它的缺点是系统更加复杂了。

通过调整软件架构，增加应用层硬件，将用户流量分担到不同的应⽤层服务器上，来提升系统的承载能⼒，这种直接引入更多应用服务器来处理大量请求的方案也被称为应用服务集群架构。

负载均衡器：接收客户端请求后再把请求分派给各个处理请求的服务器们

负载均衡器是独立于应用服务器和存储服务器的服务器，它的作用是接收客户端请求后再把请求分派给各个处理请求的服务器们。如果请求量太多到负载均衡器承担不了，就引入更多的负载均衡器。

负载均衡器相当于分配工作的领导，应用服务器相当于执行任务的组员。
负载均衡器对请求量的承担能力远超实际处理请求的服务器，处理请求的服务器处理请求的能力远超负载均衡器。
负载均衡器负责给实际处理请求的服务器们分配任务，而具体是如何分配的，由具体的分配算法决定。常见的分配算法有Round-Robin轮询算法，Weight-Round-Robin轮询算法，⼀致哈希散列算法等。

比如，一个分布式系统有要处理1w个用户请求，该系统共有两个应用服务器，一个存储服务器，一个分派请求给应用服务器的负载均衡器 -> 该分布式系统可能是如何处理这1w个请求的？-> 1w个用户请求先到达负载均衡器，负载均衡器根据分配算法，把请求分配给应用服务器，每个应用服务器只处理自己要处理的请求即可。

数据库读写分离架构

增加应用服务器的数量可以处理更多的请求，但处理这些请求最终都要从数据库读写数据，当数据多到一定程度后，也会超出存储服务器的瓶颈。
但是，我们不能像增加应用服务器那样增加存储服务器。这是因为对⼀个系统来说，需要时刻保证数据的同步。盲目增加存储服务器会导致数据不同步等问题。

如果解决数据库服务器的压力呢？指定一台数据库服务器专门处理对数据的写操作，这台服务器也叫主库。另一台数据库服务器专门处理对数据的读操作，这台服务器叫从库。从库的所有数据全部来自主库，主从库时刻保持数据同步。这就是数据库读写分离架构。

在实际应用场景中，读的频率远高于写。一般有一个主库，多个从库。同时在从库的上层引入负载均衡器，让应用服务器进行访问。

冷热数据分离架构

数据库有个无法避免的问题，如果数据保存在硬盘中，响应速度较慢！数据保存在内存中，可存储的数据较少！

在读写分离架构上继续引入缓存服务器。缓存容量小，但速度远高于主库和从库。

把数据分为冷数据和热数据。热数据就是会被频繁访问到的数据。
通常，冷热数据的数量遵循“二八原则”，20%热数据，80冷数据。

冷数据放到主从库中，热数据保存在缓从服务器中，或者放在用户本地缓存中。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。
常见的缓存软件：本地缓存-Memcached；外部缓存-Redis。

当然，想要实现缓存也是要付出代价的——比如：如何保证缓存和主库的数据同步？

分库分表

在数据库读写分离架构中，虽然减轻了存储服务的压力。但是，写操作涉及的数据依然全部保存在一台机器中，如果主库存不下呢？

在数据库读写架构中，一台主库上存储着有多个数据库（这的数据库指的是通过create database创建的数据库）。在分库分表架构中，引入多个存储服务器，每个存储服务器存储一个或多个数据库。如果一台存储服务器上只存了一张表，但是这张表很大，这台服务器也存不下，可以把这张大表拆分成多个小表，同时引入存储服务器，每个存储服务器上保存一张小表。

微服务架构

在上述一系列的架构升级中，项目后台不但能存储更多的数据，同时也能处理更多的请求。但是架构升级之路还没有到头。

之前的应用服务器，一个服务器程序里面做了很多的工作，这会导致这个服务器里的代码变得越来越复杂。为了方便代码的维护，可以把这个复杂的应用服务器拆分成更多的，功能更单一的，但是更小的服务器。服务器之间通过网络进行交互。这就是微服务。

分布式中的常用名词

应用/系统：一个应用就是一个或一组服务器程序。⽣活例⼦类比：为了完成⼀项任
务，而搭建的由⼀个⼈或者⼀群相互配的⼈组成的团队。

模块/组件：一个应用里面通常由很多个功能，每个独立的功能，可以称之为一个模块/组件。

分布式：引入多个主机/服务器，协同配合完成一系列的工作。

集群：逻辑上的分布式。

主/从：分布式系统中比较典型的结构。在多个服务器节点中，其中一个是主结点，另外的都是从结点，从结点的数据都是从主结点里同步来的。

中间件：和业务无关的服务，功能更通用的服务。生活例子类比：⼀家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变大，成立⼀个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。

系统可用性：系统整体可用的时间/总的时间。年化系统可用性=系统正常提供
服务时长/⼀年总时长。平时我们常说的4个9即系统可以提供99.99%的可用性，5个9是99.999%的可用性，以此类推。

响应时长：服务器处理一次请求消耗的时间。

吞吐量vs并发量：用来衡量系统处理请求的能力。吞吐量考察单位时间段内，系统可以成功处理的请求的数量。并发量指系统同⼀时刻支持的请求最高量。例如⼀条两车道高速公路，⼀分钟可以通过20辆车，则并发是2，⼀分钟的吞吐量是20。实践中，并发量往往无法直接获取，很多时候都是用极短的时间段（比如1秒）的吞吐量做代替。

Redis档案

redis官方名片：Redis是开源的、在内存中存储数据、作为一个数据库/缓存/流式引擎/消息中间件被广泛使用。

redis核心功能：把数据保存在内存中。在内存中存储数据有两种方法，一种是定义变量，还有一种就是使用Redis。

redis使用场景：分布式系统。在单机程序中，可以通过定义变量把数据保存在内存中。但在分布式系统中，通常使用Redis把数据存在内存中。因为redis基于网络，可以把自己内存中的变量给别的进程，甚至给别的主机的进程进行使用。

redis特性：
1. 在内存中存储数据。Redis是非关系型数据库，不同于mysql用“表”组织数据，Redis主要通过“键值对(Key-Value)”的方式来存储数据。用数据结构来组织数据，Key都是String，Value可以是hashes，lists，sets，等等。
2. Redis是可编程的。针对Redis的操作，可以直接通过简单的交互式命令进行操作，也可以通过一些脚本的方式批量执行一些操作。
3. 可以在Redis原有的功能基础上再进行扩展。Redis提供了一组API，用C++，C，或Rust语言调用API编写Redis扩展，即自己写代码去扩展Redis的功能。比如，Redis自己已经提供了很多的数据结构和命令，通过扩展，让Redis支持更多的数据结构和命令。
4. Redis是持久化存储。进程退出和系统重启都会丢失内存中的数据，所以Redis会把数据在内存和硬盘中各存一份，硬盘相当于对内存的数据备份了一下，如果Redis重启了，就会在重启时加载硬盘中的备份数据，使Redis的内存恢复到重启前的状态。
5. 支持集群。内存空间有限，所以一个Redis能存储的数据也是有限的。此时，可以引入多个主机，部署多个Redis结点，每个Redis存储数据的一部分。
6. 高可用。Redis自身也支持“主从”结构，从节点是通过复制主节点得到的。
7. 访问速度快。数据在内存中，比访问硬盘的数据库快很多。主要体现在以下三点：

• Redis的核心功能就是操作内存的数据结构，不是很消耗CPU资源，
• Redis执行命令时使用的单线程模型，减少了不必要的线程之间的竞争开销。（高版本的Redis中引入了多线程，这里的多线程是针对io的），
• 站在网络通信的角度上，Redis使用了IO多路复用的方式。

redis身份1->数据库：redis作为数据库(数据库服务器)，和mysql相比，它的速度更快，但它可用的内存空间有限，功能也没有mysql多。

redis身份2->缓存：redis和mysql结合使用->redis作为mysql的cache->经常访问的数据用redis存储，全量数据用mysql存储->系统的复杂度提高，但产品速度快的同时可用的存储空间也大。

redis身份3->会话存储：基于http协议下的项目，服务端通常都会有session机制。session中存储着用户信息。在分布式系统中，把session数据单独拎出来，放到一组单独的机器中存储（该组机器上部署Redis）。应用服务器处理请求时，先去Redis中把会话拿到。

redis身份4->消息队列：此处消息队列指的是一个服务器，基于该消息队列可以实现一个“网络版本”的生产者消费者模型。即在分布式系统中，服务器和服务器之间，有时也需要使用到生产者消费者模型。业界有名的消息队列有RabbitMQ，Kafka，RocketMQ等，当然，还有Redis哈哈。如果当前项目中已经有Redis作为缓存，且对于消息队列的功能依赖的不是很多，且不想引入额外的依赖，可以选择用Redis。

更多Redis内容可移步Redis官方文档：redis.io

小结~

1. 单机架构：应用服务和数据库服务在一台机器上。
2. 数据库和应用分离：应用程序和数据库放在不同的机器上部署了。
3. 应用服务器集群，引入负载均衡，通过负载均衡器，把请求比较均匀的分发为集群中的每个应用服务器。此时当集群中的某个主机挂了，其他的主机依然能承担服务。引入负载均衡器提高了整个系统的可用性。
4. 引入读写分离，即数据库主从结构。一个数据库结点作为主节点，其他N个数据库结点作为从结点，主节点负责写数据，从节点负责读数据。主节点需要把修改过的数据同步给从节点。
5. 引入缓存，即冷热数据分离。进一步提升服务器对请求的处理能力。Redis在一个分布式系统中，通常就是缓存，即存储热数据。
   留坑：数据库和缓存的数据一致性如何保证？
6. 分库分表，即进一步扩展数据库的存储空间。
7. 引入微服务，从业务上进一步拆分应用服务器。从业务功能的角度，把应用服务器拆分成更多的功能更单一，更简单，更小的服务器。
8. Redis是一个使用内存存储数据的中间件，一般被作为内存数据库/缓存/消息队列来使用。Redis的最大优势-快。

业务是更重要的，技术只是给业务提供支持的。一个商业项目的后台架构演化取决于实际业务。

而所谓的分布式系统，就是想办法引入更多的硬件资源处理业务。

---

纸上谈兵结束~
终于要上操作了！