对于一些较复杂的业务场景,可能的最长操作有10多个update或者insert操作,还有多个redis操作
对于redis操作,整个事务失败后需要手动处理回滚,多个操作写回滚的代码可能会比较烦索
对于DB操作,如果全部放到一个大事务里面,缺点是相互影响较大,多个更新操作,失败风险较大,子业务会影响主业务
(某些场景不用数据的事务,会用手动处理事务的方式,处理起来较烦索,尤其是操作多的情况,比较来看数据库事务代码就简单得多了)
需要拆分成一个主业务线,和多个副业务线,对于重要并且访问量大的场景,或者不重要的子业务需要较长的响应时间,需要拆分成异步处理的方式
(异步的方式,可以自己写消息队列,也可以用成熟的框架)
目前我的方式是,在拆分成主业务和副业务之后,每个子业务用一个数据库的事务控制,redis手动处理回滚,
然后处理成主业务是多个子业务并行的模式,如果有某个子业务失败了,报警,并且预留重复请求接口,暂时手动人工处理异常情况,量大再议
0 comments:
Post a Comment