【Redis学习】服务端高并发分布式结构演变之路
前言：
本篇开始我们正式开始redis的学习，这篇我们主要先来讲解一下学习Redis的前沿知识，本篇不涉及Redis的指令，主要是一些关键概念的理解
目录
1. 常见概念
1.1 基本概念
2.2 评价指标
2. 架构演进
2.1 单机架构
2.2 应用数据分离架构
2.3 应用服务集群架构
2.4 读写分离/主从分离架构
2.5 引入缓存——冷热分离架构
2.6 垂直分布
2.7 业务拆分——微服务
3. 总结
1. 常见概念
1.1 基本概念
应⽤（Application）/ 系统（System）
为了完成⼀整套服务的⼀个程序或者⼀组相互配合的程序群。
⽣活例⼦类⽐：为了完成⼀项任务，⽽搭建的由⼀个⼈或者⼀群相互配合的⼈组成的团队。
模块（Module）/ 组件（Component）
当应⽤较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。
⽣活例⼦类⽐：军队中为了进⾏某据点的攻克，将⼈员分为突击⼩组、爆破⼩组、掩护⼩组、通信⼩组等。
分布式（Distributed）
系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与数据库分别⼯作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。
⽣活例⼦类⽐：为了更好的满⾜现实需要，⼀个在同⼀个办公场地的⼯作⼩组被分散到多个城市的不同⼯作场地中进⾏远程配合⼯作完成⽬标。跨主机之间的模块之间的通信基本要借助⽹络⽀撑完成。
集群（Cluster）
被部署于多台服务器上的、为了实现特定⽬标的⼀个/组特定的组件，整个整体被称为集群。⽐如多个 MySQL ⼯作在不同服务器上，共同提供数据库服务⽬标，可以被称为⼀组数据库集群。
⽣活例⼦类⽐：为了解决军队攻克防守坚固的⼤城市的作战⽬标，指挥部将⼤批炮兵部队集中起来形成⼀个炮兵打击集群。
分布式 vs 集群：通常不⽤太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即⼯作在不同服务器上并且通过⽹络通信配合完成任务；⽽集群更在意逻辑形态，即是否为了完成特定服务⽬标。
主（Master）/ 从（Slave）
集群中，通常有⼀个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。⽐如 MySQL 集群中，只有其中⼀台服务器上数据库允许进⾏数据的写⼊（增/删/改），其他数据库的数据修改全部要从这台数据库同步⽽来，则把那台数据库称为主库，其他数据库称为从库。
中间件（Middleware）
⼀类提供不同应⽤程序⽤于相互通信的软件，即处于不同技术、⼯具和数据库之间的桥梁。
⽣活例⼦类⽐：⼀家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变⼤，成⽴⼀个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。
2.2 评价指标
可⽤性（Availability）
考察单位时间段内，系统可以正常提供服务的概率/期望。
例如：年化系统可⽤性 = 系统正常提供服务时⻓ / ⼀年总时⻓。
这⾥暗含着⼀个指标，即如何评价系统提供服务是否正常，我们就不深⼊了。
平时我们常说的：
- 4个9：99.99% 的可⽤性
- 5个9：99.999% 的可⽤性
- 以此类推
我们平时只是⽤**⾼可⽤（High Availability，HA）**这个⾮量化⽬标简要表达我们系统的追求。
响应时⻓（Response Time，RT）
指⽤⼾完成输⼊到系统给出⽤⼾反应的时⻓。
例如：点外卖业务的响应时⻓ = 拿到外卖的时刻 - 完成点单的时刻。
通常我们需要衡量的是：
- 最⻓响应时⻓
- 平均响应时⻓
- 中位数响应时⻓
这个指标原则上是越⼩越好，但很多情况下由于实现的限制，需要根据实际情况具体判断。
吞吐（Throughput）vs 并发（Concurrent）
吞吐：考察单位时间段内，系统可以成功处理的请求的数量。
并发：指系统同⼀时刻⽀持的请求最⾼量。
例如：⼀条车道⾼速公路，⼀分钟可以通过20辆车，则并发是1（单车道），⼀分钟的吞吐量是20。
实践中，并发量往往⽆法直接获取，很多时候都是⽤极短的时间段（⽐如1秒）的吞吐量做代替。
我们平时⽤**⾼并发（High Concurrency）**这个⾮量化⽬标简要表达系统的追求。
2. 架构演进
2.1 单机架构
在早期的时候，因为市场需求简单且用户量小，没有对我们的性能、安全等提出更高的要求，我们为了更快的将业务系统提供到市场接收检验，所以会采用上面的单机架构来提供服务，但是当我们的用户量足够大时，单个主机的资源有限，就很难通过这样单机服务器来很好的满足所有用户的需求，所以我们就需要尝试其它架构
2.2 应用数据分离架构
随着用户量的增加，单机服务器的架构很快就会达到硬件资源的上线，面对激增的性能压力，我们采用如图将应用服务与数据分离的做法，可以最小代价的提升系统的承载能力
和单机架构的主要区别在于将数据库服务独立部署在同一个数据中心的其它服务器上，应用服务通过网络去访问数据
2.3 应用服务集群架构
上面应用数据分离架构虽然能帮助我们处理一些流量过大的问题，但是当流量过于庞大的时候，单靠一个应用服务器是不够的，为了解决这个问题，我们可以采取两种方案：
- 垂直拓展/纵向扩展（Scale up）：通过购买性能更优，价格更贵的应用服务器来解决这个问题。这种方式的优点是不需要对软件系统做出任何更改，操作尤为简单；但是缺点也很明显的，硬件性能和价格的增长不是线性的，意味着硬件性能提升2倍所花的钱可能是更多
- 水平扩展/横向扩展（Scale out）：通过调整软件架构，增加应用层硬件，将用户流量分流到不同的应用层服务器上，来提高系统的承担能力。这种方法的优点是成本较低，且上限高，但劣势是会给系统带来更大的复杂性，需要专业的团队来完成这个工作
我们上面那张图就是基于水平拓展的描述图，我们可以发现这与我们之前的架构有两大不同，一是我们可以有多个应用服务器，它们用来分流客户流量，为了调配个应用服务器工作，我们还需要一个专门的负载均衡组件，通过这个组件就可以帮助我们管理用户流量，按照一定的规则分流到不同的应用服务器，负载均衡不止可以工作在应用层，也可以工作在网络层。
同时负载均衡的流量调度算法也有很多种，这里我们简单介绍几种最常见的负载均衡算法：
Round-Robin 轮询算法
⾮常公平地将请求依次分给不同的应⽤服务器。
Weight-Round-Robin 加权轮询算法
为不同的服务器（⽐如性能不同）赋予不同的权重（weight），能者多劳。
⼀致哈希散列算法
通过计算⽤⼾的特征值（⽐如 IP 地址）得到哈希值，根据哈希结果做分发。
优点：确保来⾃相同⽤⼾的请求总是被分给指定的服务器（即我们平时遇到的专项客⼾经理服务）。
2.4 读写分离/主从分离架构
上面我们的几个架构都是如何从应用服务层去缓解流量过大的压力，但是我们有一个没有处理的问题是：流量过大对数据库的过量访问问题。
虽然我们上面通过添加多个应用服务器的方式来实现了对用户访问的分流，但是这些应用服务器它们最后都要从数据库中来获取数据，所以存储服务器也有过载的可能，所以我们也需要对存储服务器进行拓展。
首先我们先要知道的是这里我们的存储服务器并不能像上面的应用服务器那样进行拓展，这是由于数据库服务的特殊性，如果我们将数据分开存储在不同的服务器中，就不能保证数据的一致性
所以我们的解决方法其实是这样的：我们可以创建多个数据库，但是我们只将其中一个作为主数据库，其它数据库作为从数据库，然后我们的写请求只能由主数据库来完成，但我们的读请求则是通过从数据库来完成，这样就减轻了主数据库的负担，从而提供用户的访问体验
2.5 引入缓存——冷热分离架构
随着访问量的增加，我们会发生业务中对一些数据的读取要远远大于剩下的数据，我们把这部分数据称为“热数据”，我们知道数据库中的数据一般是存在在硬盘中的，从硬盘中读取数据的速率是比较慢的，我们就可以设法把这些热数据提取到内存（缓存）中，这样在下次使用时直接从缓存中读取即可，就能提高读取速率，Redis的一个很重要的功能就是作为缓存来使用
2.6 垂直分布
随着业务的数据量增大，大量的数据存储在一个库中已经显得力不从心了，所以可以按照业务将数据进行存储
2.7 业务拆分——微服务
随着人员增加，业务发展，我们将业务分发给不同的团队去处理，每个团队分别实现自己的微服务，互相之间对数据的访问进行隔离，然后通过一些特定的技术进行相互调用
3. 总结
感谢各位大佬观看，创作不易，还望各位大佬点赞支持！！！