Redis【服务端高并发分布式结构演进之路】

单机架构（应用程序+数据库服务器）:

应用服务指的就是我们写的服务器程序，在线论坛就是一个单机系统，程序和数据库都在一台主机上完成。一台主机的硬件资源包括但不限于：

1. CPU
2. 内存
3. 硬盘
4. 网络

每一次请求都会消耗服务器的硬件资源，如何用户数量众多一台主机的服务能力肯定是不够的。如何解决这个问题呢？无非是开源节流。

        从节流的角度思考，我们可以对代码进行优化提高代码质量，这一点要求程序员具有较高的编码水平。

        从开源的角度思考，我们可以扩展这台主机的硬件资源或者引入多台主机。引入多台主机，整个系统就称之为“分布式系统”，虽然合体提高系统的服务能力，但系统的复杂程度也随之提高。

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

将应用服务和存储服务拆分开来，部署到不同主机之上，主机之间通过网络进行数据访问，虽然可以减轻主机的压力，提升服务能力，但是速度可能会相对变慢。对于应用服务器来说，对CPU的消耗较大，我么可以给应用服务器使用更好的CPU;对于存储服务器而言，消耗硬件资源较大，我们可以给存储服务器使用较大的硬盘。

引入负载均衡器，应用服务集群架构：

在集群中，某一主机挂了，其他主机仍然可以承担服务。

如果用户请求过于庞大，一台应用服务器难以支撑，我们可以引入更多的应用服务器形成应用服务集群，同时添加负载均衡器提高集群的整体效率。负载均衡器接收用户的请求并转发给应用服务器。通过这种方式可以提高系统的服务能力，但同时也引入了新的问题，比如负载均衡器的转发策略，用户的登录请求第一次转发给了A服务器并存储会话信息，第二次登录请求转发了B服务器，因为没有会话信息则需要重新输入密码验证给用户带来不便。上图中只有一个负载均衡器，他需要接收所有的用户请求并进行转发。负载均衡器对于请求的承担能力远远大于应用服务器，因为他不需要处理大量复杂的业务。如果一台负载均衡器无法承担大量请求，那么就需要引入更多的负载均衡器。

读写分离——数据库主从分离架构

对于上述架构，应用服务器可以处理更多的请求了，随之存储服务要承担的请求也会增加，如何提高存储服务器的服务能力？我要理解存储服务器是做什么的。存储服务器就是读取和写入数据的，而大多数情况下读数据的请求要比写数据的请求多，服从二八原则，所以我们可以将读写请求分离开来：

在这个架构中引入多台存储服务器，写数据的请求会发送给主数据库的服务器，读数据的请求会发送给从数据库服务器。这样就可以提高存储服务的服务能力了，随之带来的就是主从数据的同步问题。主数据库会存储全量数据。主存储服务器一般是一个，会有多个从存储服务器，一主多从。

可以将全量数据分开存储在不同主机上吗？貌似不是不可以，只是会带来新的问题，使得这种方式性价比不高。

引入缓存——冷热分离架构：

Redis在一个分布式系统中通常扮演者缓存的角色。

事实上不只读写复合二八原则，数据的访问也符合二八原则，不同时间有些数据会被频繁访问，被称之为热数据，与之相对应的是冷数据。而且数据库天然的一个问题就是慢。针对热数据，为了提升其读取的响应时间，可以增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的 html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。其中涉及的技术包括：使用memcached作为本地缓存，使用Redis作为分布式缓存，还会涉及缓存⼀致性、缓存穿透/击穿、缓存雪崩、热点数 据集中失效等问题。

分库分表——数据库可以进一步扩展空间：

引入分布式系统，可以处理更多请求，同时也要存储更大的数据量，一台主机存不下了，就需要多台主机来存储。针对数据库进一步拆分，分库分表。本来一台数据库服务器就会有很多数据库（指的是逻辑上的数据集合，create database创建出来的数据库），引入多台数据库服务器，每个数据库服务器存储一个或者一部分数据库（逻辑上的），如果某个表特别大，也可以针对表进行拆分，因涉及到CRUD,所以具体如何拆分还要看具体的业务需求。业务决定技术

有点深奥了上原文吧：

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

在之前的架构中，一个应用服务器可以处理多种业务，这会使得服务器的代码越来越复杂，为了可以更好的维护代码，就可以把服务器拆分更多，代码也随之分开，功能更单一，更小的服务器，服务器的是种类和数量随之增加。

微服务架构解决了“人员团队分工合作的问题” ，当系统变得复杂庞大就需要更多的人员维护，人员组织管理的问题也随之而来，将系统按照功能，拆分成多组微服务就利于人员的结构分配了。

引入微服务的代价：

1. 系统性能下降：拆分处出更多的服务器，服务器之间是通过网络通信的，而网络的速度可能比硬盘还要慢，而万兆技术有比较贵。
2. 系统复杂程度提高，可用性受到影响：服务器变多了，出现问题的概率也就变高了，这就需要一定的手段来保证系统的可用性（更丰富的监控报警，以及配套的运维人员）

微服务的优势：

1. 解决了人员组织架构的问题
2. 使用微服务更方便与功能的复用（但一功能的代码独立出来，解耦合）
3. 可以给不同的服务进行不同的部署