面试策略：其实你是不是真的做过项目，面试官一下就能知道，所以没必要撒谎。撒谎还会让自己感到紧张，没有必要，就实话实说除了特别必须撒谎的部分。（杨顺强都能一下听出来没做过项目）
昨天任务差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=read2.认证服务器重定向到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.你们会帮客户做哪些测试？
压力测试、同步性能测试
（这些就说一下怎么做就行了吧，我不记自己的数据，负载都挺低的。）