【Redis前奏曲】初识分布式

一. 简单认识Redis

在Redis官网中,是这样介绍Redis的:
The open source, in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker.
翻译为:
被数百万开发人员用作数据库、缓存、流媒体引擎和消息代理的开源内存数据存储

in-memory data:Redis是在内存中存储数据.
database:Redis可以作为数据库. 我们之前学过MySQL数据库,MySQL最大的问题在于它是在硬盘中存储数据,所以它比较慢.在很多网络产品中对于性能的要求是很高的.而Redis就可以作为数据库使用.由于Redis是在内存中存储数据的,所以它很快.但是与My
SQL相比,Redis的存储空间是有限的.如果我们的业务需要又大的存储空间有需要又快的访问速度,我们可以将MySQL和Redis结合使用.
cache:Redis用来做缓存.
streaming engine:Redis的初心,是用来做一个"消息中间件"的(消息队列).分布式系统下的生产者消费者模型.

Redis是在分布式系统中,发挥着很大的作用.如果只是单机程序,直接通过变量存储的方式,是比使用Redis更优的选择.

由于进程的隔离性.所以进程之间通信要用到网络.Redis就是基于网络,把自己内存中的变量共享给别的进程,甚至别的主机的进程进行使用.

二. 分布式系统

1. 单机架构

单机架构,也就是只有一台服务器,这个服务器负责所有的工作.

现在计算机硬件,发展速度非常之快.即使只有一台主机,这一台主机的性能也是很高的.可以支持非常高的并发和非常大的数据存储.
但是如果业务进一步增长,用户量和数据量都水涨船高,一台主机难以应付的时候,就需要引入更多的主机,引入更多的硬件资源.

一台主机的硬件资源是有上限的,比如: CPU,内存,硬盘,网络等…
服务器每次收到一个请求,都是需要消耗上述的一些资源.如果同一时刻,处理的请求多了,此时就可能会导致某个硬件资源,不够用了.
无论是哪个方面不够用了，都可能会导致服务器处理请求的时间变长,甚至于处理出错.

如果我们遇到了服务器不够用的场景,那我们应该怎么做呢?

1. 开源.也就是添加更多的硬件资源
2. 节流.在软件上优化.比如更改数据结构类型等.对程序员的要求比较高.

我们主要来说一下开源,虽然在一个主机上可以增加硬件资源,但是能够增加的硬件资源是有限的.这取决于主板的扩展能力.如果一台主机扩展到极致了,但是还不够,此时就只能引入多台主机了.同时也需要在软件商做对应的调整和适配. 一旦引入了多台主机,我们的系统就可以称之为"分布式系统"了.

2. 应用服务和数据库服务分离

上述应用服务器中,可能会包含很多的业务逻辑,可能会吃CPU和内存.
在**存储服务器(数据库服务器)**中,由于需要存储数据,则需要更大的硬盘空间以及更快的数据访问速度.我们可以配置更大硬盘的服务器,或者使用SSD硬盘.(固态硬盘)
调整上述以达到更高的性价比.

3. 引入更多的应用服务器节点

我们上述说到,应用服务器比较吃CPU和内存.如果把CPU或者内存吃没了,应用服务器就承受不住了.此时我们可以引入更多的应用服务器,来解决上述问题.

由于引入了更多的应用服务器节点,我们就需要一个负载均衡器来给应用服务器分配任务.所以用户的请求,先到达负载均衡器/网关服务器(单独的服务器),由负载均衡器分配任务给应用服务器让应用服务器去执行.

负载均衡器是有很多具体算法的,假设有1w个用户请求,有2个应用服务器.,此时按照负载均衡的方式,就可以让每个应用服务器承担5k的访问量.

有小伙伴会问:用户的所有请求都需要负载均衡器来分配任务,那不是它承担了所有的请求?它能承担的住吗?
负载均衡器,对于请求量的承担能力,是要远超过应用服务器的.(相当于负载均衡器是一个领导,负责分配任务,而应用服务器是组员,要去完成任务的.)但是也有可能请求量大到负载均衡器也承担不住了,此时我们就可以引入多个负载均衡器.(引入多个机房)

经过上述讨论,增加应用服务器,确实能够处理更高的请求量,但是随之存储服务器,要承担的请求量也就更多了.此时,我们可以:

1. 开源(引入更多机器)
2. 节流(门槛高,更复杂)

4. 数据库读写分离

在实际的应用场景中,读的频率是比写的频率高的.

主服务器一般是一个,从服务器可以有多个.(一主多从) 同时从数据库通过负载均衡的方式,让服务器进行访问.

数据库有一个天然的问题,响应速度慢.于是我们可以把数据区分"冷热",热点数据放到缓存中,缓存的访问速度比数据库要快很多.
计算机的二八原则中:20%的数据能够支持80%的访问量,所以我们可以将20%的数据放在缓存中以提高查询的效率.

5. 多主机存储

引入分布式系统,不光能够去应对更高的请求量(并发量),同时也要能应对更大的数据量.
有可能会出现,一台服务器已经存储不下数据了,此时就需要多台主机来存储.

针对数据库进行进一步的拆分,分库分表.
本来一个数据库服务器,这个数据库服务器上有多个数据库,现在就可以引入多个数据库服务器,每个数据库服务器存储一个或者一部分数据库.(分库)
如果一个表特别大,大到一台主机也存不下,就可以针对表进行拆分(分表)

6. 微服务架构

之前应用服务器,一个服务器中做了很多的业务,这就可能导致一个服务器的代码变得越来越复杂.为了方便于代码的维护,就可以将这样一个复杂的服务器,拆分成更多的,功能更单一,更小的服务器.(微服务)

由于引入了更多的服务器,导致服务器的种类和数量就增加了,那么应用服务器就复杂了,就需要更多的人去维护了.

总的来说,微服务的优缺点如下:

优点：

1. 高度可扩展性：微服务架构将应用程序拆分成多个小型服务，每个服务都可以独立部署和扩展，从而提高了整体系统的可扩展性。
2. 独立性：每个微服务都是独立的部分，由团队负责开发、测试和部署，这种独立性可以提高团队的效率和生产力。
3. 灵活性：由于微服务之间是松耦合的，可以更容易地添加或删除服务，从而实现更快速的迭代和创新。
4. 技术异构性：微服务架构允许使用不同的编程语言和技术来构建不同的服务，从而提高了灵活性和适应性。
5. 可维护性：由于每个微服务都是独立的，可以更轻松地进行维护和升级，而不会影响整个系统。

缺点:

1. 复杂性：微服务架构需要管理多个服务之间的通信和数据传输，这样就增加了系统的复杂性和技术难度。
2. 分布式系统的挑战：微服务架构需要处理分布式系统的挑战，如服务发现、负载均衡、故障恢复等，这需要额外的开发和管理工作。
3. 测试的挑战：由于每个微服务都是独立的，测试也需要进行单独的测试，增加了测试的复杂性和成本。
4. 部署的挑战：微服务架构需要管理多个服务的部署和版本控制，这需要额外的管理和自动化工作。
5. 性能问题：由于微服务之间需要通过网络进行通信和数据传输，可能会出现性能问题，需要进行优化和调整。

三.常见名词解释

应用(Application)/系统(System)

一个应用,就是一个/组服务器程序

模块(Module)/组件(Component)

一个应用,里面有很多个功能.每个独立的功能,就可以称为是一个模块/组件

分布式(Distributed)

引入多个主机/服务器,协同配合完成一系列的工作.
物理上的多个主机

集群(Cluster)

引入多个主机/服务器,协同配合完成一系列的工作.
逻辑上的多个主机

主(Master)/从(Slave)

分布式系统中一种比较典型的结构
多个服务器节点,其中一个是主，另外的是从.从节点的数据要从主节点这里同步过来

中间件(Middleware)

和业务无关的服务(功能更通用的服务)
比如:数据库,缓存,消息队列…

可用性(Availability)

系统整体可用的时间/总的时间
比如一年中有360天服务器可以正常工作.则360 / 365 =>可用性

响应时长(Response Time RT)

衡量服务器的性能
和具体服务器要做的业务密切相关
越小越好

吞吐(Throughput) vs并发(Concurrent)

衡量系统的处理请求的能力.衡量性能的一种方式