想让Redis发挥出自身优势，就离不开分布式三个字，接下来介绍一下什么是分布式。
- 单机架构
对于一些简单的服务端应用，在服务器上一般都会运行一个服务端进程，使用数据库存储数据。服务进程通过网络接收用户的请求，进行业务处理，并对数据库进行读写。
但是如果用户人数多起来了，那么一台主机就无法应付，比如内存、网络、硬盘、CPU等资源都可能不足，一台主机的能力有限，此时就有两种解决思路：
- 对软件进行优化，提高软件的效率
- 引入更多的服务器，让多个服务器共同完成一个服务
一旦引入了多台服务器完成一个服务，那么整个系统就称为一个分布式系统了。要注意的是，并不是直接再买一台服务器就可以解决问题的，还要考虑如何部署服务，多个主机上的服务如何完成数据的同步等等复杂的问题，最后问题又回归到了软件层面。
- 应用数据分离架构
当有了多台主机，为了提高服务器的效率，会让一个服务器尽可能只干一种活，此时就把应用服务和数据库分离开，服务器只专门负责其中一个任务。
- 应用服务集群架构
当业务量再大起来，就要由多台服务器来处理业务逻辑，此时多个服务器共同完成一个任务，称为一个集群。这种架构叫做应用服务集群架构。那么当用户向服务器发起请求，到底要发往哪一台主机？也就是说此时需要有一个进程来决策用户的请求给哪一个应用服务完成，此时就引入了负载均衡，保证每个应用服务承担差不多的任务。
- 读写分离架构
当应用服务多了起来，那么整个服务要存储的数据也就多了，此时数据库系统不可能只用一台服务器处理，所以就要用多个服务器来共同完成数据存储。
之前说过，尽可能让一个服务器完成相同的任务，而数据库的任务无非就是读取与写入，此时把读写分开，就称为读写分离架构。一个服务器负责写入数据库，另一个数据库负责读取数据，此时被写入的数据库还要实时进行数据同步，将数据传给被读的数据库。
对于多个数据库的情况，往往会选出一个头儿，称为主数据库，其余数据库称为从数据库，这种架构称为主从架构。
- 冷热分离架构
在实际上，数据库中的数据只少量被访问，计算机界常说二八原则，即20%的数据可以处理80%的访问量。那么就可以把这小部分数据拿到缓存中，以更快的速度访问到。
此时读取数据的逻辑就是，先读取缓存中的数据，如果缓存中有那么直接返回，如果缓存没有，再去数据库查找。而此处的缓存，就是Redis的应用场景之一。
- 分库架构
当业务再庞大些，就可能出现一个数据库的表就存不下一张表了，此时就要对表进行再拆分，一个数据库只存一个表，根据具体的种类去查询某一个数据库。此处每个表都用一个数据库集群来存储，遵顼之前的主从，读写分离架构。
- 微服务架构
当应用服务再复杂些，此时业务逻辑就很难维护，此时就可以把整个服务拆分为多个服务。每个服务只负责一个模块的业务开发，一个个小的服务称为微服务，一群微服务共同完成一个大服务，这种架构称为微服务架构。