比如生产者发送了一个员工离职的消息，我会在消费者端去生产者服务查询员工是否真的离职了，确认没问题后再消费。影响性能不说，而且感觉这样就耦合起来了，是否违背了消息队列的原则呢

有没有大佬解答一下

肯定要查询处理，如果期间他又入职了呢，你按离职处理数据无法一致性

首先你要明白，系统内，不应该存在拜占庭将军问题，也就是说你的数据不可信这种问题，这种问题不是系统内的问题，是安全问题。
其次，其实你想问的应该是强一致性和最终一致性的区别，这种问题，小一点是业务流程处理的问题，大一点是领域设计的问题。
再然后，我假设你还没到领域模型这一步，那么你问的只是业务流程的问题。
例如一个员工，离职，再入职，员工的状态该怎么变。
消息队列(假设是同一个queue)是可以做到同一个分组下按顺序消费的，只要你上一个消息(离职)的消息没commit，下一个消息是不会让你消费的，也就是员工一定是离职消息先到，再入职的消息后到，参考rockmq。
当然也有一些中间件不支持顺序消费，又或者你干脆是用的两个topic(两个queue)，那么这个消息是乱序的，其实这就是架构设计导致的业务问题，一般实际工作中，业务问题就用业务的方式来解决。
一般也就是最终一致性 —— 我们不关注它中间怎么变，只要保证最终数据是对的就行。
例如 员工A的离职消息，再入职消息乱序。
这两个消息的报文体里面都有操/生产作时间(例如数据库的更新时间)，在消费者中，业务代码里，按照员工为单位，记录它最后一次操作/生产的时间，如果下一条消息过来比这个时间要早，直接丢弃这条消息。
例如：再入职的消息(2021-10-23 21:55:00)先到，更新员工的状态为入职，然后员工离职的消息(2021-10-23 21:54:00)到了，发现这个消息的生产时间比刚刚的2021-10-23 21:55:00的要早，那就不处理这条离职的消息。这样员工的状态是对的。当然其中会有一些部分会用到分布式锁，这里就不提了。
下游反查上游，首先架构设计上领域交集太大，其次轻则性能差/雪崩/消息堆积，重则同行多写导致数据库死锁。
关注公众号：面试官求放过

不需要反查啊，