2021-01-13 字节一面+百度一面

1.分布式相关问题

https://www.cnblogs.com/xuwc/p/9139164.html

https://www.cnblogs.com/xuwc/p/9152236.html


2.分布式如何保证幂等性

所谓幂等性,指的是系统A对系统B的接口进行多次调用所产生的结果和调用一次所产生的结果是一致的。

1.1 数学定义

在数学里,幂等有两种主要的定义:

在某二元运算下,幂等元素是指被自己重复运算(或对于函数是为复合)的结果等于它自己的元素。例如,乘法下唯一两个幂等实数为0和1。 即 s *s = s
某一元运算为幂等的时,其作用在任一元素两次后会和其作用一次的结果相同。例如,高斯符号便是幂等的,即f(f(x)) = f(x)。

1.2 HTTP规范的定义

在HTTP/1.1规范中幂等性的定义是:

如果一个请求方法在服务器上多次执行的预期影响与它只执行一次相同,那么这个请求方法就被认为具有幂等性。在此规范中,PUT、DELETE和安全method( GET, HEAD,OPTIONS, TRACE)都是幂等的。
HTTP的幂等性指的是一次和多次请求某一个资源应该具有相同的副作用。如通过PUT接口将数据的Status置为1,无论是第一次执行还是多次执行,获取到的结果应该是相同的,即执行完成之后Status =1。

2.在HTTP规范中定义GET,PUT和DELETE方法应该具有幂等性:

  1. GET方法是向服务器查询,不会对系统产生副作用,具有幂等性(不代表每次请求都是相同的结果)
  2. PUT方法首先判断系统中是否有相关的记录,如果有记录则更新该记录,如果没有则新增记录。
  3. DELETE方法是删除服务器上的相关记录。

3.分布式系统接口幂等性
随着分布式系统及微服务的普及,因为网络原因而导致调用系统未能获取到确切的结果从而导致重试,这就需要被调用系统具有幂等性。 例如上文所阐述的支付系统,针对同一个订单保证支付的幂等性,一旦订单的支付状态确定之后,以后的操作都会返回相同的结果,对用户的扣款也只会有一次。

4.技术方案

  1. 查询操作:查询一次和查询多次,在数据不变的情况下,查询结果是一样的。select是天然的幂等操作;
  2. 删除操作:删除操作也是幂等的,删除一次和多次删除都是把数据删除。(注意可能返回结果不一样,删除的数据不存在,返回0,删除的数据多条,返回结果多个) ;
  3. 唯一索引,防止新增脏数据。比如:支付宝的资金账户,支付宝也有用户账户,每个用户只能有一个资金账户,怎么防止给用户创建资金账户多个,那么给资金账户表中的用户ID加唯一索引,所以一个用户新增成功一个资金账户记录。要点:唯一索引或唯一组合索引来防止新增数据存在脏数据(当表存在唯一索引,并发时新增报错时,再查询一次就可以了,数据应该已经存在了,返回结果即可);
  4. token机制,防止页面重复提交。业务要求: 页面的数据只能被点击提交一次;发生原因: 由于重复点击或者网络重发,或者nginx重发等情况会导致数据被重复提交;解决办法: 集群环境采用token加redis(redis单线程的,处理需要排队);单JVM环境:采用token加redis或token加jvm内存。处理流程:1. 数据提交前要向服务的申请token,token放到redis或jvm内存,token有效时间;2. 提交后后台校验token,同时删除token,生成新的token返回。token特点:要申请,一次有效性,可以限流。注意:redis要用删除操作来判断token,删除成功代表token校验通过,如果用select+delete来校验token,存在并发问题,不建议使用;
  5. 悲观锁——获取数据的时候加锁获取。select * from table_xxx where id=‘xxx’ for update; 注意:id字段一定是主键或者唯一索引,不然是锁表,会死人的悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会很长,根据实际情况选用;
  6. 乐观锁——乐观锁只是在更新数据那一刻锁表,其他时间不锁表,所以相对于悲观锁,效率更高。

注意:乐观锁的更新操作,最好用主键或者唯一索引来更新,这样是行锁,否则更新时会锁表,上面两个sql改成下面的两个更好

  1. 分布式锁——还是拿插入数据的例子,如果是分布是系统,构建全局唯一索引比较困难,例如唯一性的字段没法确定,这时候可以引入分布式锁,通过第三方的系统(redis或zookeeper),在业务系统插入数据或者更新数据,获取分布式锁,然后做操作,之后释放锁,这样其实是把多线程并发的锁的思路,引入多多个系统,也就是分布式系统中得解决思路。要点:某个长流程处理过程要求不能并发执行,可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁,其他流程执行时获取锁就会失败,也就是同一时间该流程只能有一个能执行成功,执行完成后,释放分布式锁(分布式锁要第三方系统提供);

  2. select + insert——并发不高的后台系统,或者一些任务JOB,为了支持幂等,支持重复执行,简单的处理方法是,先查询下一些关键数据,判断是否已经执行过,在进行业务处理,就可以了。注意:核心高并发流程不要用这种方法;

  3. 状态机幂等——在设计单据相关的业务,或者是任务相关的业务,肯定会涉及到状态机(状态变更图),就是业务单据上面有个状态,状态在不同的情况下会发生变更,一般情况下存在有限状态机,这时候,如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。注意:订单等单据类业务,存在很长的状态流转,一定要深刻理解状态机,对业务系统设计能力提高有很大帮助

  4. 对外提供接口的api如何保证幂等。如银联提供的付款接口:需要接入商户提交付款请求时附带:source来源,seq序列号, source+seq在数据库里面做唯一索引,防止多次付款(并发时,只能处理一个请求) 。重点:对外提供接口为了支持幂等调用,接口有两个字段必须传,一个是来源source,一个是来源方序列号seq,这个两个字段在提供方系统里面做联合唯一索引,这样当第三方调用时,先在本方系统里面查询一下,是否已经处理过,返回相应处理结果;没有处理过,进行相应处理,返回结果。注意,为了幂等友好,一定要先查询一下,是否处理过该笔业务,不查询直接插入业务系统,会报错,但实际已经处理了。

https://blog.csdn.net/u011635492/article/details/81058153?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.control


3.CAP是什么,如何保证

CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。

一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
可用性(A):保证每个请求不管成功或者失败都有响应。
分区容忍性(P):系统中任意信息的丢失或失败不会影响系统的继续运作。

https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99/5712863?fr=aladdin


4.golang基本数据类型的底层实现,内存分配,调度

golang基本数据类型的底层实现

golang内存分配机制

golang调度模型


5.分布式中的一致性问题

https://www.cnblogs.com/takumicx/p/10021538.html


6.微服务相关问题

https://www.cnblogs.com/yazid/p/12214383.html


8.什么是测试?

一般来说,分为以下好几步:需求评审、制定测试计划、测试用例设计、测试用例评审、冒烟测试、一轮测试、N轮测试、回归测试、撰写文档。

https://www.boxuegu.com/news/1260.html


9.常见的自动化测试框架和测试工具

自动化测试的目的是为了一定程度上的解放人工测试,提高测试的效率,避免人工反复进行同样的操作测试。

https://www.cnblogs.com/ustcinfo-qc/p/12124174.html


10.网站反爬协议?

Robots协议
网站开发者对于网络爬虫的规范的公告,你可以不遵守可能存在法律风险,但尽量去遵守

Robots协议:在网页的根目录+/robots.txt 如www.baidu.com/robots.txt

https://www.cnblogs.com/baohanblog/p/12664184.html

猜你喜欢

转载自blog.csdn.net/weixin_43202635/article/details/112689849