那时刻
2020-05-211.对于防重，防刷。可以通过数据监控来实现类似熔断机制，比如数据监控某个功能在被刷，触发报警，同时熔断，暂时把该功能禁掉，减少损失。 2.想到一种情况，我们系统对于第三方调用返回值处理不当，导致有重复调用，也就是我们系统防重没有做好。作者回复: 问题二，之前遇到的情况是，在事务内调用外部接口，调用超时后事务回滚本地就没有留下数据，对账的时候要对两边，不管哪方数据缺失都可能是因为有bug需要重视
共 4 条评论23
👽2020-05-25安全兜底 的问题，我的理解是分级别。 我的初步分级是 1，无限额涉及钱的问题（类似于退款），2，限额设计钱的问题（为用户提供的红包奖励等，这部分钱通常有限额） 3，无门槛虚拟货币（无门槛优惠券，无门槛积分等，因为这部分基本与货币可以等值，但是由于存在可以追回的机会，所以尚存一些容错） 4，有门槛虚拟货币（这部分，基本上，因为其目的就是促销，并不会带来实质上的经济损失，所以就并没有那么敏感了） 分级之后，再进一步划分处理的级别。因为人力和时间都是有限的，很难将所有的安全兜底都控制的那么完美，那就优先保证一些损失影响可能较大的业务上。 权重更高的业务，可以予以更严谨的测试，以及附加的人工审核机制，更频繁的监控等。相对权重较低的，就可能重视程度不那么高，仅保留较低限度的兜底。作者回复: 分析的不错
共 2 条评论18- 👽2020-05-25对于，我方调用记录和对方调用记录不符，个人认知，假设，对方系统记录是正确的。 我猜测的点：我调用对方，对方存了，我没存。或者请求重发了，但是我方仅保存了一次。 首先需要通过日志来看。调用前日志，调用后结果日志，以及重发日志。综合来看自己请求是否存在问题。 甚至，中间部分时候，己方的服务器挂掉了，也会形成记录不一致的问题。 个人思路，以日志为切入点解决问题。
作者回复: 所有涉及到三方服务的交互，我建议request和response全部记录到（NOSQL）数据库中
共 2 条评论12 
20192020-08-28调用第三方服务进行支付金币，我们的做法是不管支付成不成功都把数据放入本方数据库，只不过增加一个状态字段来判断是否支付成功。如果支付成功一定是接口三方返回成功，如果失败有可能三方服务有问题或者网络问题。支付失败的情况，给用户友好提示，让用户再次支付，由于三方支付是幂等的，用上次调用的业务号直接支付，支付成功就修改状态。这样两方进行对账不会产生重复入账的情况。作者回复: 没错，先落地，再调三方
10
大胖子呀、2020-05-21最近正好要做小程序发放红包的功能，学习了，后面实施的时候一定要注意。 第一次回答下问题，经验不足，有错误之处还请指出。 问题一：如果系统正在被攻击的话，应该会出现几种异常情况，比如短时间内会有大量资金流出（涉及金额实时扣除的）、同一个用户短时间内有大量的数据重复，等等。系统可以根据具体业务情况，针对可能出现的异常情况进行监控，如果出现的话及时预警。 问题二：可能是因为调用第三方接口成功了，但是存入自己系统数据库出现错误，没有及时发现处理，造成了数据丢失，有可能就会导致这种情况。作者回复: 问题一，的确监控是较好的手段，关键在于报警阈值怎么设置，我觉得可以对比昨天同时，上周同时的量，发现差异达到一定百分比报警。此外，对于活动可以申请单独的活动监控标签，单独呈现曲线，做好量的预估，超量报警，有的时候大盘很大的话活动给整个大盘带来的变化不明显。
5
郑思雨2020-12-21说到安全手段，最先想到的是校验+对账。 校验要注意的一点是 对业务case的穷举，在业务流程比较复杂的情况，需要多考虑边界情况，比如两条指令共同决定一个行为，那么两条指令的先后顺序、两条指令同时到达的校验有很大的差异。 而对账更多的是及时发现问题，及时止损。公司内部可以做准实时对账，与外部平台有对接时，只能做成T+1的，实时性差，发现问题也就更晚。 举2个例子： 用户提现时需要传递 token 和 账户ID，这时我们就可以做一个 token 和 账户ID关系的校验，看看token对应的User 和 账户ID 是否能对应上，防止攻击者用一个token 提现多个账户的余额。毕竟获取多个token比获取多个账户ID要困难很多。（这个例子是一个用户可以有多个账户的设计） 账户出金的安全性：可以通过设计来规避问题，比如 设计 冻结、解冻 等功能。作者回复: 安全方面设计上的确可以考虑很多：双向对账、多步流程整体考虑安全校验、兜底策略、防止外部猜测业务逻辑、不但在内部校验通过外部再实现一套业务逻辑实现校验、设定业务策略常识作为底线
2
睁眼看世界2020-05-29老师，请教下，全链路幂等处理的话，如果是web请求，除了前端防抖的话，后端可以如何处理？作者回复: 其实幂等考虑2方面： 1、幂等依据，可以是每次交互生成的token，可以是客户端的序列号，可以是有意义的业务订单号 2、根据幂等依据进行防重处理： 1）限制：比如锁方式、状态机控制 2）去重方式
1
玩帆船的东郭君2023-03-17 来自江苏课程买了挺久，今天才看。说到限量、防重复，以我之前在国内某top金融公司5年开发经验谈，实际的金融风控规则，更加细腻。限量：我的账户里面只有100块钱，那么客户的贷款金额或者取数金额就不能高于这个钱。系统的利息计算批处理，产生的利息不能大于本金，财务系统每支出的一笔钱需要与业务系统的业务数据，对应上等 防重复：有些财务系统，对中间件的可信度还是持有怀疑，最终还是采用数据库一笔交易，唯一 一笔流水号进行定义。1