先分析下为何会产生顺序的问题:
加@Transactional属于数据库的事务。伪代码如下:
database transaction begin;
try{
insert into table;
send to kafka;//这个动作先发生,有可能消息已被消费,而下面的commit还没执行完成。
database transaction commit;//这个必须放在后面以保证两个动作的事务特性。
} catch (exception) {
database transaction rollback;
}
上面的send to kafka发送失败了,那么数据库也会回滚,这样数据是一致的。但是如果发送kafka成功而commit失败,那么数据库数据是无效的,而消费者照常去消费消息,这也可能导致B服务通过Id找不到数据。
上面是B服务找不到数据的两种可能情况。
所以问题的原因是对两个操作进行了不正确的事务控制。正确的事务控制应该是下面这样的:
kafka transaction begin;
database transaction begin;
try{
insert into table;
send to kafka;
database transaction commit;
kafka transaction commit;
} catch (exception) {
database transaction rollback;
kafka transaction rollback;
}
上面database事务提交先于kafka事务,这样会保证服务B在消费的时候数据已经在数据库了。database事务提交失败了,两者都回滚,数据是一致的,database事务提交成功,kafka事务也提交成功,两边的数据也还是一致的,但是如果database事务提交成功,kafka事务提交失败,也有可能导致数据不一致(数据插入成功了,服务B无法消费)。所以得有个补偿机制,消息中间件我了保证数据一致性,会有个超时询问机制,如图:
所以系统A还需提供一个事务询问的接口,供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时,如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话,就会主动调用系统A提供的事务询问接口询问该系统目前的状态。