浅谈分布式系统

前言： 

Redis 是一个基于内存的数据存储系统，能够提供非常快的读写速度。虽然它也支持持久化功能，但其主要设计是为了在内存中操作数据 为了更好的学习Redis，我们得先了解一下分布式系统，只有在分布式系统中，才能发挥Redis的“威力”，如果只在单机程序中，可以直接通过变量来存储数据，是比使用Redis的选择更优

常⻅概念

在正式引⼊架构演进之前，为避免读者对架构中的概念完全不了解导致低效沟通，优先对其中⼀些⽐较重要的概念做前置介绍：

1. 1 应⽤（Application）/系统（System）

一个应用/系统 指 一个或一组 服务器程序

1.2模块（Module）/?组件（Component） 

一个应用里面有多个功能 每个独立的功能 指的就是一个模块/组件 

1.3 分布式（Distributed） 

 指的就是引入多台主机/服务器，协同完成某项工作

1.4 集群（Cluster） 

 指的就是引入多台主机/服务器，协同完成某项工作

分布式vs集群。通常不⽤太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即⼯作在不同服务器上并且通过⽹络通信配合完成任务；⽽集群更在意逻辑形态，即是否为了完成特定服务⽬标。 

1.5 主（Master）/从（Slave） 

集群中，通常有⼀个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。⽐如MySQL集群中，只有其中⼀台服务器上数据库允许进⾏数据的写⼊（增/删/改），其他数据库的数据修改全部要从这台数据库同步⽽来，则把那台数据库称为主库，其他数据库称为从库 。

1.6 中间件（Middleware） 

和业务内容无关的服务 比如：redis mysql rabbitmq .... 但共同使用可以解决更大的任务 

评价指标（Metric） 可⽤性（Availability）

系统可用的时间/整体时间 平时我们常说的4个9即系统可以提供99.99%的可⽤性，5个9是99.999%的可⽤性，以此类推。我们平时只是⽤⾼可⽤（High Availability HA）这个⾮量化⽬标简要表达我们系统的追求。 越高越好

响应时⻓（Response Time RT） 

⽤⼾完成输⼊到系统给出⽤⼾反应的时⻓。例如点外卖业务的响应时⻓=拿到外卖的时刻-完成点单的时刻。通常我们需要衡量的是最⻓响应时⻓、平均响应时⻓和中位数响应时⻓。这个指标原则 上是越⼩越好，但很多情况下由于实现的限制，需要根据实际情况具体判断 

吞吐（Throughput）vs 并发（Concurrent） 

吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同⼀时刻⽀持的请求最⾼量。例如⼀条辆⻋道⾼速公路，⼀分钟可以通过2辆⻋，则并发是2，⼀分钟的吞吐量是20。实践中，并发量往往⽆法直接获取，很多时候都是⽤极短的时间段（⽐如1秒）的吞吐量做代替。我们平时⽤⾼并发（Hight Concurrnet）这个⾮量化⽬标简要表达系统的追求。 

1.单机架构 

假设此时为一个电商平台网站 在初期访问量很少的情况下 可以选择单机架构 

例如：单机架构 只有一台服务器 这个服务器包括所有的工作（应用服务，数据库服务） 应用服务：指的是写的服务器程序 例如java的spring... 一些业务逻辑代码 数据库服务：指的是mysql... 存储数据的地方 

随着后期网站访问量增长 一台主机硬件资源（CPU,内存，硬盘，网络）有限的情况下

可以选择俩种方式 1.开源  简单粗暴 增加更多的硬件资源（CPU 硬盘 ） 但主机扩容能力也是有限的 一旦引入多台主机，就是“分布式系统” 2.节流 进行软件上的优化 节省开销提供效率 

一旦数据量过于庞大 只能选择引入多台主机

2.应⽤数据分离架构

前言：

当单机系统不能承受过大的访问量时候 我们可以选择将应用服务和数据库服务进行分离配置多台主机 

应用服务器吃CPU和内存多点 数据库服务器吃硬件   所有可以搭配更适合它们的主机 更具有性价比 优点：提高了系统的稳定性 防止系统崩溃 并且访问速度变快 缺点：成本上去了  包括人力 资金 时间

  3.引入负载均衡

前言：

为了解决用户流量向哪台应⽤服务器分发的问题，需要⼀个专⻔的系统组件做流量分发，此时负载均衡就是做这个“领导”，向每台应用服务器分配均衡任务，防止某台服务器压力过大 导致崩溃

同时流量调度算法也有很多种，这⾥简单介绍⼏种较为常⻅的： • Round-Robin 轮询算法。即⾮常公平地将请求依次分给不同的应⽤服务器。 • Weight-Round-Robin 轮询算法。为不同的服务器（⽐如性能不同）赋予不同的权重（weight）， 能者多劳。 • ⼀致哈希散列算法。通过计算⽤⼾的特征值（⽐如 IP 地址）得到哈希值，根据哈希结果做分发，优 点是确保来⾃相同⽤⼾的请求总是被分给指定的服务器。也就是我们平时遇到的专项客⼾经理服 务

4.读写分离+主从分离架构

前言：

增加应用服务器，确实能处理好过大的访问量，可随着而来的是，数据库要承担的数据量也变增大，这时候我们可以继续将数据库中的读/写的数据进行分离 要知道 读的数据往往要比写的数据多的多 随之可以将写这个服务器设置成主服务器（写） 并且设置多个从服务器(读） 并且一旦新增数据 读写服务器要保持一致

一主多从服务器 

5. 引⼊缓存 ⸺ 冷热分离架构

 前言：

数据库最大的问题就是响应速度太慢 这时候可以引入我们的主角缓存-Redis 将热点数据放进缓存中 缓存的访问速度比数据库快很多倍

缓存是比较小的 所有只能放入“热点”数据 热点数据指的就是经常访问的数据 

6.分库分表

 前言：

随着业务的数据量增⼤，⼤量的数据存储在同⼀个库或表中已经显得有些⼒不从⼼了，所以可以按照业务，将数据分别存储。

7.业务拆分 ⸺ 微服务

前言：

随之业务越来越大 ，应用服务器里做了很多功能 导致代码的变得越来越复杂，这时候可以对每个功能进行拆分 分成多个模块  微服务：可以对一个大应用 分解成多个小应用 功能单一 

所谓的分布式 就是引入更多的硬件设备