本篇摘要
- 本篇将简单介绍下何为
Redis，以及它的简单概念，以及关于分布式系统的简单概念，如单机架构，什么是分布式，负载均衡，缓存，微服务等概念。
一·浅谈Redis
Redis是基于内存的一块存储数据的小型缓存（也可以理解成小型数据库）。
也学会有个疑问，在内存中存储数据为什么不直接使用变量存储呢？
- 因为是单机程序，肯定直接选择变量存储是更优势的，但是如果是分布式系统的话，Redis肯定是略胜一筹的！
对应MYSQl也是一个数据库，它俩有啥区别呢？
- 首先MYSQl是大型的，它的优点就是慢，存储大，而Redis就是快，存储少，应该按需求选择。（但是经常结合使用，比如20%存储热点数据【也就是经常被访问使用的】于Redis；80%不经常被访问的就用MYSQl即可）
Redis 的初心最初就是用来作为一个"消息中间件"的(消息队列)分布式系统下的生产者消费者模型；当前很少会直接使用 Redis 作为消息中间件(业界有更多更专业的消息中间件使用)
总之，Redis 就是基于网络,可以把自己内存中的变量给别的进程，甚至别的主机的进程进行使用。
一张图秒懂大致流程：
基本概念
模块(Module)/组件(Component）：一个应用,里面有很多个功能,每个独立的功能,就可以称为是一个 模块/组件。分布式(Distributed)：引入多个主机/服务器,协同配合完成一系列的工作（物理上的多个主机）集群(Cluster)：引入多个主机/服务器,协同配合完成一系列的工作（逻辑上的多个主机）。主(Master)/从(Slave)：分布式系统中一种比较典型的结构，多个服务器节点,其中一个是主,另外的是从.从节点的数据要从主节点这里同步过。中间件(Middleware)：和业务无关的服务(功能更通用的服务)，比如：数据库，缓存，消息队列等。可用性(Availability)：系统整体可用的时间/总的时间。响应时长(Response Time RT)：衡量服务器的性能，和具体服务器要做的业务密切相关的。
一句话通俗了解Redis：
Redis 就像是一个超级快的内存小仓库，你可以把它当作一个临时的小本本，快速地记东西、找东西、改东西，特别适合用来做缓存、计数器、消息队列等需要高速读写操作的场景。
二·浅谈分布式
首先要明白的就是，我们使用的每台主机都是有上限的（硬件资源）比如：CPU 内存 硬盘 网络。
当我们请求过多的时候，这个主机的硬件资源就不足了，就导致服务器请求失常过多，甚至崩溃，那要怎么解决呢？
那就是开源或者节流：
- 开源：简单粗暴增多不足的硬件设备。
- 节流：通过性能测试进行整改操作。
但是硬件资源也是不能无限拓展的（取决于主板的拓展能力），最后就要引入多台主机协作了（也就是分布式）【构成分布式系统，但是也是迫不得已而为，维护等成本也要增大】。
单机架构
如下：
- 首先比如用户进行访问：先通过域名解析出ip，然后对应的请求对应的应用服务器（业务能力需要很强，因此非常占CPU 内存等资源），然后去对应的数据库服务器拿数据。
大致流程：
对应的服务器种类：
Web服务器软件：Tomcat、Netty、Nginx、Apache等
数据库软件：MySQL、Oracle、PostgreSQL、SQL-Server等
- ⽤⼾访问量很少，没有对我们的性能、安全等提出很⾼的要求，⽽且系统架构简单，⽆需专业的运维团队，所以选择单机架构是合适的。
数据库分离与负载均衡
为了缓解对应的访问压力，可以最⼩代价的提升系统的承载能⼒，我们选择了将应⽤和数据分离的做法：
- 和之前架构的主要区别在于将数据库服务独⽴部署在同⼀个数据中⼼的其他服务器上，应⽤服务通过⽹络访问数据。
但是如果访问过多，单台应⽤服务器已经⽆法满⾜需求了，因此就需要引出新的技术了。
大致流程：
因此引入负载均衡技术。
负载均衡：为了解决⽤⼾流量向哪台应⽤服务器分发的问题，需要⼀个专⻔的系统组件做流量分发。实际中负载均衡不仅仅指的是⼯作在应⽤层的，甚⾄可能是其他的⽹络层之中（比如之前学的NAT网络技术那里就是这样）。
如下：
用户的请求先到达负载均衡器（网关服务器)，然后被分发到对应的应用服务器然后就是上面雷同的操作了。
大致流程：
因此就可以这么理解：
负载均衡器： 是领导, 分配工作。应用服务器：是组员,执行任务。
如果请求量大到负载均衡器也扛不住了，那就只能多加负载均衡服务器了（但是这样付出的代价就要多了）。
数据库读写分离
用户如果频繁访问对应一个数据库（读的频率是远高于写的），尽管已经做到了负载均衡，但是仍然可能出现较大的压力，因此这里我们采取主从分离操作来缓解。
因此这里可以这么操作：一个主库（用于用户写入然后同步到多个读库），多个多库（将数据分散开了并建立联系，供用户读取）。
主服务器一般是一个，从服务器可以有多个(一主多从)；同时从数据库通过负载均衡的方式,让应用服务器进行访问。
应⽤中
需要对读写请求做分离处理，所以可以利⽤⼀些数据库中间件，将请求分离的职责托管出去。（中间件如：MyCat、TDDL、Amoeba、Cobar等类似数据库中间件等）
流程图总结：
缓存机制（冷热分离架构）与分库分表操作
首先要认识：
热点数据：业务中⼀些数据的读取频率远⼤于其他数据的读取频率。冷数据： 也就是不经常访问的。
为了缓解用户大量访问带来的压力，我们采取冷热分离，还是引入本地缓存等来缓存对应的热点数据，从这里就拦截了用户去数据库（从而缓解压力）。
这里比如一个商品网站，把对应的商品信息等常见的信息作为热点数据放在缓存中，而交易界面等不常见就放在库里。
使⽤memcached作为本地缓存，使⽤Redis作为分布式缓存，还会涉及缓存⼀致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。
如：
随着数据量不断增多，压力也变大了，因此又引入了新的管理方式如：分库分表操作。
分库操作：增多数据库，每个数据库存储一部分数据。分表操作：这里比如一张表数据太大了，就可以按一定规则分开，多个库存储。
但是这里要怎么分呢？ 根据业务需求即可，永远要记住：业务决定了技术！
如：
相关使用软件:
- Greenplum、TiDB、PostgresqlXC、HAWQ等，商⽤的如南⼤通⽤的GBase、睿帆科技的雪球DB、华为的LibrA等
流程图展示：
微服务
对于全部数据都安排在具体的整个服务器，就会使得它的维护变得十分困难，因此，采取把它按照一定规则分成多个小的服务器集群（每部分人只需要维护对应的集群即可，其他不管，这样就简化操作了）。
如下：
- 随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微服务，然后互相之间对数据的直接访问进⾏隔离，可以利⽤Gateway、消息总线等技术，实现相互之间的调⽤关联。甚⾄可以把⼀些类似⽤⼾管理、安全管理、数据采集等业务提成公共服务。
大致流程：
这样引入微服务，有利也是有弊的，那么下面说下弊端：
- 这样分散出去就需要引入大量硬件设备等资源耗费以及之间的通信（网络通信比硬盘读取还慢，因此都是耗费）。
- 分散出去后，离散度增高了，整个系统框架的维护成本就要增加了。
优势：
- 解决了人来管理的问题。
- 使用微服务,可以更方便于功能的复用。
- 可以给不同的服务进行不同的部署。
三.本篇小结
本篇学习了分布式基本概念如：
单机架构：应用程序 +数据库服务器。数据库和应用分离:应用程序和数据库服务器分别放到不同主机上部署。负载均衡：通过负载均衡器，把请求比较均匀的分发给集群中的每个应用服务器。读写分离与数据库主从结构：一个数据库节点作为主节点,其他N个数据库节点作为从节点，主节点负责写 数据，从节点负责 读 数据，主节点需要把修改过的数据同步给从节点。缓存与冷热数据分离：进一步的提升了服务器针对请求的处理能力（上面说的二八原则）。分库分表：数据库拓展空间，缓解压力。引入微服务：把应用服务器拆分成更多的功能更单一,更简单,更小的服务器集群。
本篇分享到此为止，欢迎大家继续订阅阅读此专栏。