【redis】服务器架构演进

单机架构

所有的应用服务、业务所需的数据、业务处理等都在一台服务器上。

在初期，用户访问量很少，对服务器的的性能和安全没有很高的要求，所以单机架构足以胜任。

⽤⼾在浏览器中输⼊ 网站名，⾸先经过 DNS 服务将域名解析成 IP 地址 ，随后浏览器访问该 IP 对应的应⽤服务。

应用数据分离架构

随着用户访问量的增加，已经逐渐逼近了系统的极限，需要进行系统重构，我们将应用服务和数据库服务分开部署到不同的服务器上，显著提高两者各自性能。

应⽤服务集群架构

我们上线的服务受到用户的欢迎，用户访问量暴增，单台服务器已经无法满足需求。
服务器应用首先遇到瓶颈，商讨后，有两种解决发案：

1. 垂直扩展 / 纵向扩展:通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量。
   这种⽅案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增⻓关系是⾮线性的，意味着选择性能 2 倍的硬件可能需要花费超过 4 倍的价格，其次硬件性能提升是有明显上限的。

2. ⽔平扩展 / 横向扩展:通过调整软件架构，增加应⽤层硬件，将⽤⼾流量分担到不同的应⽤层服务器上，来提升系统的承载能⼒。
   这种⽅案的优势在于成本相对较低，并且提升的上限空
   间也很⼤。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验

当然也可以进行软件优化来解决问题，但是这对程序猿的要求很高，需要通过性能测试区对症下药，也同样是有上限的。

我们选择了水平扩展方式，但是，为了保证用户的请求被平均的分配的每一台应用服务器上，需要⼀个专⻔的系统组件做流量分发-----负载均衡，这就可以说是分布式系统了。

引入分布式后，系统的复杂程度大大提高，出bug的概率也会更高。

负载均衡软件：Nginx、HAProxy、LVS、F5 等

读写分离 / 主从分离架构

我们通过水平扩展方式，引入多台应用服务器并设计好了负载均衡服务器后，我们解决了用户请求量增加的问题，但是，这些请求最终都会从数据库读写数据，到⼀定程度之后，数据库服务器就会达到极限，称为系统承载能⼒的瓶颈点。
我们可以像扩展应⽤服务器⼀样扩展数据库服务器么？答案是否定的，因为数据库服务有其特殊性：如果将数据分散到各台服务器之后，数据的⼀致性将⽆法得到保障。

所谓数据的⼀致性
此处是指：针对同⼀个系统，⽆论何时何地，我们都应该看到⼀个始终维持统⼀的数据。想象⼀下，银⾏管理的账⼾⾦额，如果收到⼀笔转账之后，⼀份数据库的数据修改了，但另外的数据库没有修改，则⽤⼾得到的存款⾦额将是错误的。

我们采⽤的解决办法是这样的，保留⼀个主要的数据库作为写⼊数据库，其他的数据库作为从属数据库。从库的所有数据全部来⾃主库的数据，经过同步后，从库可以维护着与主库⼀致的数据。然后为了分担数据库的压⼒，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。

冷热分离架构

随着访问量继续增加，发现业务中⼀些数据的读取频率远⼤于其他数据的读取频率。我们把这部分数据称为热点数据，与之相对应的是冷数据。针对热数据，为了提升其读取的响应速度，可以增加本地缓存，并在外部增加分布式缓存。

对于大多数的业务来说，通常会出现 二八现象，80%的访问量是冲着那20%的热点数据去的，我们将热点数据放入缓存，能把绝⼤多数请求在读写数据库前拦截掉，⼤⼤降低数据库压⼒。

相关软件：
Memcached、Redis 等缓存软件

垂直分库

随着业务的数据量增⼤，⼤量的数据存储在同⼀个库中已经显得有些⼒不从⼼了，所以可以按照业务，将数据分别存储。

微服务架构

随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微服务。
将之前的复杂的服务器拆分成更多的，功能较为单一，更小的服务器。降低了维护服务器的难度，但是服务器的数量和种类更多了。
也会降低业务整体的性能，因为各个拆分出来的服务要进行网络通信，而网络通信的速度可能会比硬盘的读取速度还慢。