Java业务开发常见错误100例
朱晔
贝壳金服资深架构师
立即订阅
6044 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 业务代码真的会有这么多坑?
免费
代码篇 (20讲)
01 | 使用了并发工具类库,线程安全就高枕无忧了吗?
02 | 代码加锁:不要让“锁”事成为烦心事
03 | 线程池:业务代码最常用也最容易犯错的组件
04 | 连接池:别让连接池帮了倒忙
05 | HTTP调用:你考虑到超时、重试、并发了吗?
06 | 20%的业务代码的Spring声明式事务,可能都没处理正确
07 | 数据库索引:索引并不是万能药
08 | 判等问题:程序里如何确定你就是你?
09 | 数值计算:注意精度、舍入和溢出问题
10 | 集合类:坑满地的List列表操作
11 | 空值处理:分不清楚的null和恼人的空指针
12 | 异常处理:别让自己在出问题的时候变为瞎子
13 | 日志:日志记录真没你想象的那么简单
14 | 文件IO:实现高效正确的文件读写并非易事
15 | 序列化:一来一回你还是原来的你吗?
16 | 用好Java 8的日期时间类,少踩一些“老三样”的坑
17 | 别以为“自动挡”就不可能出现OOM
18 | 当反射、注解和泛型遇到OOP时,会有哪些坑?
19 | Spring框架:IoC和AOP是扩展的核心
20 | Spring框架:框架帮我们做了很多工作也带来了复杂度
设计篇 (6讲)
21 | 代码重复:搞定代码重复的三个绝招
22 | 接口设计:系统间对话的语言,一定要统一
23 | 缓存设计:缓存可以锦上添花也可以落井下石
24 | 业务代码写完,就意味着生产就绪了?
25 | 异步处理好用,但非常容易用错
26 | 数据存储:NoSQL与RDBMS如何取长补短、相辅相成?
安全篇 (4讲)
27 | 数据源头:任何客户端的东西都不可信任
28 | 安全兜底:涉及钱时,必须考虑防刷、限量和防重
29 | 数据和代码:数据就是数据,代码就是代码
30 | 如何正确保存和传输敏感数据?
不定期加餐 (6讲)
加餐1 | 带你吃透课程中Java 8的那些重要知识点(一)
加餐2 | 带你吃透课程中Java 8的那些重要知识点(二)
加餐3 | 定位应用问题,排错套路很重要
加餐4 | 分析定位Java问题,一定要用好这些工具(一)
加餐5 | 分析定位Java问题,一定要用好这些工具(二)
加餐6 | 这15年来,我是如何在工作中学习技术和英语的?
结束语 (2讲)
结束语 | 写代码时,如何才能尽量避免踩坑?
结课测试 | 关于Java业务开发的100个常见错误,你都明白其中缘由了吗?
Java业务开发常见错误100例
15
15
1.0x
00:00/00:00
登录|注册

28 | 安全兜底:涉及钱时,必须考虑防刷、限量和防重

朱晔 2020-05-21
你好,我是朱晔。今天,我要和你分享的主题是,任何涉及钱的代码必须要考虑防刷、限量和防重,要做好安全兜底。
涉及钱的代码,主要有以下三类。
第一,代码本身涉及有偿使用的三方服务。如果因为代码本身缺少授权、用量控制而被利用导致大量调用,势必会消耗大量的钱,给公司造成损失。有些三方服务可能采用后付款方式的结算,出现问题后如果没及时发现,下个月结算时就会收到一笔数额巨大的账单。
第二,代码涉及虚拟资产的发放,比如积分、优惠券等。虽然说虚拟资产不直接对应货币,但一般可以在平台兑换具有真实价值的资产。比如,优惠券可以在下单时使用,积分可以兑换积分商城的商品。所以从某种意义上说,虚拟资产就是具有一定价值的钱,但因为不直接涉及钱和外部资金通道,所以容易产生随意性发放而导致漏洞。
第三,代码涉及真实钱的进出。比如,对用户扣款,如果出现非正常的多次重复扣款,小则用户投诉、用户流失,大则被相关管理机构要求停业整改,影响业务。又比如,给用户发放返现的付款功能,如果出现漏洞造成重复付款,涉及 B 端的可能还好,但涉及 C 端用户的重复付款可能永远无法追回。
前段时间拼多多一夜之间被刷了大量 100 元无门槛优惠券的事情,就是限量和防刷出了问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Java业务开发常见错误100例》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(5)

  • 那时刻
    1.对于防重,防刷。可以通过数据监控来实现类似熔断机制,比如数据监控某个功能在被刷,触发报警,同时熔断,暂时把该功能禁掉,减少损失。
    2.想到一种情况,我们系统对于第三方调用返回值处理不当,导致有重复调用,也就是我们系统防重没有做好。

    作者回复: 问题二,之前遇到的情况是,在事务内调用外部接口,调用超时后事务回滚本地就没有留下数据,对账的时候要对两边,不管哪方数据缺失都可能是因为有bug需要重视

    2020-05-21
    8
  • 👽
    安全兜底 的问题,我的理解是分级别。
    我的初步分级是 1,无限额涉及钱的问题(类似于退款),2,限额设计钱的问题(为用户提供的红包奖励等,这部分钱通常有限额) 3,无门槛虚拟货币(无门槛优惠券,无门槛积分等,因为这部分基本与货币可以等值,但是由于存在可以追回的机会,所以尚存一些容错) 4,有门槛虚拟货币(这部分,基本上,因为其目的就是促销,并不会带来实质上的经济损失,所以就并没有那么敏感了)

    分级之后,再进一步划分处理的级别。因为人力和时间都是有限的,很难将所有的安全兜底都控制的那么完美,那就优先保证一些损失影响可能较大的业务上。

    权重更高的业务,可以予以更严谨的测试,以及附加的人工审核机制,更频繁的监控等。相对权重较低的,就可能重视程度不那么高,仅保留较低限度的兜底。

    作者回复: 分析的不错

    2020-05-25
    4
  • ..
    最近正好要做小程序发放红包的功能,学习了,后面实施的时候一定要注意。

    第一次回答下问题,经验不足,有错误之处还请指出。

    问题一:如果系统正在被攻击的话,应该会出现几种异常情况,比如短时间内会有大量资金流出(涉及金额实时扣除的)、同一个用户短时间内有大量的数据重复,等等。系统可以根据具体业务情况,针对可能出现的异常情况进行监控,如果出现的话及时预警。

    问题二:可能是因为调用第三方接口成功了,但是存入自己系统数据库出现错误,没有及时发现处理,造成了数据丢失,有可能就会导致这种情况。

    作者回复: 问题一,的确监控是较好的手段,关键在于报警阈值怎么设置,我觉得可以对比昨天同时,上周同时的量,发现差异达到一定百分比报警。此外,对于活动可以申请单独的活动监控标签,单独呈现曲线,做好量的预估,超量报警,有的时候大盘很大的话活动给整个大盘带来的变化不明显。

    2020-05-21
    2
  • 👽
    对于,我方调用记录和对方调用记录不符,个人认知,假设,对方系统记录是正确的。
    我猜测的点:我调用对方,对方存了,我没存。或者请求重发了,但是我方仅保存了一次。
    首先需要通过日志来看。调用前日志,调用后结果日志,以及重发日志。综合来看自己请求是否存在问题。
    甚至,中间部分时候,己方的服务器挂掉了,也会形成记录不一致的问题。
    个人思路,以日志为切入点解决问题。

    作者回复: 所有涉及到三方服务的交互,我建议request和response全部记录到(NOSQL)数据库中

    2020-05-25
    1
  • 睁眼看世界
    老师,请教下,全链路幂等处理的话,如果是web请求,除了前端防抖的话,后端可以如何处理?

    作者回复: 其实幂等考虑2方面:
    1、幂等依据,可以是每次交互生成的token,可以是客户端的序列号,可以是有意义的业务订单号
    2、根据幂等依据进行防重处理:
    1)限制:比如锁方式、状态机控制
    2)去重方式

    2020-05-29
收起评论
5
返回
顶部