开放平台资源的使用需要考虑防刷
短信验证码服务属于开放性服务，由用户侧触发，且因为是注册验证码所以不需要登录就可以使用,很容易被短信轰炸平台利用
@GetMapping("wrong")
public void wrong() {
sendSMSCaptcha("13600000000");
}
private void sendSMSCaptcha(String mobile) {
//调用短信通道
}对于短信验证码这种开放接口，程序逻辑内需要有防刷逻辑。
1. 控制相同手机号的发送次数和发送频次:
限制同一手机号每天的最大请求次数, 频率
2. 增加前置图形验证码:
短信轰炸平台一般会收集很多免费短信接口，一个接口只会给一个用户发一次短信，所以控制相同手机号发送次数和间隔的方式不够有效, 即将弹出图形验证码作为前置
虚拟资产并不能凭空产生无限使用
虚拟资产虽然是平台方自己生产和控制，但如果生产出来可以立即使用就有立即变现。比如，因为平台 Bug 有大量用户领取高额优惠券，并立即下单使用。
在商家看来，这很可能只是一个用户支付的订单，并不会感知到用户使用平台方优惠券的情况；同时，因为平台和商家是事后结算的，所以会马上安排发货。而发货后基本就不可逆了，一夜之间造成了大量资金损失。
我们从代码层面模拟一个优惠券被刷的例子。
假设有一个 CouponCenter 类负责优惠券的产生和发放。如下是错误做法，只要调用方需要，就可以凭空产生无限的优惠券：
@Slf4j
public class CouponCenter {
//用于统计发了多少优惠券
AtomicInteger totalSent = new AtomicInteger(0);
public void sendCoupon(Coupon coupon) {
if (coupon != null)
totalSent.incrementAndGet();
}
public int getTotalSentCoupon() {
return totalSent.get();
}
//没有任何限制，来多少请求生成多少优惠券
public Coupon generateCouponWrong(long userId, BigDecimal amount) {
return new Coupon(userId, amount);
}
}这样一来，使用 CouponCenter 的 generateCouponWrong 方法，想发多少优惠券就可以发多少：
@GetMapping("wrong")
public int wrong() {
CouponCenter couponCenter = new CouponCenter();
//发送10000个优惠券
IntStream.rangeClosed(1, 10000).forEach(i -> {
Coupon coupon = couponCenter.generateCouponWrong(1L, new BigDecimal("100"));
couponCenter.sendCoupon(coupon);
});
return couponCenter.getTotalSentCoupon();
}更合适的做法是，把优惠券看作一种资源，其生产不是凭空的，而是需要事先申请
接下来，我们按照这个思路改进一下程序。
首先，定义一个 CouponBatch 类，要产生优惠券必须先向运营申请优惠券批次，批次中包含了固定张数的优惠券、申请原因等信息：
//优惠券批次
@Data
public class CouponBatch {
private long id;
private AtomicInteger totalCount;
private AtomicInteger remainCount;
private BigDecimal amount;
private String reason;
}在业务需要发放优惠券的时候，先申请批次，然后再通过批次发放优惠券：
@GetMapping("right")
public int right() {
CouponCenter couponCenter = new CouponCenter();
//申请批次
CouponBatch couponBatch = couponCenter.generateCouponBatch();
IntStream.rangeClosed(1, 10000).forEach(i -> {
Coupon coupon = couponCenter.generateCouponRight(1L, couponBatch);
//发放优惠券
couponCenter.sendCoupon(coupon);
});
return couponCenter.getTotalSentCoupon();
}可以看到，generateCouponBatch 方法申请批次时，设定了这个批次包含 100 张优惠券。在通过 generateCouponRight 方法发放优惠券时，每发一次都会从批次中扣除一张优惠券，发完了就没有了：
public Coupon generateCouponRight(long userId, CouponBatch couponBatch) {
if (couponBatch.getRemainCount().decrementAndGet() >= 0) {
return new Coupon(userId, couponBatch.getAmount());
} else {
log.info("优惠券批次 {} 剩余优惠券不足", couponBatch.getId());
return null;
}
}
public CouponBatch generateCouponBatch() {
CouponBatch couponBatch = new CouponBatch();
couponBatch.setAmount(new BigDecimal("100"));
couponBatch.setId(1L);
couponBatch.setTotalCount(new AtomicInteger(100));
couponBatch.setRemainCount(couponBatch.getTotalCount());
couponBatch.setReason("XXX活动");
return couponBatch;
}这样改进后的程序，一个批次最多只能发放 100 张优惠券：在通过 generateCouponRight 方法发放优惠券时，每发一次都会从批次中扣除一张优惠券，发完了就没有了
钱的进出一定要和订单挂钩并且实现幂等
涉及钱的进出，需要做好以下两点。
第一，任何资金操作都需要在平台侧生成业务属性的订单，可以是优惠券发放订单，可以是返现订单，也可以是借款订单，一定是先有订单再去做资金操作。
第二，一定要做好防重，也就是实现幂等处理，并且幂等处理必须是全链路的。这里的全链路是指，从前到后都需要有相同的业务订单号来贯穿，实现最终的支付防重。
关于这两点，你可以参考下面的代码示例：
//错误：每次使用UUID作为订单号
@GetMapping("wrong")
public void wrong(@RequestParam("orderId") String orderId) {
PayChannel.pay(UUID.randomUUID().toString(), "123", new BigDecimal("100"));
}
//正确：使用相同的业务订单号
@GetMapping("right")
public void right(@RequestParam("orderId") String orderId) {
PayChannel.pay(orderId, "123", new BigDecimal("100"));
}
//三方支付通道
public class PayChannel {
public static void pay(String orderId, String account, BigDecimal amount) {
...
}
}对于支付操作，我们一定是调用三方支付公司的接口或银行接口进行处理的。一般而言，这些接口都会有商户订单号的概念，对于相同的商户订单号，无法进行重复的资金处理，所以三方公司的接口可以实现唯一订单号的幂等处理。
但是，业务系统在实现资金操作时容易犯的错是，没有自始至终地使用一个订单号作为商户订单号，透传给三方支付接口。出现这个问题的原因是，比较大的互联网公司一般会把支付独立一个部门。支付部门可能会针对支付做聚合操作，内部会维护一个支付订单号，然后使用支付订单号和三方支付接口交互。最终虽然商品订单是一个，但支付订单是多个，相同的商品订单因为产生多个支付订单导致多次支付。
如果说，支付出现了重复扣款，我们可以给用户进行退款操作，但给用户付款的操作一旦出现重复付款，就很难把钱追回来了，所以更要小心。
这，就是全链路的意义，从一开始就需要先有业务订单产生，然后使用相同的业务订单号一直贯穿到最后的资金通路，才能真正避免重复资金操作。
重点回顾
第一，使用开放的、面向用户的平台资源要考虑防刷，主要包括正常使用流程识别、人机识别、单人限量和全局限量等手段。
第二，虚拟资产不能凭空产生，一定是先有发放计划、申请批次，然后通过批次来生产资产。这样才能达到限量、有审计、能追溯的目的。文章来源：https://www.toymoban.com/news/detail-802755.html
第三，真实钱的进出操作要额外小心，做好防重处理。不能凭空去操作用户的账户，每次操作以真实的订单作为依据，通过业务订单号实现全链路的幂等控制。如果程序逻辑涉及有价值的资源或是真实的钱，我们必须有敬畏之心。程序上线后，人是有休息时间的，但程序是一直运行着的，如果产生安全漏洞，就很可能在一夜之间爆发，被大量人利用导致大量的金钱损失。文章来源地址https://www.toymoban.com/news/detail-802755.html
到了这里，关于安全兜底：涉及钱时短信必须考虑防刷、限量和防重的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
