标签：索引 获取 分配 需求 需要 原因 接口 不一致 bsp
1、异步处理时防止重复点击的逻辑校验
场景 打款请求时，进入异步处理的队列，生成一个任务号，存在如数据库，且状态为未完成。此时，如果并发操作，如重复点击或者重复调用接口，则发出的两条请求可能被分配到不同服务器处理，此时数据库产生两条数据，同一任务id对应不同进程id，属于异常场景。程序逻辑判断数据>2，不处理，则异步任务终止。
其中，重复点击导致产生两条数据的原因仅为猜测，实际排查过程中发现，前端已经做了防重复点击，可能是后端的前置逻辑导致对同一批数据做两次请求
总结 不仅在同步业务处理时需要注意并发问题，异步任务时也需要根据实现逻辑关注中间状态
解决 1、数据库加联合唯一索引，第二条数据写不进去，直接将数据库报错抛出
2、忽略两天数据的场景，当做正常业务处理，两条都进行更新
3、 排查产生两条数据的原因，源头上杜绝
最终方案选择了2 当时我选择的是1和3,1作为立即解决的方案，在不动业务逻辑的场景下，解决问题，风险较小。3作为后续的溯源很有必要。但是最后没争过开发
2、临时小需求对系统功能的影响，需要思考后再做回归
eg.列表新增字段的需求，需要新增一个时间标签。当做一个简单的回归时正常。但是这个列表中有三个写入的业务类型，其中一个写入类型与其他写入的函数不同。此时，由于未对第三个业务类型进行回归，导致漏测。这也是为什么测试需要参与设计评审的原因。
分析：正常的业务场景和实现方式来说，基于复用原则，和通用的代码实现方式，这种写入应该都是在同一个函数完成。但是防不胜防啊。需求急测试不能急，任何小的修改都可能对你之前的测试结果形成覆盖
3、客户端测试时，需要注意系统与原生兼容和交互，如获取权限，打开文件等
4、前后端交互问题，前端页面展示错误、请求参数错误、交互错误这种类型的bug咱就不提了。主要说一种，请求的同步和异步，也就是时间对请求结果的影响，和前端在处理请求结果时，是否会基于时间的考虑来展示返回结果。
先来个简单的例子，在某修改功能中，要求前端请求后进行查询，以便在列表展示上获取刚才的修改提交。此时，先发出修改请求，再发出查询请求，如果修改请求仍在处理，还没有成功，便返回查询结果，然后返回修改结果，修改成功。此时就造成了展示内容与实际结果不一致。所以查询接口应该等待修改接口返回结果后再发出
前后端交互中也存在同步异步问题。同步就是上面的例子。下面是前后端交互的两种异步场景。
a、轮询（polling） 间隔一定时间不断向后端发送请求，如导出功能，第一次请求导出时，后端给到一个任务id，然后前端拿着这个id每隔1秒请求一次。确定就是消耗大，有延迟。延迟问题可以通过长轮询方式解决，具体自行扩展
b、websocket是跟http一样性质的传输协议。详细区别自己找找，这里就谈一个，http是单向的，websocket是双向的协议。所以很明了，websocket 协议中，服务器端会主动向浏览器端发送结果，进而可以降低延迟。缺点就是资源消耗大。所以在生命周期结束时，应该关闭连接
标签：索引 获取 分配 需求 需要 原因 接口 不一致 bsp
原文地址：https://www.cnblogs.com/olio1993/p/11962931.html
