记Kafka顺序消费

1、生产者根据当前的msgtype绑定对应的partition，运维根据实例去消费对应的partition数据—需要运维介入，不合适

2、生产者根据当前的msgtype绑定对应的partition，每个实例通过分布式锁来竞争获取对应的partition，进行消费
以上两个均存在每个实例均存在状态，如果关闭一个则会存在partition的数据无法消费，导致数据阻塞

3、生产者通过获取中间件中的自增ID+中间件的纳秒数作为所有数据的外加唯一标识，消费者消费数据后不交付给业务，而是直接
交给中间件（redis）通过zset进行排序，然后业务从redis中pop消费数据，进行消费
问题：1、比较依赖中间件，如果出问题则较为严重
2、数据需要冗余存储两份（从redis中pop的数据，只存储id，通过id取获取对应的业务）

4、通过业务id或者类型进行取模消费。

总结

以上均只能处理partition中的顺序消费，如果消费者同时需要并发消费的情况下，则重新需要考虑在消费者端考虑将同一类型数据分配到同一队列中，避免在消费者端出现了并发数据不顺序的情况。