【进击的前端】Node 开发者必知后端知识图谱（二）.md

本文首发于 本人掘金专栏https://juejin.im/user/5a676894f265da3e2b16921c/posts， 欢迎关注交流

在上一章中，我们简单介绍了后端架构的整体框架。

目前，你已经了解到，作为一个后端开发者，我们需要关注的点有：性能， 高可用， 伸缩性， 拓展性， 安全性。

在接下来的章节中，我们将依次对这些话题进行讨论。

其他链接

【进击的前端】node开发者必知后端知识图谱（一）

【进击的前端】node开发者必知后端知识图谱（二）

本章节知识图谱

在本章节，我们的关注点主要是在 高性能 和 高可用

性能优化

性能优化是软件发展史中亘古不变的追求。

那么，对于后端同学来说，我们追求高性能，究竟什么样才是高性能？高性能我们需要关注哪些指标？ 后端架构应该如何设计，才能达到高性能呢？ 下面会一一介绍

性能测试指标

1. 响应时间，越少越好

2. 并发数，越多越好

3. 吞吐数量，越多越好

4. 性能计数器(system load)，主要包括内存使用，cpu使用，磁盘使用等。

并发数 和 吞吐量的区别？

并发数:就是并发连接数，指网络设备所能处理的最大会话数量。这里的会话数是指请求->响应一次会话。

吞吐量: 用户请求是由一个个数据包组成，网络设备（防火墙/路由器/交换机）对每个数据包的处理要耗费资源。吞吐量是指在不丢包的情况下单位时间内通过网络设备的数据包数量。

并发数x包长度=吞吐量 参考知乎衡量网站性能时，并发数与吞吐量为何要分别考量？

性能优化策略

那么，性能优化的策略有哪些呢？

策略1： 前端性能优化

1. 减少http请求

2. 使用浏览器缓存

3. 启动压缩

4. css放在最上面，js放在最下面

5. 减少cookie大小

策略2： cdn加速

主要使用cdn缓存静态资源：比如说文件，css, js 等静态文件。

策略3： 反向代理

反向代理位于服务器一侧。

1. 提高安全

2. 可以使用缓存

3. 负载均衡

正向代理、反向代理

正向代理 和 反向代理

正向代理代理客户端，为客户端收发请求，客户端必须要做一定的配置，比如说，翻墙。

用户不能直接访问facebook, 但是可以访问服务器A，服务器A可以访问facebook, 服务器A 就被称为正向代理。

反向代理服务端，隐藏了具体的机器，可以用于负载均衡

策略4：应用服务器的优化

应用服务器是后端业务代码部署的地方，也是最复杂，变化最多的地方，优化的主要手段有缓存，集群，异步等，具体介绍如下:

1. 分布式缓存

网站性能优化第一定律 : 优先考虑使用缓存

使用缓存的注意点：

1. 不要存放频繁修改的数据，数据的读写比要在2：1以上

2. 没有热点的访问。缓存珍贵

3. 数据不一致和脏读。�要容忍一定时间的数据不一致

4. 缓存雪崩。就是大部分情况下，都会走缓存，万一缓存有一天不能用了，流量就会全部打到数据库上，从而造成数据库的崩溃

5. 建议缓存预热， 缓存里面存放的是热点数据。如何判断是热点数据呢？是根据LRU(最近最久未使用算法)对不断访问的数据筛选出来的，这个过程需要花费一定的时间。新启动缓存，没有任何数据，因此刚开始的性能会比较差，最好在刚启动的时候就把热点数据加载好，这就叫 缓存预热

6. 注意缓存穿透， 如果是不恰当的代码，或者是恶意攻击，会频繁的请求一个不存在的值，缓存中没有，就会去数据库中找，从而拖慢数据库。建议给不存在的数据也缓存起来。

分布式缓存的两个代表：

1. jboss ( 同步更新 )

2. memcached ( 互不通讯�，高效的网络TCP, UDP, 高效的内存管理 )

2. 异步操作

使用消息队列将调用异步化，不仅仅可以增强拓展性，也可以提高性能。

不使用消息队列，直接操作数据库，延迟高，高并发压力大。

使用消息队列，将峰值的事务存放在消息队列中，从而削平了高峰的并发事务。

但是后续操作可能会失败，因此会要业务上，通过邮件等方式避免纠纷。

3.使用集群

高并发时，使用负载均衡，把一组机器组成一个集群，把并发请求发到多台机器上处理。

负载均衡

1. http重定向

   主服务器的吞吐量限制

2. DNS解析

3. 反向代理

4. ip负载均衡

高可用

网站为了实现高可用，一般会分为三层：应用层，服务层，数据层

应用层是通过负载均衡来把一组机器来组成集群。负载均衡的设备通过心跳检测检测（或者是服务器放一个check_live.html, 或者是通过header请求）到某一个服务器不可用时，就把流量分发到其他的服务器上。

服务层是通过分布式服务调用框架来来实现负载均衡。

数据层比较特殊。�为了保证服务器宕机的时候，数据不丢失，需要在数据写入的时候，就对数据进行同步复制，将数据写入多台机器中，实现冗余备份。

高可用的应用层

通过负载均衡进行无状态服务的失效转移

应用层通过负载均衡来保证高可用。实现的�前提是，任意一个服务器都不保持请求的上下文，也就是，对于同一个请求，所有的服务器都对等。

集群的session管理

单独部署一个session服务器，用来同一管理session。

高可用的服务层

分级管理

性能更好的机器分配给更核心的业务

超时设置

一旦服务层超时，应用层换一个机器重新尝试

异步调用

应用层对服务层的调用可以通过异步的形式，避免一个服务层方法的失败，导致整个链路的异常。比如说用户注册的流程是：写入数据库，发送确认邮件，开通权限。如果是同步的，【发送邮件】这一步有可能会阻塞掉，从而导致用户注册失败。

服务降级

网站高峰期，为了保证核心功能是没有问题的，通常会采用下面的方法：

1. 拒绝服务。一部分不可用，总比全部人都无法用好。

2. 关闭功能。比如说淘宝双十一关闭了评价的非核心功能

幂等性设计

应用层调用了服务层的转账接口，但是没有拿到成功的结果，于是重复调用接口，很容易就悲剧了。

服务重复调用是不可避免的，因此需要服务层做好幂等性设计，调用一次和调用一百次的结果是一样的。

高可用的数据层

数据层的高可用的指标是：

1. 数据持久性。通过在不同的设备上进行备份

2. 数据可访问性。出现了服务器宕机，可以快速备份

3. 数据一致性。不一致的情况：一部分服务器更新了，另一部分服务器没有更新。

cap 原理：

我们永远没有办法实现，数据一致性（consisitency）, 数据可用性（availibility）和伸缩性 这三个目标。

一般我们会优先保证 伸缩性和数据可用性，而牺牲数据一致性。

数据备份

冷备和热备的区别

冷备份：数据库是关闭，直接拷贝到另外一个地方。

热备份：数据库是运行状态。

热备份分为两种: 异步热备 和 同步热备

失效转移

如果数据服务器某一个机器宕机，那么�针对这台服务器的读写必须重新路由到其他服务器。

失效转移有三部分构成：失效确认、访问转移、数据恢复