保持思考，保持清醒
1、Git的分支你们是怎么管理的？
2、接口保证幂等性是基本的要求，那么幂等性你们是怎么做的?
3、你们有用@Transactional来控制事务是吧，那么能不能说出一些事务不生效的场景？
- Git的分支你们是怎么管理的？
-
首先要阐述Git是什么，为什么我们开发需要引入git
-- 项目版本管理工具，版本的控制体现在一个个分支上的开发 -
阐述你们开发分支的管理流程
-- 不同环境方面（固定几种环境主分支ret、uat、sit、dev）
-- 根据cq单或者人员名称去拉取基于某种环境主分支的代码，创建一个新的分支，在这个分支上开发
-- 开发人员没有merge主分支的权限，commit备注规范等
- 接口保证幂等性是基本的要求，那么幂等性你们是怎么做的?
-- 首先阐述什么是幂等性，对其理解
幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的。eg. getUserName()
所以说并不是每个接口都要考虑它的幂等性问题，因为查询和删除就具备天然的幂等性，查询多次和查询一次结果是一样（除非有数据表更新）；删除一次和删除多次效果是一样的（只是返回条数不一样而已），只有insert、update或者一些复合操作要考虑幂等性问题。
-- 结合你们业务场景来聊
1、短信推送，第三方重复推送问题（创建唯一索引）
考虑推送记录表的唯一性数据，添加唯一索引或者组合索引来限制数据的唯一性，一次推送和重复推送都不会产生脏数据
2、前端控制重复提交源头（token机制：防止页面重复提交）
提交时创建一个随机数token，存放到session中，提交给服务器，
服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。
3、select + insert
并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了。注意：核心高并发流程不要用这种方法；
4、分布式锁
token 机制处理 接口幂等性问题，这种方式一个问题对代码的入侵比较多，相对书写代码来讲就比较麻烦，可以使用 redis 分布式锁机制解决接口幂等性问题：
https://www.jianshu.com/p/fbedd907a48a#!/xh
5、状态机幂等
这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为100，付款失败为99
https://blog.csdn.net/uxiad7442kmy1x86dtm3/article/details/88968532
6、外提供接口的api如何保证幂等
对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。
- 你们有用@Transactional来控制事务是吧，那么能不能说出一些事务不生效的场景？
https://www.cnblogs.com/codingmengmeng/p/12111392.html
网友评论