目录
简要
分布式系统
负载均衡
引入缓存
数据库分表
微服务
小结
简要
redis是存储数据在内存中, 定义变量就是在内存中, 但是redis是在分布式系统中, 才能真正发挥威力, 如果只是单机程序, 那么直接通过变量来存储数据的方式将是最优的选择.
redis是如何发挥威力的? 首先进程之间是具有隔离性的, 一个进程想要获取另外一个进程的变量, 由于隔离性是无法直接获取的, 需要进程之间的通信, 也就是通过网络的形式进行通信的, redis就是利用这一点进行了一个封装, 将内存中的变量分享给别的进程, 或者是别的主机的进程进行使用.
redis现在已经被非常多的人使用, 他通常被当做数据库, 缓存流引擎, 中间件等等.
不是有mysql吗? 为什么还需要redis? MySQL最主要的问题就是慢, 很多互联网多产品的性能要求是很高的. 如果要性能, 就需要使用除了MySQL的其他更高性能的技术, redis就是其中之一, redis是使用内存的作为数据库使用, 内存的速度是比外存的速度是快很多的.
下面是各种存储器性能对比:
Redis是很快的, 因为内存的原因, 但是正是因为如此, 他们使用的场景和条件还是有限制的.
它的劣势也很显然, 既然是内存存储的形式, 那么内存的成本肯定是被硬盘等存储的成本高的. MySQL相比来说具有更大的存储空间和更低的成本, mysql也提供了更多的增删改查的功能.
那么有没有一种又快成本又低的存储方式? 最简单的方法就是将两者结合, 典型的方案: Redis和Mysql结合, 也就是将最常用的数据存储在redis, 全部数据存储在mysql, 那么redis就相当于mysql的一个缓存,但是代价就是系统的复杂程度就大大提升了, 且如果数据发生修改, 那么就涉及到redis和mysql的数据同步问题. 这些都是我们接下来要学习的内容.
分布式系统
我们之前的学习都是基于单机架构, 所谓单机架构, 就是只有这一台服务器:
假设为一个电商网站, 其实这里的应用服务就是一个http服务器, 用户发送http请求, 然后应用服务提交请求, 提供数据库服务, 完成服务. 公司绝大部分公司的产品, 都是这种单机架构.
但是当用户量, 数据量非常大的时候, 一台主机的硬件资源(cpu,内存, 硬盘, 网络)是有限的, 一台主机不够用了, 就需要多个这样的单机架构, 引入更多的硬件资源, 构成一个分布式系统.
除了连接多台主机, 还可以在程序上进行优化, 也就是节流, 通过各种性能测试, 找出是哪个环节出现了瓶颈, 然后做出对应的优化. 但是这种方法对于程序员的水平要求较高.
更简单粗暴的方法那就是在硬件上面解决性能问题. 你可以换一个能处理更多线程的cpu, 更好的网卡, 更快的内存, 但是一个主机的极限性能仍然是存在上限的, 还不够的话那么就可以引入更多的主机.
当然不是新的机器买来就可以直接使用的, 在软件上还需要做出代码上的调整. 整体系统的复杂度就更高了, 复杂程度可能呈现一个指数级别增长, bug出现的概率可能更高. (也是属于很无奈了)
下面这个模型是应用服务和数据库服务分离:
应用服务器里面需要处理业务逻辑, 对cpu和内存有更高的要求, 存储服务器则需要更大的存储空间(硬盘空间>> 固态硬盘, 机械硬盘), 以此达到一个更高的性价比
引入更多的服务器:
应用服务器会消耗cpu, 但是如果cpu性能被消耗完了. 服务器就顶不住了, 此时引入另外一个服务器主机(也可能是多个), 就可以解决上述问题. 用户的请求先到达负载均衡器, 假设有1w个请求, 按照负载均衡的机制, 就让每个主机负责5000个请求(根据性能调节)
负载均衡器(就像一个公司领导负责员工的任务), 有很多个均衡的方法, 具体使用哪个方法, 需要根据场景来进行选择
负载均衡
负载均衡器对于请求量的承担能力, 要远超应用服务器的, 就比如我们刚才那个例子, 负载均衡负责分配工作.
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。
软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。
硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。
负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。
既然是有更多的web服务, 那么就意味着更多的web请求, 这么多的web请求, 对于存储服务器来说肯定是会带来更大的压力的. 数据库对于这个请求压力时更加敏感的.
为了解决这个问题, 使用节流的方法, 将数据库的读写进行分离:
此时的存储服务器变成量两台了, 一台是主(master)数据库, 一台从(slave)数据库. 写数据就往主数据库中写, 读取数据就从从数据库中读取, 同时我们定时的将主数据库中的数据同步到从数据库中(实际情况上, 读的操作是比写的操作多的) (因此主服务器一般是一个,从数据库可以有多个).
引入缓存
使用的存储服务器大多部分都是进行读取操作, 但是读取的内容化中又有冷热之分, 所谓冷热, 也就是经常要查的数据和不是很频繁需要读取的数据. 对于需要频繁读取的部分, 我们将其放入缓存之中, 访问的速度就会比直接从数据库中访问快多了:
这个缓存服务器(redis)只是存放少部分数据, 这个数据被称为热点数据, 他们通常会执行二八原则, 也就是20%的数据能够支持80%的访问量(缓存服务器中存储着总数据量的20%的数据, 80%的请求都是访问这个缓存服务器中的数据).
为什么不把所有的数据都放入缓存? 因为是内存中存储, 内存中存储就要考虑成本!!
此时缓存服务器就帮助数据库服务器负重前行!!
数据库分表
引入分布式系统，不光要能够去应对更高的请求量，同时也要能应对更大的数据量。是否可能会出现一台服务器已经存不下数据了呢？就需要多台主机来存储。
上面这张图就是讲的对数据库进行分库分表。首先对数据库进行分库，讲一个数据库分为多个数据库， 可以讲引入多个数据库服务，每个数据库服务器存储一个或者一部分。比如现在要访问用户表， 那么就到对应的存储用户信息的存储集群中去请求， 如果是写，就使用主数据库，如果是读取就是用从数据库。
当然如果某个表特别大， 大到一个主机存不下，那么也可以针对表进行拆分。
微服务
之前的应用服务器， 一个服务器程序里面做了很多个业务，这可能会导致一个服务器的代码会越来越复杂， 为了方便代码的维护，可以将服务器拆分为更多的更小的，功能更加单一的小服务器。与此同时，服务器的种类和数量增加了。
他们各自有各自的应用服务器，缓存和存储集群。微服务本质上是在解决人的问题，当服务器变得复杂，就需要更多的人来维护，但是人也是需要成本和管理的。将这些人进行分组来管理每一个子系统，将更加方便管理代码。
啥时候涉及到人的问题？当然是大公司，拥有一定开发者基数的公司一般会有微服务的项目。
解决问题的技术肯定是有代价的。那代价是什么？
- 系统性能下降 -- 拆分出来的更多的服务，多个功能之间要依赖网络通信，网络通信的速度是非常慢的，是比硬盘还要慢的。想要保证性能，就得引入更多的硬件资源。（幸运的是现在的硬件是非常先进的）
- 系统的复杂程度提高了不少，可用性降低，出现问题的概率也会变大。这需要更加完善的监控系统和运维人员
微服务有哪些优势？
- 解决了人的问题
- 方便功能的服用
- 可以给不同的服务进行不同的部署
小结
- 单机架构： 应用程序 +数据库服务器
- 数据库和应用分离（应用和数据库部署在不同主机）
- 负载均衡器：将请求均匀的，合理的分发给集群中的应用服务器，提高服务器的可用性
- 读写分离，主从式数据库：一个数据库作为主节点，n个数据库作为从节点，主负责写，从负责读（主数据库需要给从服务器进行同步操作）
- 缓存，冷热数据分离：进一步提高服务器请求的处理能力（引入的问题：缓存同步问题）
- 分库分表：进一步扩展存储空间
- 引入微服务：从业务上拆分应用服务器
