面试系统化学习和准备（一）——今日事必须今日毕

面试策略：其实你是不是真的做过项目，面试官一下就能知道，所以没必要撒谎。撒谎还会让自己感到紧张，没有必要，就实话实说除了特别必须撒谎的部分。（杨顺强都能一下听出来没做过项目）

 

昨天任务差2个没写完：

1.STAR原则（这个应该好写 两句话的事儿），其实就是最困难的项目：纸上写了思路，明天再优化一下。----》关键点在于让面试官一下子就知道你的优势在哪儿。

2.介绍自己的产品（这个应该也好写 ）---》关键点在于让面试官一下子就知道你产品的优势在哪儿

郑杰给推荐的热门云计算课程：

https://edu.aliyun.com/roadmap/cloudnative?spm=a2c6h.12873639.0.0.2a306e7eSm2HIU

 

 

一、Seafile架构相关包括：负载均衡层、应用层（seafile+数据库）、存储后端

1.负载均衡器

（1）定义：可以将流量均匀的分配到各个服务器上的工具

（2）从软硬件层面区分：硬件负载均衡器F5（很贵）、软件负载均衡器（常用）

（3）软件负载均衡器从协议上可分为

1.四层代理：Linux的LVS，基于传输层协议，仅支持TCP协议，仅支持轮询策略

2.七层代理：Haproxy、Nginx，都是既支持TCP又支持HTTP，提供丰富的负载均衡策略

（4）Haproxy和Nginx区别

1.Haproxy比Nginx更专注于负载均衡这一件事，所以转发负载性能更好

2.对于Seafile来说，会话保持是很重要的，haproxy配置起来比nginx简单。

（5）会话保持

1.定义：在一次会话过程中，发起的多个请求都要落到同一台机器上。

2.意义：因为HTTP是一种无状态协议，对请求和响应的状态都不保存，很容易导致用户访问网页其他页面时候需要重新登陆。

3.工作原理：首先clinet向server发起请求---》server检查是否有cookie，如果没有给你生成一个set-cookie字段保存cookie，并在cookie中写入SessionID来标识这个客户端。----》客户端收到set-cookie字段，之后每次请求都带上Cookie信息和SessionID---》服务端返回响应

4.相关概念

A. Cookie：由于server有成百上千的celint来访问，所以该用户状态都需要在客户端记录，以减轻服务端压力。Cookie是保存在客户端的一小段文本，每次客户端请求都需要发送cookie字段和SessionID，这样服务端就能知道你是哪个client，也能收到你这个用户当前的状态信息。

B. Session：Session保存在server端，server就只保存这么一个表记录所有SessionID，每个SessionID对应唯一一个客户端。

 

（6）常用的负载均衡策略有以下五种

1.轮询策略（默认）：所有请求均匀分配（排排坐吃果果，你一个我一个）

2.权重策略： 手动设置权重，性能高的服务器承担更多负载（我比你胖，我要吃10个）

3.IP哈希：以IP地址为标准，对服务器数量取模运算（一个萝卜(IP)一个坑，很不建议，无法保持负载的均衡）

4.IP_URL哈希：以IP发来的URL为标准，比如1.jpg取模之后余数为1 永远去服务器1处理，2.jpg永远去2服务器处理，处理粒度更细，但是还是负载不均衡。

5. Fair：优先将请求分配给低延时的机器（你们谁闲着就挑粪去）

（7）如何保证不会单点故障：部署两个haproxy，通过keepalived来实现主备的高可用。keepalived通过七层协议中三四五层的交换机制来监控节点服务状态，客户端通过一个虚拟IP地址来访问，当keepalived检测到主负载均衡不可用的时候，可以主动将VIP切换到备份负载均衡器上。

 

2.MariaDB数据库

（1）架构选择：MariaDB集群分为主从和多主，主从的话异步同步有延迟，可能造成数据丢失。多主的方案要求强一致性来保证数据延迟，多主节点之间通过wsrep协议/接口来实现高可靠。

（2）wsrep API：是一种数据库插件接口，主要针对写复制，该程序主要用于定义应用程序如何调用复制库进行回写。

为什么用wsrep API：数据库的一个对象，被客户端修改，导致事务产生一系列的原子性改变，在集群中所有的节点都具备相同的对象，由同步复制机制应用到各个节点。

【数据库实现负载均衡的思路跟seafile是一样的】

 

3.存储

（1）数据容灾指标体现：

RPO：（Recovery Point Obejective，恢复点目标）是指业务系统所允许的在灾难过程中的最大数据丢失量，用来衡量容灾系统的数据冗余备份能力。

RTO：（Recovery Time Objective，恢复时间目标）是指信息系统从灾难状态恢复到可运行状态所需的时间，用来衡量容灾系统的业务恢复能力。

如果本地服务中心被摧毁，我们的数据是不会丢失的，因为我们已经实时将全部数据备份到了异地，因此RPO是没有的。而RTO的话单节点是1小时，集群的话1天以内恢复服务。

（2）工作原理：

实时备份采用了跟客户端一样的同步算法，从主服务器检索增量的修改，并实时同步到异地的数据中心，而且每隔1小时备份服务器会主动检查一次主服务器上的所有数据库。

除了底层存储需要备份之外，还需要备份数据库，可以做一个crontab任务定时用mysqldump导出数据库文件，数据库延迟导出不会影响资料库数据的完整性。

 

二、如何保证安全性以及其他问题

0.统一认证的工作原理

最基本的思想是引入了一个授权层，来分离客户端和用户。 客户端应用想获取token，首先需要备案（不是说你是个应用就给你发token的）拿到appid和appkey，其次需要用户授权。

完整的流程如下：

1. 客户端带着appid、redirect_url、ressponse_type=code参数向认证服务器发请求，请求授权码code。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

 

2.认证服务器重定向到redirect_url页面，请求用户登录和授权。用户同意授权，返回code给客户端。

3.客户端带着appid appkey redirect_url  code这几个参数，后端发请求token。认证服务器返回token（json格式的）。就这么简单。

 

密码式的话就是相当于用户非常信任这个应用，直接把用户名和密码告诉应用客户端了。客户端都不需要备案，直接带着账号密码向认证服务器发请求，然后验证通过了就拿到token。 跟授权码方式最大的区别是，授权码是用户自己去认证服务器登录，而密码式是用户直接把密码交给客户端，客户端去认证。显然多一个人知道密码就更不安全。

 

这篇讲的最好可以看下：

https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

 

 

 

 

1.web服务怎么保证安全性：

（1）防火墙过滤网络攻击，杀毒软件查杀

（2）尽量避免暴露不必要的端口，比如我们就只开放了80和443
（3）限制登录IP段，我们有限制登录的功能

 2.nginx反向代理有什么好处

为什么要用反向代理，因为正向代理是代理服务器和客户端之间做一些配置，需要用户有感知。而反向代理是应用服务器和代理服务器之间做一些配置，用户无感知。

反向代理的好处是可以只暴露代理服务器地址，隐藏应用真实服务器地址，提高了安全性。对于客户端的请求，可以进行一些过滤处理掉一些不安全的信息。代理服务器硬盘还会缓存一些访问过的数据，来提高访问速度。

 3.你们网盘怎么保证同步的速度，你们如何处理数据的。 

 一个是本地来计算索引并且分块，另一个是多线程同步，主要还是自研的同步算法性能高。

4.你们会帮客户做哪些测试？

压力测试、同步性能测试

（这些就说一下怎么做就行了吧，我不记自己的数据，负载都挺低的。）