1.认识redis
Redis是在分布式系统中在内存中存储数据的一个组件，如果只是单机程序，直接通过变量来存储数据是更优的选择。
进程具有隔离性 （也就是进程A内存里的数据无法被进程B访问），如果是分布式系统，必然会涉及到多个进程，甚至说这多个进程会在不同的主机上，此时如果想要访问不同进程上的变量，就会出现与进程的隔离性进行冲突的场景，为了解决这个进程间通信的问题，最主流方案是网络（既可以在同一主机上跨进程通信，又能跨主机不同进程间进行通信）---->因此，Redis就是基于网络，可以把自己内存中的变量给别的进程，甚至别的主机的进程进行使用。
MySQL（数据在硬盘上存储）最大的问题在于访问速度比较慢，但是很多互联网产品对于性能的要求会比较高。
Redis（数据在内存上存储）也可以作为数据库来使用，速度比MySQL快很多。（因为访问硬盘比访问内存要花更久的时间，大概快十万倍，但是实际使用过程中很难定量衡量两者相比快多少）
但是与MySQL相比，Redis最大的劣势是存储空间是有限的，因此对于性能要求不是很高的互联网产品，还是使用MySQL更多一点，因为MySQL提供了更多的增删改查能力。
"二八原则" ：20%的热点数据，能够满足80%的访问需求。（因此我们可以把MySQL和Redis结合起来使用，把热点数据放到Redis中供快速使用，把全量数据放在MySQL里提供更加丰富的增删改查服务）---->代价就是1.系统的复杂程度 大大提升了；2.如果想要删改数据，就要考虑Redis和MySQL之间的数据同步问题。
Redis的初心：最初就是用来作为一个**"消息中间件"**的消息队列,实现分布式系统下的生产者消费者模型。但是目前很少使用Redis作为消息中间件的作用。
2.分布式系统
2.1单机架构
单机架构：只有一台服务器，这个服务器负责所有的工作。
一句话总结：用户只跟 Web 服务器说话，Web 服务器只跟数据库服务器说话，真正碰数据的只有 MySQL Server。
疑问：在单机程序中，能不能把数据库服务器也去掉，只留一个应用服务器及负责业务又负责数据存储？【答：技术上可以实现，但是工程上几乎不这样干。因为：❶ 并发 & 多进程安全极差；如果不用MySQL,反而自己管数据文件：要自己实现 读写锁 ，要处理 死锁 ，要处理 多进程同时写文件）相当于重新造了一个数据库；❷ 事务 / 崩溃恢复太难；❸ 无法独立扩展 / 维护（如果业务 + 数据引擎绑在一个进程：想换存储引擎 → 重写；想迁移数据库 → 不可能；想让多个服务共用数据 → 锁死）；❹ 稳定性风险极高（业务代码崩了或内存越界或线程异常，可能会直接破坏数据文件）；❺ 无法支持多语言 / 多客户端（智能被自己的程序读取）】
**可以一个程序既处理业务又管数据（如 SQLite），但那是"嵌入式数据库"用法；
Web 后端不这么做，是因为：并发、事务、安全、扩展、维护性------你不该自己再写一个数据库。***
2.2分布式
如果业务进一步增长，用户量和数据量使一条主机难以应付的时候，就需要引入更多的主机和硬件资源。（一台主机的硬件资源【包括但不限于：1.CPU 2.内存 3.硬盘 4.网络带宽】是有上限的，服务器每次收到一个请求都是需要消耗上述的一些资源去处理这个请求；如果同一时刻处理的请求多了，此时就会导致某个硬件资源不够用了！无论哪个方面不够用了，都可能会导致服务器处理请求的时间变长，甚至处理出错。）
-----------（如何处理上述问题）-----------
1.软件上优化：需要通过性能测试，找到是哪个环节出现了瓶颈，再去对症下药（难）；
2.去增加更多的硬件资源（简单粗暴）
由于一个主机上面能够增加的硬件资源是有限的，取决于主板的扩展能力，当扩展到最大极限还是不够用时，就只能引入多台主机了-->不是拿来直接用，也需要在软件上做出相应的调整和适配。
一旦引入多台主机，系统就可以被称为"分布式系统"。（引入分布式是万不得已的决定，因为这样系统的复杂程度会大大提高。）
2.3数据库分离
应用服务和数据库服务分离（基本分离情况）：分离之后能一定程度上解决刚才说的硬件资源不够用的问题。
2.4理解负载均衡
引入更多的应用服务器节点：
这里要call back一下多线程的概念，因为多线程 的处理与负载均衡很像:
**多线程让"一台服务器干得更快"，负载均衡让"多台服务器一起干"；
真实后端系统 = 负载均衡 × N 台机器 × 每台多线程。**
负载均衡器对于请求量的承担能力是要远远超过应用服务器的，因为他的工作是"分配任务"，而应用服务器的工作是"执行任务"。如果请求量大到负载均衡器也撑不住了，就引入更多的负载均衡器(引入多个机房)。
2.5数据库读写分离
随着增加更多的应用服务器处理更多的请求量，存储服务器要承担的请求量也就更多了。
