架构

1、接口幂等性的实现方式

2、如何避免下重复订单

1、当进入商品详情页时，去生成一个全局唯一ID（可用雪花算法）；
2、将这个全局唯一ID和订单信息传给服务器；
3、判断这个ID对应的订单号存在，则直接返回；
4、生成订单号，保存订单信息；
更多请查看如何避免下重复订单

3、如何实现下订单后一个小时后未付款的订单自动取消

为了避免轮询并且在服务端主动取消订单，可以使用类似于消息队列的方式，比如 redis 的 pub/sub 服务。

1、DelayQueue 延时队列，此队列放入的数据需要实现java.util.concurrent.Delayed接口，用户存放待取消订单
2、redis 分布式缓存，用于存放待取消订单，数据可以长久存放，不受服务启停影响
3、监听器，监听某一事件，执行一定的逻辑

4、三高：高并发、高性能、高可用

一. 高并发

高并发是现在互联网分布式框架设计必须要考虑的因素之一，它是可以保证系统能被同时并行处理很多请求，对于高并发来说，它的指标有：

响应时间：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间。
吞吐量：吞吐量是指每秒能处理多少请求数量，好比你吃饭，每秒能吃下多少颗米饭。
秒查询率：秒查询率是指每秒响应请求数，和吞吐量差不多。
并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

二. 高性能

什么是高性能呢？高性能是指程序处理速度非常快，所占内存少，cpu占用率低。高性能的指标经常和高并发的指标紧密相关，想要提高性能，那么就要提高系统发并发能力，两者互相捆绑在一起。应用性能优化的时候，对于计算密集型和IO密集型还是有很大差别，需要分开来考虑。还有可以增加服务器的数量，内存，IO等参数提升系统的并发能力和性能，但不要浪费资源，要考虑硬件的使用率最高才能发挥到极致。

怎么样提高性能呢？

避免因为IO阻塞让CPU闲置，导致CPU的浪费
避免多线程间增加锁来保证同步，导致并行系统串行化
避免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上

三. 高可用

高可用通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。高可用注意如果使用单机，一旦挂机将导致服务不可用，可以使用集群来代替单机，一台服务器挂了，还有其他后备服务器能够顶上。或者使用分布式部署项。比如现在redis的高可用的集群方案有： Redis单副本，Redis多副本（主从），Redis Sentinel（哨兵），Redis Cluster，Redis自研。

5、如何进行系统拆分？

可以从纵向和横向来拆分：

纵向拆分：从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
横向拆分：从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

1、单一职责、高内聚低耦合;
2、服务粒度适中;
3、考虑团队结构:（康威定律：设计系统的组织其产生系统的设计和架构等价于组织间的沟通结构。就是指每个团队开发设计和测试发布自己团队的微服务时，要互不干扰系统效率才能得到提升，）
4、以业务模型切入:（领域模型：对具体某个边界领域的抽象，反应了领域内用户业务需求的本质。领域模型只反应业务与任何技术是现实没有关系的，不仅反应领域间的实体概念还能反应领域间的过程概念）
5、演进式的拆分;
6、避免环形依赖与双向依赖:（如：商品服务于订单服务相互依赖）

6、令牌桶和漏桶使用场景？

记住一条，令牌桶会比漏桶更优就行了，99%选用令牌桶。如果请求产生的速率恒定，令牌桶和漏桶效果一样。如果请求分布不均匀，令牌桶比漏桶好。

7、如何设计一个接口？

接口设计需要考虑哪些方面

1.接口的命名。
2.请求参数。
3.支持的协议。
4.TPS、并发数、响应时长。
5.数据存储。DB选型、缓存选型。
6.是否需要依赖于第三方。
7.接口是否拆分。
8.接口是否需要幂等。
9.防刷。
10.接口限流、降级。
11.负载均衡器支持。
12.如何部署。
13.是否需要服务治理。
14.是否存在单点。
15.接口是否资源包、预加载还是内置。
16.是否需要本地缓存。
17.是否需要分布式缓存、缓存穿透怎么办。
18.是否需要白名单。

接口设计原则
原则一：必须符合Restful，统一返回格式，约定业务层错误编码，每个编码可以携带可选的错误信息。
原则二：命名必须规范、优雅。
原则三：单一性。
单一性是指接口要做的事情应该是一个比较单一的事情，比如登陆接口，登陆完成应该只是返回登陆成功以后一些用户信息即可，但很多人为了减少接口交互，返回一大堆额外的数据。
原则四：可扩展。
原则五：必须有文档。
原则六：产品心。
原则七：第三方服务接口数据能缓存就缓存。
原则八：第三方服务需要做降级。
原则九：建议消除单点。
原则十：接口粒度要小。
原则十一：客户端能处理的逻辑就不要给服务端处理，减少服务端压力。
原则十二：资源预加载。
原则十三：不要过度设计。
原则十四：缓存尽量不要穿透。
原则十五：接口能缓存就缓存。
原则十六：思辨大于执行

8、日志框架

image.png

9、一次完整的HTTP请求过程

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户。

10、网站统计IP PV UV实现原理

PV(访问量)：Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
UV(独立访客)：Unique Visitor,一般使用cookie标记,访问您网站的一台电脑客户端(比如一台电脑开多个浏览器访问则为多个UV)为一个访客，00:00-24:00内相同的客户端只会被计算一次。
IP(独立IP)：指独立IP数。00:00-24:00内相同IP地址之被计算一次(多台电脑可能共用一个ip)。

ip、pv、uv的区别：

IP(独立IP)：某IP地址的计算机访问网站的次数。这种统计方式很容易实现，具有真实性。所以是衡量网站流量的重要指标。
PV(访问量)：PV反映的是浏览某网站的页面数，所以每刷新一次也算一次。就是说PV与来访者的数量成正比，但PV并不是页面的来访者数量，而是网站被访问的页面数量。
UV(独立访客)：可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。如果更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数是不变的。

工作流程：

1、编写监控javascript和提供接口。这个接口返回的是监控网站对应的javascript文件，这个文件可以再客户端可以标记和采集访客的信息。
2、网站调用接口。只需将引入javascript到要监控的站点即可，访客访问该站点时，javascript文件就会被加载。
3、标记和采集数据。监控js被加载后就会往浏览器写入cookie标记访客，比如新访客生产一个新cookie和标记访问次数，若是老用户则，读取 cookie信息，计算访问次数和最后访问时间等，这些客户端的信息处理完后，则向指定的服务器发送数据。
4、最后服务器接收javascript提交过来的数据处理入库和后续的数据处理了。

11、如何去设计分布式监控中心？

监控中心最基本四个功能：

数据采集
实时绘图
告警
数据存储

大概原理：

监控中心的agent需要安装到被监控的主机上，它负责定期收集各项数据，并发送到监控中心server，监控中心server将数据存储到数据库，监控中心web在前端进行绘图。

agent收集数据分为主动和被动两种模式：

主动：agent请求server获取主动的监控项列表，并主动将监控项内需要检测的数据提交给server/proxy
server向agent请求获取监控项的数据，agent返回数据。

一般需要监控哪些数据：

可以自己埋点获取监控信息
代码运行时间统计、次数、错误次数
服务器系统信息、JVM 内存/GC信息、线程信息
SQL语句执行时长
各个进程的CPU和内存使用情况

现在市面比较流行的监控组件：
按照功能划分：