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