RabbitMq 去下订单，这么多细节你不看吗？

先来个题外话~

servlet 3.0规范
1.其实提高并发请求，就是减少tomcat线程池中，线程的执行时间，说白了就是提高利用率。而servlet 3.0就是，一个用户请求过来了，访问servlet拿到一个线程之后去处理了业务逻辑，这时候业务逻辑块开启了     一个新的线程去处理自己的业务逻辑，处理完之后，在此调用  servlet.虽说次数增多了，但是两次时间都是比较短，整体的并发量也就上去了。

rabbitMQ 下订单

1.有两种模式，一种是推，一种是拉，默认是推，拉是，消息执行完主动去拉，会造成消息堆积 kafaka是只有推模式的。

2.消费者假死现象，消费端有异常造成的，导致没有手动确认，比如代码异常，数据库异常等等。消费端去消费消息，不是直接消费消息的，而是本地有一个消息队列

3.消费者及消费线程，不是说100000个就会创建这么多线程的

4.消息单条确认，批量确认。批量确认会存在消息丢失的现象。rabbitmq的消息是有状态，所以比kafka性能低，单条确认加try catch，异常的话直接放到死信队列中

5.rabbitMQ 建议使用批量确认消息，减少网络通信，有异常可以先放到死信队列中

6.延迟队列，订单失效的业务场景，比如10分钟内没有支付的场景。定时任务可以做这个吗？不可以的，时效性是不准确的。

  延迟队列去做，生成订单以后，往mq里面发送一条消息，放到延迟队列里面，不是用来消费，是让里面的消息过期 的，消息一旦过期就会插