消息队列有两种模式，一种是队列模式，一种订阅-发布模式.
队列模式就是一个点对点，生产者生产消息发入到队列，然后消费端从队列里拉取，这里注意的是当有多个消费者的时候，一条消息只会被一个消费者消息，如果一条消息需要被多个消费者消费，那就需要将消息发入到多个队列（rabbit mq就是典型的队列模式，要实现一个消息被多个消费者消费，可以用exchange路由到不同的队列中）。
基于这种情况，产生了订阅-发布模型，一条消息发给消息队列可以发给订单模块，风控模块等等，那如果订单模块里面有多个服务，这些服务肯定只要一个服务能消费就行了，所以在订阅-发布模型中有了消费者组的概念，另外消息队列是实现队列的语义的，比如a消息在b消息之前进入队列，a消息没有消费完，b是不会发出去的，这样下游一堆服务嗷嗷待哺，却阻塞在了某个消息上很是影响处理速度，于是在队列模型上，订阅发布又做了处理，消息原先发给队列，改成了消息发给主题，主题再发给队列，一个主题有多个队列（这是rocketmq概念，对应kafka就是主题和分区），这样就保证了每个队列可以同时发消息，另外消费者消费消息是采用了拉的方式而不是队列给消费者推的模式，如果用推消费者消费不过来，就会有问题，用拉的模式天然解决了背压，消费者需要多少就拉多少
所以订阅-发布实现大致流程，首先消费者和队列创建长连接，消费者发送到某个主题给队列，队列收到后先写事务曰志，再将消息根据规则发到某个队列，再回调消费者通知消费者处理成功还是失败，队列这个地方一般需要做备份，也就是副本，也可以用类似es的手段，写入超过法定数量即表示成功，后期如果备份损坏，再通过标志位从主分片或其他分片拉取消息，消费者消费的时候，告知队列从哪拉取，kafka里有个设置，从最新处，或者从最开始，队列也可以记录消费者消费的offset，当消费者再次拉取的时候告诉消费者消息到哪了，消费者也可指定具体的offset来消费，flink里面通过checkpoint机制，序列化了offset，当宕机重启后能够知道上次消费的情况，从而实现exactly onece的语义。
