分布式（10）

46.什么是Session Replication?

47.什么是Session数据集中存储？

48.什么是Cookie Based Session?

49.什么是JWT？使用JWT的流程？对比传统的会话有啥区别？

50.如何设计一个秒杀系统？

51.接口设计要考虑哪些哪些方面？

52.什么是接口幂等？如何保证接口的幂等性？

46.什么是Session Replication?

Session Replication的方案则不对负载均衡器做更改，而是在Web服务器之间增加了会话数据同步的功能，各个服务器之间通过同步保证不同Web服务器之间的Session数据的一致性，如下图所示。

Session Replication方案对负载均衡器不再有要求，但是同样会带来以下问题：

同步Session数据会造成额外的网络带宽的开销，只要Session数据有变化，就需要将新产生的Session数据同步到其他服务器上，服务器数量越多，同步带来的网络带宽开销也就越大。

每台Web服务器都需要保存全部的Session数据，如果整个集群的Session数量太多的话，则对于每台机器用于保存Session数据的占用会很严重。

47.什么是Session数据集中存储？

Session数据集中存储方案则是将集群中所有Session集中存储起来，Web服务器本身则并不存储Session数据，不同的Web服务器从同样的地方来获取Session，如下图所示。

相对于Session Replication方案，此方案的Session数据将不保存在本机，并且Web服务器之间也没有了Session数据的复制，但是该方案存在的问题在于：

读写Session数据引入网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，但是通信发生在内网，则问题不大。

如果集中存储Session的机器或集群出现问题，则会影响应用。

48.什么是Cookie Based Session?

Cookie Based方案是将Session数据放在Cookie里，访问Web服务器的时候，再由Web服务器生成对应的Session数据，如下图所示。

但是Cookie Based方案依然存在不足：

Cookie长度的限制。这会导致Session长度的限制。

安全性。Session数据本来是服务端数据，却被保存在了客户端，即使可以加密，但是依然存在不安全性。

带宽消耗。这里不是指内部Web服务器之间的带宽消耗，而是数据中心的整体外部带宽的消耗。

性能影响。每次HTTP请求和响应都带有Session数据，对Web服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发就会越高。

49.什么是JWT？使用JWT的流程？对比传统的会话有啥区别？

JSON Web Token，一般用它来替换掉Session实现数据共享。

使用基于Token的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

1.客户端通过用户名和密码登录服务器；

2.服务端对客户端身份进行验证；

3.服务端对该用户生成Token，返回给客户端；

4.客户端将Token保存到本地浏览器，一般保存到cookie中

5.客户端发起请求，需要携带该Token；

6.服务端收到请求后买寿险验证Token，之后返回数据。

如上图为Token实现方式，浏览器第一次访问服务器，根据传过来的唯一标识userId,服务端会通过一些算法，如常用的HMAC SHA256算法，然后加一个密钥，生成一个token,然后通过BASE64编码以下之后将这个token发送给客户端；客户端将token保存起来，下次请求时，带着token,服务器收到请求后，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过，返回不通过信息。

可以对比下图session实现方式，流程大致一致。

优点：

无状态，可扩展：在客户端存储的Token是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载均衡器能够将用户信息从一个服务传到其他服务器上。

安全：请求中发送Token而不再是发送Cookie能够防止CSRF（跨站请求伪造）。

可提供接口给第三方服务：使用Token时，可以提供可选的权限给第三方应用程序。

多平台跨域

对应用程序和服务进行扩展的时候，需要介入各种的设备和应用程序。假如我们的后端api服务器a.com只提供数据，而静态资源则存放在cdn服务器b.com上。当我们从a.com请求b.com下面的资源时，由于触发浏览器的同源策略限制而被阻止。

我们通过CORS（跨域资源共享）标准和token来解决资源共享和安全问题。

举个例子，我们可以设置b.com的响应首部字段为：

50.如何设计一个秒杀系统？

秒杀特点以及思路？

短时间内，大量用户涌入，集中读和写有限的库存。

1.尽量将请求拦截在系统上有（越上游越好）；

2.读多写少的多使用缓存（缓存抗读压力）；

从分层角度理解？

层层拦截，将请求尽量拦截在系统上游，避免将锁冲落到数据库上。

第一层：客户端优化

产品层面，用户点击“查询”后者“购票”后，按钮置灰，机制用户重复提交请求。

JS层面，限制用户在x秒之内只能提交一次请求，比如微信摇一摇抢红包。

基本可以拦截80%的请求。

第二层：站点层面的请求拦截（Nginx层，写流控模块）

怎么防止程序员写for循环调用，有去重依据么？IP？

Cookie ID？.....想复杂了，这类业务都需要登录，用uid即可。在站点层面，对uid进行请求计数和去重，甚至不需要统一存储计数，直接站点层内存储（这样计数会不准，但最简单，比如guava本地缓存）。一个uid，5秒只准通过1个请求，这样又能拦住99%的for循环请求。

对于5秒内的无效请求，统一返回错误提示或者错误页面。

这个方法拦住了写for循环发HTTP请求的程序员，有些高端程序员（黑客）控制了10万个肉鸡，手里面有10万个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照Uid限流拦不住了。

第三层：服务层拦截

方案一：

写请求放到队列中，每次只透有限的写请求到数据层，如果成功了再放下一批，直到库存不够，队列里写请求全部返回“已售完”。

方案二：或采用漏斗机制，只放一倍的流量进来，多余的返回”已售完“，把写压力转换成读压力。

读请求，用cache，redis单机可以抗10万 QPS,用异步线程定时更新缓存里的库存值。

还有提示”模糊化“，比如火车余票查询，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票。

第四层：数据库层

浏览器拦截了80%，站点层拦截了99.9%并做了页面缓存，服务层又做了写请求队列与数据缓存，每次透到数据库层的请求都是可控的。db基本就没有什么压力了，通过自身机制来控制，避免出现超卖。

从架构角度理解？

高性能

动静分离秒杀过程中你是不需要刷新整个页面的，只有时间在不停跳动。这是因为一般都会对大流量的秒杀系统做系统的静态化改造，即数据意义上的动静分离。动静分离三步走：

1.数据拆分

2.静态缓存

3.数据整合

热点优化：

数据的热点优化与动静分离是不一样的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性的处理。热点识别和隔离不仅对”秒杀“这个场景有意义，对其他的高性能分布式系统也非常有参考价值。

系统优化

减少序列化：

减少Java中的序列化操作可以很好的提升系统性能。序列化大部分是在RPC阶段发生，因此应该尽量减少RPC调用，一种可行方案是将多个关联性较强的应用进行“合并部署”，从而减少不同应用之间的RPC调用（微服务设计规范）

直接输出流数据：只要涉及字符串的I/O操作，无论是磁盘I/O还是网络I/O，都比较耗费CPU资源，因为字符需要转换成字节，而这个转换又必须查表编码。所以对于常用数据，比如静态字符串，推荐提前编码成字节并缓存，具体到代码层面就是通过OutputStream()类函数从而减少数据的编码转换；另外，热点方法toString()不要直接调用ReflectionToString实现，推荐直接硬编码，并且只打印DO的基础要素和核心要素。

裁剪日志异常堆栈：无论是外部系统异常还是应用本身异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会家具系统当前负载。可以通过日志配置文件控制异常堆栈输出的深度。

去组件矿建：极致优化要求下，可以去调一些组件框架，比如去掉传统的MVC框架，直接使用Servlet处理请求。这样可以绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，当然，需要合理评估你对框架的依赖程度

高可用

流量削峰

1.答题：答题目前已经使用的非常普遍了，本质是通过在入口层削减流量，从而让系统更好的支撑瞬时峰值。

2MQ：最为常见的削峰方式是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲时流量。

3.过滤

Plan B:为了保证系统的高可用，必须设计一个Plan B方案来进行兜底。