在java的事务中，有时候可能会遇到以下情况，第一步是更新某某表，中间可能要更新不确定的多步，最后一步是更新缓存，结构大致如下：

（1）updateA();

（2）updateXX();   //此步骤可能有也可能没有，也可能有多个

（3）updateCache();

此时，因为第二步的不确定性，导致代码不太好写，而我们的更新缓存又必须放在最后一步，那么我们可以使用回调机制来处理。

（更新缓存放在最后一步可以保证以上步骤中任何一步更新出错都可以回滚，如果放在中间的话，更新缓存后面的更新出错了，则更新缓存这一步不会回滚，因为更新缓存不与数据库打交道。）

示例代码如下：

 

package alan_test;public class TestCallBack {private void updateDB() {System.out.println("update DB");}private void updateCache() {System.out.println("update Cache");}public void update( CallBack callBack ) {updateDB();if(callBack != null) {callBack.doSth();}updateCache();}public static void main( String[] args ) {TestCallBack testCallBack = new TestCallBack();testCallBack.update(new CallBack() {@Overridepublic void doSth() {new AnotherClass().updateXXX();}});System.out.println("-------------------------------------------");testCallBack.update(null);}
}class AnotherClass {void updateXXX() {System.out.println("update XXX");}
}interface CallBack {void doSth();
}

运行结果为：

 

其中，CallBack的dowSth()中可以添加一系列的更新方法以实现复杂的业务需求的需要。

从设计模式的角度来看，以上这种更倾向于策略模式，如果是监听器方式的回调则更倾向于观察者模式。

注：大家对spring事务操作怎么保证redis缓存与数据库一致有什么好的建议也一起来共享下，谢谢。

（吐槽一下：为什么java中函数不能当做对象使用，像javascript中那样直接传函数回调多简单）

欢迎关注我的公众号“彤哥读源码”，查看更多“源码&架构&算法”系列文章, 与彤哥一起畅游源码的海洋。