初始Redis

Mysql最大的问题在于,访问速度比较慢

而Redis是内存中存储数据的中间件,可以作为数据库使用,比较快,和Mysql相比,存储空间有限

Redis是在分布式系统中,才能发挥威力的,在单机程序,直接通过变量存储数据的方式,是比使用redis更优的选择

那么要求更大更快,就可以把redis和mysql结合起来,采取二八原则,20%的热点数据,满足80%的访问需求

分布式系统(引入多个主机/服务器)

单机架构

单机程序中,能不能把数据库服务器也去掉,只剩一个应用服务器既负责业务,又负责数据存储?

可以的,但是很麻烦

如果业务进一步增长,用户量和数据量都很大,一台主机难以应付时,就需要引入更多的主机,引入更多的硬件资源

引入分布式,这是万不得已的,系统的复杂度会大大提高,出现bug的概率也更高

应用服务和数据库服务分离;

应用服务器,里面可能会包含很多的业务逻辑,会吃cpu和内存

数据库服务,需要更大的硬盘空间,更快的数据访问速度

引入负载均衡,更多的应用服务器节点

用户的请求,先到达负载均衡器

假设又1w的用户请求,2个应用服务器,此时按照负载均衡的方式,就可以让每个应用服务器承担5k的访问量

负载均衡器,看起来承担了所有的请求,可以顶住嘛?

负载均衡器对于请求量的承担能力,远超过应用服务器

• 负载均衡器:领导,分配工作
• 应用服务器:组员,执行工作

那么是否会出现,请求量大到负载均衡器也扛不住?

有可能!引入更多的负载均衡器

如上面所述,增加应用服务器,的确能够处理更高的请求量,但是随之存储服务器,要承担的请求量也更多了

读写分离,数据库主从结构

当然,数据库响应速度比较慢

把数据区分"冷热"

热点数据放到缓存中,访问的速度快很多

引入缓存,冷热数据分离

缓存服务器,只是放一小部分热点数据

是否会出现,一台服务器已经存不下数据,当然会

此时需要多台主机存储,拓展存储空间

分库分表

针对数据库进行进一步的划分,分库分表

本来一个数据库服务器,有多个数据库,现在就可以引入多个数据库服务器,每个存储一部分数据库

如果这个表特别大,一台主机存不下,也可以针对表拆分

微服务架构

从业务上进一步拆分应用服务器

之前应用服务器,一个服务器程序里面做了很多的业务,这就可能导致这一个服务器的代码变得越来越复杂

为了方便代码的维护,就可以把这样一个复杂的服务器,拆分成更多的,功能更单一,但是更小的服务器,服务器的种类和数量就增加了

注意:微服务本质上是在解决人的问题

应用服务器复杂了,就需要更多的人维护,人多,就需要配套的管理,划分组织结构,分工

按照功能,拆分成多组微服务,就有利于人员的组织结构分配

引入微服务,解决了人的问题,付出的代价?

1.系统的性能下降

拆出来更多的服务,多个功能之间要更依赖网络通信,通络通信的速度可能比硬盘还慢

2.系统复杂程度提高,可用性受到影响

服务器更多了,出现问题的概率就更大,这就需要一系列手段,来保证系统的可用性

微服务优势:

1.解决了人的问题

2.使用微服务,更方便功能的复用

3.可以给不同的服务提供不同的部署

Redis特性(官方文档)

in-memory data structures

在内存中存储数据

redis主要通过键值对的方式存储组织数据

key都是string,value可以是多种数据结构

Programmability

针对redis的操作,可以直接通过简单的交互式命令进行操作

也可以通过一些脚本的方式,批量执行一些操作 

Extensibility

可以在redis原有的功能基础上再进行拓展

redis提供了一组API 

Persistence

持久化

redis内存为主,硬盘为辅 

Clustering

redis作为一个分布式系统中的中间件,能够支持集群是很关键的

这个水平拓展,类似于分库分表 

High avaliability

高可用=>冗余/备份

redis自身也是支持主从结构的

为啥redis快?

1.redis数据在内存中,比访问硬盘快

2.redis核心功能都是比较简单的逻辑,操作内存的数据结构

3.从网络角度上,redis使用了IO多路复用的方式(epoll)

4.redis使用的是单线程模型,减少了不必要的线程之间的竞争开销