1. 防止事务过大(TransactionTemplate编程式事务)
我们平时在使用spring框架开发项目时，喜欢用@Transactional注解声明事务。例如：
@Transactional(rollbackFor = Throwable.class)
public void updateUser(User user) {
System.out.println("update");
}
只需在需要使用事务的方法上，使用@Transactional注解声明一下，该方法通过AOP就自动拥有了事务的功能。
没错，这种做法给我们带来了极大的便利，开发效率更高了。
但也给我们带来了很多隐患，比如大事务的问题。我们一起看看下面的这段代码：
@Transactional(rollbackFor = Throwable.class)
public void updateUser(User user) {
User oldUser = userMapper.getUserById(user.getId());
if(null != oldUser) {
userMapper.update(user);
} else {
userMapper.insert(user);
}
sendMq(user);
}
这段代码中getUserById方法和sendMq方法，在这个案例中无需使用事务，只有update或insert方法才需要事务。
所以上面这段代码的事务太大了，是整个方法级别的事务。假如sendMq方法是一个非常耗时的操作，则可能会导致整个updateUser方法的事务超时，从而出现大事务问题。
那么，如何解决这个问题呢？
答：可以使用TransactionTemplate的编程式事务优化代码。
@Autowired
private TransactionTemplate transactionTemplate;
....
public void updateUser(User user) {
User oldUser = userMapper.getUserById(user.getId());
transactionTemplate.execute((status) => {
if(null != oldUser) {
userMapper.update(user);
} else {
userMapper.insert(user);
}
return Boolean.TRUE;
})
sendMq(user);
}
只有在execute方法中的代码块才真正需要事务，其余的方法，可以非事务执行，这样就能缩小事务的范围，避免大事务。
当然使用TransactionTemplate这种编程式事务，缩小事务范围，来解决大事务问题，只是其中一种手段。
额外补充
有返回值实例
Boolean bool = transactionTemplate.execute(new TransactionCallback<Boolean>() {
@Override
public Boolean doInTransaction(TransactionStatus status) {
return baseMapper.insert(fp) > 0;
}
});
无返回值实例
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
@Override
protected void doInTransactionWithoutResult(TransactionStatus status) {
baseMapper.insert(fp);
}
});
2. 判断条件太多（策略模式解决）
我们在写代码的时候，判断条件是必不可少的。不同的判断条件，走的代码逻辑通常会不一样。
废话不多说，先看看下面的代码。
public interface IPay {
void pay();
}
@Service
public class AliaPay implements IPay {
@Override
public void pay() {
System.out.println("===发起支付宝支付===");
}
}
@Service
public class WeixinPay implements IPay {
@Override
public void pay() {
System.out.println("===发起微信支付===");
}
}
@Service
public class JingDongPay implements IPay {
@Override
public void pay() {
System.out.println("===发起京东支付===");
}
}
@Service
public class PayService {
@Autowired
private AliaPay aliaPay;
@Autowired
private WeixinPay weixinPay;
@Autowired
private JingDongPay jingDongPay;
public void toPay(String code) {
if ("alia".equals(code)) {
aliaPay.pay();
} elseif ("weixin".equals(code)) {
weixinPay.pay();
} elseif ("jingdong".equals(code)) {
jingDongPay.pay();
} else {
System.out.println("找不到支付方式");
}
}
}
PayService类的toPay方法主要是为了发起支付，根据不同的code，决定调用用不同的支付类（比如：aliaPay）的pay方法进行支付。
这段代码有什么问题呢？也许有些人就是这么干的。
试想一下，如果支付方式越来越多，比如：又加了百度支付、美团支付、银联支付等等，就需要改toPay方法的代码，增加新的else...if判断，判断多了就会导致逻辑越来越多？
很明显，这里违法了设计模式六大原则的：开闭原则 和 单一职责原则。
开闭原则：对扩展开放，对修改关闭。就是说增加新功能要尽量少改动已有代码。
单一职责原则：顾名思义，要求逻辑尽量单一，不要太复杂，便于复用。
那么，如何优化if...else判断呢？
答：使用 策略模式+工厂模式。
策略模式定义了一组算法，把它们一个个封装起来, 并且使它们可相互替换。 工厂模式用于封装和管理对象的创建，是一种创建型模式。
public interface IPay {
void pay();
}
@Service
public class AliaPay implements IPay {
@PostConstruct
public void init() {
PayStrategyFactory.register("aliaPay", this);
}
@Override
public void pay() {
System.out.println("===发起支付宝支付===");
}
}
@Service
public class WeixinPay implements IPay {
@PostConstruct
public void init() {
PayStrategyFactory.register("weixinPay", this);
}
@Override
public void pay() {
System.out.println("===发起微信支付===");
}
}
@Service
public class JingDongPay implements IPay {
@PostConstruct
public void init() {
PayStrategyFactory.register("jingDongPay", this);
}
@Override
public void pay() {
System.out.println("===发起京东支付===");
}
}
public class PayStrategyFactory {
private static Map<String, IPay> PAY_REGISTERS = new HashMap<>();
public static void register(String code, IPay iPay) {
if (null != code && !"".equals(code)) {
PAY_REGISTERS.put(code, iPay);
}
}
public static IPay get(String code) {
return PAY_REGISTERS.get(code);
}
}
@Service
public class PayService3 {
public void toPay(String code) {
PayStrategyFactory.get(code).pay();
}
}
这段代码的关键是PayStrategyFactory类，它是一个策略工厂，里面定义了一个全局的map，在所有IPay的实现类中注册当前实例到map中，然后在调用的地方通过PayStrategyFactory类根据code从map获取支付类实例即可。
如果加了一个新的支付方式，只需新加一个类实现IPay接口，定义init方法，并且重写pay方法即可，其他代码基本上可以不用动。
当然，消除又臭又长的if...else判断，还有很多方法，比如：使用注解、动态拼接类名称、模板方法、枚举等等。
3. 减少不必要的db
尽可能的减少对数据库的查询
举例子
删除一个服务（已下架或未上架的才能删除）
之前有看别人写的代码，会先根据id查询该记录，然后做一些判断
反例
正例
4. 用@RequiredArgsConstructor代替@Autowired
我们都知道注入一个bean有三种方式哦（set注入, 构造器注入, 注解注入）,spring推荐我们使用构造器的方式注入Bean
@RestController
@RequiredArgsConstructor
public class PropertyController {
final DeveloperProperty developerProperty;
@GetMapping("/property")
public Object index() {
return developerProperty.getName();
}
}
5. TransactionSynchronizationManager事务同步管理器
有很多业务场景涉及到事务提交前或事务提交后做一些关联性的操作，一种方式就是可以考虑事务消息的解决方案。除此之外，其实这种业务场景可以考虑使用TransactionSynchronizationManager所支持的同步器实现功能。
使用TransactionSynchronizationManager的registerSynchronization方法注入一个TransactionSynchronization事务同步器，然后重写TransactionSynchronization或者其子类的beforeCommit()或者afterCommit()方法，写入事务前或后要执行的逻辑即可。
例如下面的实例代码，场景是完成带有事务的业务操作在事务提交后发送MQ消息，就可以通过同步器的afterCommit方法实现事务提交后执行发送MQ消息的操作。
@Transactional(rollbackFor = Exception.class)
public void registerSynchronization() {
try {
Thread.sleep(200L);
} catch (InterruptedException e) {
log.info(e.getMessage(), e);
}
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
rocketMQTemplate.asyncSendOrderly("TransactionTopic", "RocketMQTestService -> registerSynchronization",
"RocketMQTestService -> registerSynchronization", defaultSendCallback(), 3000L);
}
});
}
6. TransactionalEventListener监听事务
在Spring4.2+，有一种叫做TransactionEventListener的方式，能够控制在事务的时候Event事件的处理方式。Spring的发布订阅模型实际上并不是异步的，而是同步的来将代码进行解耦。而TransactionEventListener仍是通过这种方式，只不过加入了回调的方式来解决，这样就能够在事务进行Commited，Rollback…等的时候才会去进行Event的处理。
- 创建一个MQ发送消息事件类
@Getter
@Setter
public class TranCompleteEvent extends ApplicationEvent {
String destination;
Object payload;
String hashKey;
long timeout;
public TranCompleteEvent(Object source) {
super(source);
}
public TranCompleteEvent(Object source, String destination, Object payload, String hashKey, long timeout) {
super(source);
this.destination = destination;
this.payload = payload;
this.hashKey = hashKey;
this.timeout = timeout;
}
}
- 创建一个监听类
@Slf4j
@Component
public class TranCompleteListener {
@Autowired
private RocketMQTemplate rocketMQTemplate;
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onHandleEvent(TranCompleteEvent event) {
log.info("事务提交的监听器,event={}", JSON.toJSONString(event));
rocketMQTemplate
.asyncSendOrderly(event.getDestination(), event.getPayload(), event.getHashKey(), defaultSendCallback(),
3000L);
}
private SendCallback defaultSendCallback() {
return new SendCallback() {
@Override
public void onSuccess(SendResult sendResult) {
log.info("mq消息发送成功。{}", sendResult);
}
@Override
public void onException(Throwable throwable) {
log.error("mq消息发送失败。{}", throwable);
}
};
}
}
- 业务层代码
@Transactional(rollbackFor = Exception.class)
public void transactionEvent() {
// 业务层代码
try {
Thread.sleep(200L);
} catch (InterruptedException e) {
log.info(e.getMessage(), e);
}
//插入成功
TranCompleteEvent tranCompleteEvent = new TranCompleteEvent("Complete link.");
tranCompleteEvent.setDestination("TransactionTopic");
tranCompleteEvent.setPayload("RocketMQTestService -> transactionEvent");
tranCompleteEvent.setHashKey("RocketMQTestService -> transactionEvent");
tranCompleteEvent.setTimeout(3000L);
//发布事件
applicationEventPublisher.publishEvent(tranCompleteEvent);
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 只有当前事务提交之后，才会执行事件监听的方法，其中参数phase默认为AFTER_COMMIT，共有四个枚举：
public enum TransactionPhase {
BEFORE_COMMIT,
AFTER_COMMIT,
AFTER_ROLLBACK,
AFTER_COMPLETION
}
