【Redis】高并发分布式结构服务器
文章目录
服务端高并发分布式结构
名词基本概念
- 应⽤（Application）/系统（System）
为了完成一整套服务的一个程序或相互配合的程序群。例子：为了完成⼀项任务，⽽搭建的由⼀个⼈或者⼀群相互配的⼈组成的团队
- 模块（Module）/组件（Component）
当应⽤较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。例子：军队中为了进⾏某据点的攻克，将⼈员分为突击⼩组、爆破⼩组、掩护⼩组、通信⼩组等
- 分布式（Distributed）
分布式（Distributed）是指将计算、任务或数据分散到多个独立的计算机或节点上进行处理的方式。（即：将系统中的多个模块被部署于不同服务器之上）与传统的集中式系统相比，分布式系统具有更高的灵活性、可扩展性和冗余性。
在分布式系统中，各个节点(模块)可以通过网络进行通信和协作，共同完成任务。每个节点独立地执行一部分工作，并根据需要与其他节点进行交互。节点之间可以相互传递消息、共享资源和数据，以实现更加复杂和大规模的计算和服务。（跨主机之间的模块之间的通信基本要借助⽹络⽀撑完成）
例子1：Web服务器与数据库分别⼯作在不同的服务器上，或者多台Web服务器被分别部署在不同服务器上
例子2：为了更好的满⾜现实需要，⼀个在同⼀个办公场地的⼯作⼩组被分散到多个城市的不同⼯作场地中进⾏远程配合⼯作完成⽬标。
- 集群（Cluster）
被部署于多台服务器上的、为了实现特定⽬标的⼀个/组特定的组件，整个整体被称为集群。比如，多个MySQL⼯作在不同服务器上，共同提供数据库服务⽬标，可以被称为⼀组数据库集群
分布式和集群的区别
分布式强调的是物理形态，即⼯作在不同服务器上并且通过⽹络通信配合完成任务。 =>物理上的多台主机
集群更在意逻辑形态，即是否为了完成特定服务⽬标 =>逻辑上的多台主机，比如：一台主机上部署多个服务器程序
- 主（Master）/从（Slave）
集群中，通常有⼀个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。
⽐如MySQL集群中，只有其中⼀台服务器上数据库允许进⾏数据的写⼊（增/删/改），其他数据库的数据修改全部要从这台数据库同步⽽来，则把那台数据库称为主库，其他数据库称为从库。主库：可以读和写入 从库：只可以进行读取
- 中间件（Middleware）
⼀类提供不同应⽤程序⽤于相互通信的软件，即处于不同技术、⼯具和数据库之间的桥梁
例子：⼀家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变⼤，成⽴⼀个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁
评价指标
- 可⽤性（Availability）
考察单位时间段内，系统可以正常提供服务的概率/期望。例如：年化系统可⽤性=系统正常提供服务时⻓/⼀年总时⻓。平常说的4个9即系统可以提供99.99%的可⽤性，5个9是99.999%的可⽤性
- 响应时⻓（ResponseTimeRT）
指⽤⼾完成输⼊到系统给出⽤⼾反应的时⻓，例如：点外卖业务的响应时⻓=拿到外卖的时刻-完成点单的时刻
需要衡量的是最⻓响应时⻓、平均响应时⻓和中位数响应时⻓。这个指标原则上是越⼩越好，但很多情况下由于实现的限制，需要根据实际情况具体判断
- 吞吐（Throughput）vs并发（Concurrent）
吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同⼀时刻⽀持的请求最⾼量。实践中，并发量往往⽆法直接获取，很多时候都是⽤极短的时间段（⽐如1秒）的吞吐量做代替
例如⼀条辆⻋道⾼速公路，只有两条通道，但是⼀分钟可以通过20辆⻋，则并发是2，⼀分钟的吞吐量是20
1.单机架构
单机架构：只有一台服务器，这台服务器用来负责所有的工作。整个系统在物理上只由一个节点组成，所有的计算和存储都发生在这个节点上，比如一个电商网站：
- Web服务器软件：Tomcat、Netty、Nginx、Apache
- 数据库软件：MySQL、Oracle、PostgreSQL、SQL Server
注意：在单机程序当中，本质上可以把数据库服务器也去掉，用一个应用服务器即负责业务，又负责数据存储
大部分的中小公司的产品，都是这种单机架构，整个系统只有一个单机服务器。由于计算机硬件发展速度非常之快，主机的性能都很高，能支持非常高的并发和非常大的数据存储，已经能满足大部分中小公司的需求。
单机架构相对于分布式架构来说，系统比较容易进行管理和维护，数据传输和处理的延迟较低，易于部署
当业务需求进一步增长时，用户量和数据量等都会增加，一台服务器难以应对时，就需要引入更多的主机和其他硬件资源
缺点
- **有限的性能和扩展性：**由于计算和存储资源都集中在一个节点上，无法有效地利用分布式环境下多个节点的计算和存储能力。当系统的工作负载和数据量增加时，单机架构可能无法满足性能和扩展性（比如主机上能够增加的硬件资源等，都是有限的）的要求。
- 单点故障：由于只有一个节点，如果这个节点出现故障或停机，整个系统将无法正常运行。
- 硬件资源限制：单个节点的硬件资源（CPU、内存、磁盘，网络等）是有限的，无法满足大规模数据处理和存储的需求。
- 服务器每次收到一个请求，都是需要消耗上述的硬件资源去处理请求，如果同一时刻处理的请求太多，就可能导致某个硬件资源不够用，就会导致服务器处理请求的时间变长/处理出错
如果真的遇到了上述的场景，如何处理
1.开源 => 增加更多的硬件资源，但是一台主机上可以增加的硬件资源也是有限的，取决于主板的拓展能力，如果一台主机拓展到极限了还是不够，那么就只能引入多台主机了，引入多台主机后需要在软件上做出对应的调整和适配。此时系统就可以称为是分布式系统，系统复杂性大大提高，出现bug概率提高
2.节流 =>在软件上做优化，通过性能测试，找到是哪个环节出现的瓶颈
2.应用数据分离架构
系统的访问量逐步上升，逐渐逼近了硬件资源的极限，⾯对当前的性能压⼒，我们需要未⾬绸缪去进⾏系统重构、架构挑战，以提升系统的承载能⼒，可以选择将应⽤和数据分离的做法，可以最⼩代价的提升系统的承载能⼒
引入多台主机后，就不是单机架构了，系统就可称为“分布式系统”
应用服务器和数据库服务器就是不同的服务器。应⽤服务通过⽹络访问数据库服务当中的数据，并且可以根据不同服务的特点配置不同的服务器，从而达到更高的性价比
- 应用服务器会包含更多的业务逻辑，需要大量的计算分析，对cpu，内存性能要求高。所以可以配置CPU比较好的主机
- 数据库服务器需要更大的硬盘空间，更快的数据访问速度，对空间要求高。可以配置更大硬盘的服务器，甚至可以上固态硬盘(SSD)
硬盘分类：
- 机械硬盘：便宜，访问速度慢
- 固态硬盘：贵，访问速度快
应用服务集群架构
随着数据量进一步增加，单台应⽤服务器已经⽆法满⾜需求了。单机应⽤服务器⾸先遇到了瓶颈，此时可以有两种解决方法：
- 垂直扩展/纵向扩展：通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量。这种⽅案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增⻓关系是⾮线性的，意味着选择性能2倍的硬件可能需要花费超过4倍的价格，其次硬件性能提升是有明显上限的
- ⽔平扩展/横向扩展：通过调整软件架构，增加应⽤层硬件，将用户流量分担到不同的应⽤层服务器上，来提升系统的承载能⼒
优势在于成本相对较低，并且提升的上限空间也很⼤。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验，并且为了解决⽤⼾流量向哪台应⽤服务器分发的问题，需要⼀个专⻔的系统组件（负载均衡器）做流量分发
- 用户的请求先到达负载均衡器/网关服务器，
负载均衡器（Load Balancer）：也是一个单独的服务器，或者称为网关。是一种用于分发网络流量的设备或软件。它位于应用程序和网络基础设施之间，将传入的流量（请求）分配到多个服务器或计算资源上，以实现负载的均衡和性能的优化。（和之前学习的多线程思想相似，都是通过流量分发到多处进行处理，以提高效率）
负载均衡器的主要功能包括：
- 流量分发：接收传入的请求流量，将其分发到后端的多个服务器或计算资源上，以确保每个服务器都能得到相对均等的工作负载。
-
负载调度：采用不同的调度算法，如轮询、权重、最少连接等，来决定请求应该被分发到哪个后端服务器上。根据服务器的性能和负载情况，动态地调整流量分发策略。
- 策略1：轮询算法—将请求依次分给不同的应⽤服务器
- 策略2：随机选择算法—每次随机将请求分发给一台应用服务器
- 策略3：基于权重的轮询算法—为不同的服务器（⽐如性能不同）赋予不同的权重，能者多劳
- 策略4：⼀致哈希散列算法—通过计算⽤⼾的特征值（⽐如?IP?地址）得到哈希值，根据哈希结果做分发，优点是确保来⾃相同⽤⼾的请求总是被分给指定的服务器
- 高可用性：可以监控后端服务器的可用性，并在某个服务器发生故障或不可用时，自动将流量转移到其他正常工作的服务器上，确保服务的连续性和高可用性。
- 健康检查：可以定期检查后端服务器的健康状态，如响应时间、负载情况等，并根据检查结果来决定是否将流量分发给该服务器。
- 扩展性：通过添加更多的后端服务器，可以实现系统的水平扩展，以满足不断增长的流量需求。
负载均衡器的流量承担能力是远远超过应用服务器的，因为它只用单纯的分配任务，服务器是需要进行执行任务的，所花时间是更长的。如果超过负载均衡器的承受能力，就引入更多的负载均衡器，也就是多个机房，用来分担流量
- 负载均衡软件：Nginx、HAProxy、LVS、F5等
读写分离/主从分离架构
通过负载均衡解决了请求量过大的问题，大量请求可以得到并行处理了，⽆论扩展多少台服务器，这些请求最终都会从数据库读写数据，那么到一定程度上，就会到达瓶颈点。并且不能将数据库服务器和应用服务器一样进行扩展，因为将数据分散到不同的数据库后，会破坏数据的一致性，例如转账，如果一个数据库的数据修改了，另一个数据库没修改，就造成数据不一致
解决办法：保留⼀个主要的数据库作为写⼊数据库，其他的数据库作为从属数据库。
- 从库的所有数据全部来⾃主库的数据，经过同步后，从库可以维护着与主库⼀致的数据
- 为了分担数据库的压⼒，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中
应⽤中需要对读写请求做分离处理，所以可以利⽤⼀些数据库中间件，将请求分离的职责托管出去。例如：MyCat、TDDL、Amoeba、Cobar等类似数据库中间件
引入缓存-冷热分离架构
实际上读的频率是远高于写的频率，因此主数据库服务器一般是一个，从数据库服务器有多个（一主多从），同时从数据库通过负载均衡的方式，让应用服务器进行访问。针对数据库响应速度比较慢的问题，将数据进行“冷热”划分，将热点数据放到缓存中，冷的数据放到硬盘。
- 热点数据：⼀些数据的读取频率远⼤于其他数据的读取频率
针对热数据，为了提升其读取的响应时间，可以增加本地缓存，并在外部增加分布式缓存。缓存热⻔商品信息或热⻔商品的html⻚⾯等。通过缓存能把绝⼤多数请求在读写数据库前拦截掉，⼤⼤降低数据库压⼒
注意：缓存服务器中存放一小部分热点数据，根据二八原则:20%的数据，能够支持80%的访问量。数据库中存储的还是完整的数据，只是将热点数据放到缓存中了，缓存的速度非常快，但是容量小，成本高，也是Redis出现的位置。Redis的核心功能就是作为缓存服务器
代价：数据的一致性问题，如果存储服务器的数据被修改，访问时使用的是缓存的数据，那就出现错误了
分库分表（垂直分库）
引入分布式系统不光要去应对高的请求量，也需要应对更大的数据量。虽然一个服务器存储的数据量可以达到几十个TB，即使如此面对不同的应用场景，也会存不下。需要使用多台主机存储数据，所以可以针对数据库进行分库分表
原本是一个数据库服务器，这个服务器上存储了多个数据库，现在由于数据量太大，一个数据库服务器存不下那么多数据，就引入多个数据库服务器，每个服务器上存储一个或一部分数据库
如果某个表特别大，一台服务器存不下，也可以针对表进行拆分，使用多个存储服务器进行存储
业务拆分⸺微服务
之前的应用服务器，一个服务器中要实现所有的业务，会导致这一个服务器的代码越来越复杂。按照功能拆成多组微服务，就可以便于代码的维护，互相之间对数据的直接访问进⾏隔离，可以利⽤Gateway、消息总线等技术，实现相互之间的调⽤关联。甚⾄可以把⼀些类似⽤⼾管理、安全管理、数据采集等业务提成公共服务
应用服务器复杂了之后，就需要更多的人力资源进行维护，增加了管理成本。为了减少管理成本，就可以把一个复杂的服务器，拆分成更多的，功能单一的，更小的服务器（微服务），有利于划分组织结构，分多组进行管理
引入微服务主要是为了解决人的管理问题，付出的代价有：
1.系统性能下降，多个被拆出来的服务，功能之间需要更依赖网络通信。解决办法：引入更多的机器提升性能，万兆网卡等等配套设施
2.系统复杂程度提高，可用性降低，出现问题的概率增加。 解决办法：引入更丰富的报警机制，监控系统，以及运维人员
总结
1.单机架构（应用程序+数据库服务器）
2.数据库和应用程序分离
- 应用程序和数据库服务器分别放到不同的主机上进行部署
3.引入负载均衡，将应用服务器集群化
- 通过负载均衡器把请求比较均匀的分发给集群当中的每个应用服务器
- 好处是：当集群当中的某个主机挂了，其它的主机仍然可以承担服务，提高了整个系统的可用性
4.引入读写分离，数据库主从结构
- 一个数据库节点作为主节点， 其它N个数据库节点作为从节点，主节点负责写数据，从节点负责读数据，主节点需要把修改过的数据同步给从节点
5.引入缓存，冷热数据分离
- 进一步的提升了服务器针对请求的处理能力 【28原则】
- 引入的问题：数据库和缓存的一致性问题
6.引入分库分表，数据库能够进一步拓展存储空间
7.引入微服务，从业务上进一步拆分应用服务器
- 从业务功能的角度，把应用服务器拆分成更多的功能更单一，更简单，更小的服务器