网站地址跟网页地址区别,域名备案查询最新消息,个人网站取什么域名好,郑州编程培训机构作者简介#xff1a;大家好#xff0c;我是smart哥#xff0c;前中兴通讯、美团架构师#xff0c;现某互联网公司CTO 联系qq#xff1a;184480602#xff0c;加我进群#xff0c;大家一起学习#xff0c;一起进步#xff0c;一起对抗互联网寒冬 学习必须往深处挖… 作者简介大家好我是smart哥前中兴通讯、美团架构师现某互联网公司CTO 联系qq184480602加我进群大家一起学习一起进步一起对抗互联网寒冬 学习必须往深处挖挖的越深基础越扎实
阶段1、深入多线程阶段2、深入多线程设计模式阶段3、深入juc源码解析阶段4、深入jdk其余源码解析阶段5、深入jvm源码解析
事务的难点在哪
之前分享过一个观点设计模式最难的不是代码、也不是设计思想而是如何准确判断每种设计模式的使用时机。一些人可能对23种设计模式如数家珍、倒背如流却常常在阴沟里翻船不知不觉就用了各种if else到处打补丁。 同理事务本身其实也不难无论本地事务还是分布式事务业界都有成熟的解决方案。事务最大的问题也在使用时机
人们往往不知道此处需要事务 佣金错误案例
日常开发时我们很容易写出下面的代码
Transactional(rollbackFor Exception.class)
public void execute() {updateUserPoint();updateUserLevel();
}
由于用户积分和用户等级需要满足“要么同时成功要么同时失败”的特性所以加上了Transactional保证事务。很多人都十分清楚Transactional什么情况下会失效但事务往往总在你意想不到的地方失效。 请大家观察下面这段代码看看有什么问题代码做了适当简化
// 根据订单号获取佣金
public ListOrderCmsDO getCmsList(String outerOid) {if (StringUtil.isEmpty(outerOid)) {return Collections.emptyList();}ListOrderCmsDO cmsList;try {// 构造请求参数CmsCalculationReqBO reqBO generateParam(outerOid);log.info(CmsCalculateBiz.getCmsList, outerOid:{}, reqBO:{}, outerOid, reqBO);// 计算佣金cmsList cmsCalculatorSelector.select(reqBO).calculateAllCms(reqBO);log.info(CmsCalculateBiz.getCmsList, outerOid:{}, reqBO:{}, cmsList:{}, outerOid, reqBO, cmsList);} catch (Exception e) {log.info(CmsCalculateBiz.getCmsList, request error, outerOid:{}, outerOid, e);}return cmsList;
}// 计算佣金每计算一种类型的cms就往cmsList中add
public ListOrderCmsDO calculateAllCms(CmsCalculationReqBO reqBO) {// ...CmsCalculateContextBO contextBO generateCmsContextBO(reqBO);/*** 注意以下执行顺序不能改变** 计算V0 分享奖励* 计算V1 自售或者分享奖励* 计算V2 平台补贴* 计算V2 自售补贴* 计算V2 自售或者分享奖励* 计算V2 星火奖励* 计算V3 平台补贴* 计算V3 自售补贴* 计算V3 自售或者分享奖励* 计算V3 星火奖励*/calculateV0Profit(reqBO, contextBO);calculateV1Profit(reqBO, contextBO);calculateV2SubsidyProfit(reqBO, contextBO);calculateV2Profit(reqBO, contextBO);calculateV2Spark(reqBO, contextBO);calculateV3SubsidyProfit(reqBO, contextBO);calculateV3Profit(reqBO, contextBO);calculateV3Spark(reqBO, contextBO);return contextBO.getCmsList();
}
大致逻辑是 上游方法依赖getCmsList()然后批量插入用户下单所得佣金具体佣金计算逻辑在calculateAllCms()。一个用户下单所得佣金比较复杂最终返回的cmsList类似这种
[{bizId: xxx,cmsAmt: 1,cmsDesc: V2平台补贴,outerOid: xxx,uid: 10086},{bizId: xxx,cmsAmt: 15,cmsDesc: V2分享奖励,outerOid: xxx,uid: 10086},{// 本订单其他类型佣金...}
] 一个用户它的佣金假设有A、B、C三种类型要么同时插入3种佣金要么都不插入后期有问题直接重跑即可最怕的就是那种只插入一半的情况修复很麻烦需要删除原有的甚至还要回滚由佣金引发的一系列操作。 而上面的代码就可能导致部分佣金写入的问题 假设calculateAllCms()中需要计算3类佣金A、B都没问题C类佣金计算失败抛异常那么就会进入上面的catch代码块。然而此时cmsList中已经有A、B类佣金代码继续往下走就会return cmsList返回了不完整的佣金列表最终数据库插入的就是不完整的佣金缺少C类佣金。
catch里面可以直接返回emptyList不插入总比插入不完整的好后面再补就是了。 小结
分布式应用中也很容易因为疏忽导致数据不一致比如我们往往会引入Manager层为的是对其他Service的API接口做一层封装
Slf4j
Component
public class MemberServiceManager {Resourceprivate MemberDirectRecordService memberDirectRecordService;public MemberDirectRecordTO getDirectRecord(Long uid) {if (Validator.isNotId(uid)) {return null;}try {ServiceResultTOMemberDirectRecordTO resultTO memberDirectRecordService.getDirectRecord(uid);if (Validator.isNullOrEmpty(resultTO) || Validator.isFalse(resultTO.getSuccess())) {return null;}return resultTO.getData();} catch (Exception e) {log.error(getDirectRecord, error, uid:{}, uid, e);}return null;}}
上面这种写法由于异常被吞了调用者往往很难区分到底是远程调用超时导致null还是接口查询本身为null。如果调用者的逻辑是
if(result不为null){ // 本意是不为null进行一些操作do something;
}
但如果这个“null”仅仅是因为RPC远程调用失败导致的而不是对应的数据真的为null本次操作就会被遗漏效果和上面的佣金计算是一样的。 这些其实都是事务范畴try catch处理不当容易导致问题被忽略最终发生数据不一致的问题。
