思途CMS系统租车板块，提供给平台管理员进行租车产品的发布、管理、销售，并提供给前台会员进行车辆产品预定的功能模块。系统功能强大、代码简单易懂、操作简单，并完美体现和满足商业模式对系统的功能要求，使租车公司能把更多的精力放在网站的运营以及业务的开展上。
PHP租车网站源码，唯一真实解决租车管理、租车订单、租车资讯、租车评论、租车配置的租车网解决方案！
文件：590m.com/f/25127180-500072685-bf11f2（访问密码：551685）
以下内容无关：
-------------------------------------------分割线---------------------------------------------
在消息队列选型时，我们调研了市场上比较常用ActiveMQ，RabbitMQ，RocketMQ，Kafka。
RabbitMQ相对成熟稳定，这是我们选择它最主要的原因。
社区比较活跃，有完善的资料可以参考。
Rabbitmq的吞吐量可以达到万级，完全满足我们系统的要求。
RabbitMQ是Erlang语言开发的，性能比较好。
有完善的可视化界面，方便查看。
2. 消息队列的优点和缺点有哪些
优点有：
异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。
应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。
流量削锋 - 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。
缺点有：
系统可用性降低
系统复杂度提高
3. RabbitMQ常用的工作模式有哪些
2.1 简单模型
p：生成者
C：消费者
红色部分：quene，消息队列
2.2 工作模型
这种模式下一条消息只能由一个消费者进行消费，默认情况下，每个消费者是轮询消费的。
p：生成者
C1、C2：消费者
红色部分：quene，消息队列
2.3 发布订阅模型（fanout）
这种模型中生产者发送的消息所有消费者都可以消费。
p：生成者
X：交换机
C1、C2：消费者
红色部分：quene，消息队列
2.4 路由模型（routing）
这种模型消费者发送的消息，不同类型的消息可以由不同的消费者去消费。
p：生成者
X：交换机，接收到生产者的消息后将消息投递给与routing key完全匹配的队列
C1、C2：消费者
红色部分：quene，消息队列
2.5 主题模型（topic）
这种模型和direct模型一样，都是可以根据routing key将消息路由到不同的队列，只不过这种模型可以让队列绑定routing key 的时候使用通配符。这种类型的routing key都是由一个或多个单词组成，多个单词之间用.分割。
通配符介绍：
*：只匹配一个单词
#：匹配一个或多个单词
- 如何保证消息不丢失（如何保证消息的可靠性）
一条消息从生产到消费经历了三个阶段，分别是生产者，MQ和消费者，对于RabbitMQ来说，消息的传递还涉及到交换机。因此RabbitMQ出现消息丢失的情况有四个
分别是
消息生产者没有成功将消息发送到MQ导致消息丢失
交换机未路由到消息队列导致消息丢失
消息在MQ中时，MQ发生宕机导致消息丢失
消费者消费消息时出现异常导致消息丢失
针对上面提到的四种情况，分别进行处理
amqp协议提供了事务机制，在投递消息时开启事务，如果消息投递失败，则回滚事务，很少有人去使用事务。除了事务之外，RabbitMQ还提供了生产者确认机制（publisher confirm）。生产者将信道设置成confirm（确认）模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一ID），这就使得生产者知晓消息已经正确到达了目的地了。
开启生产者确认机制，
注意这里确认的是是否到达交换机
spring.rabbitmq.publisher-confirm-type=correlated
@RestController
public class Producer {
@Autowired
private RabbitTemplate rabbitTemplate;
@GetMapping("send")
public void sendMessage(){
/**
* 生产者确认消息
*/
rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
@Override
public void confirm(CorrelationData correlationData, boolean ack, String cause) {
System.out.println(correlationData);
System.out.println(ack);
System.out.println(cause);
}
});
rabbitTemplate.convertAndSend("s","error","这是一条错误日志！！！");
}
}
消息从交换机未能匹配到队列时将此条消息返回给生产者
spring.rabbitmq.publisher-returns=true
@RestController
public class Producer {
@Autowired
private RabbitTemplate rabbitTemplate;
@GetMapping("send")
public void sendMessage(){
/**
* 消息未达队列时返回该条消息
*/
rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
@Override
public void returnedMessage(ReturnedMessage returnedMessage) {
System.out.println(returnedMessage);
}
});
rabbitTemplate.convertAndSend("s","error","这是一条错误日志！！！");
}
}
消息在交换机或队列中发生丢失，我们只需要将交换机和队列进行持久化。
/**
- 定义一个持久化的topic交换机
- durable 持久化
- @return
*/
@Bean
public Exchange exchangeJavatrip(){
return ExchangeBuilder.topicExchange(EXCHANGE).durable(true).build();
}
/**
- 定义一个持久化的队列
- durable 持久化
- @return
*/
@Bean
public Queue queueJavatrip(){
return QueueBuilder.durable(QUEUE).build();
}
消费者开启手动签收模式，消费完成后进行ack确认。
spring.rabbitmq.listener.simple.acknowledge-mode=manual
@RabbitListener(queues = MqConfig.QUEUE)
public void receive(String body, Message message, Channel channel) throws Exception{
long deliveryTag = message.getMessageProperties().getDeliveryTag();
System.out.println(deliveryTag);
// 系统业务逻辑判断是否签收
if(deliveryTag % 2 == 0){
channel.basicAck(deliveryTag,false);
}else{
// 第二个参数是否批量确认，第三个参数是否重新回队列
channel.basicNack(deliveryTag,false,true);
}
}
- 如何保证消息不重复消费（如何保证消息的幂等性）
消息重复的原因有两个：
生产时消息重复
由于生产者发送消息给MQ，在MQ确认的时候出现了网络波动，生产者没有收到确认，实际上MQ已经接收到了消息。这时候生产者就会重新发送一遍这条消息。
消费时消息重复。
消费者消费成功后，在给MQ确认的时候出现了网络波动，MQ没有接收到确认，为了保证消息被消费，MQ就会继续给消费者投递之前的消息。这时候消费者就接收到了两条一样的消息。
由于消息重复是网络波动等原因造成的，无法避免，我们能做的的就是保证消息的幂等性，以防业务重复处理。具体处理方案为：
让每个消息携带一个全局的唯一ID，即可保证消息的幂等性，具体消费过程为：
消费者获取到消息后先根据id去查询redis/db是否存在该消息。
如果不存在，则正常消费，消费完毕后写入redis/db。
如果存在，则证明消息被消费过，直接丢弃。
@RabbitListener(queues = MqConfig.QUEUE)
public void receive(Message message, Channel channel){
String messageId = message.getMessageProperties().getMessageId();
String body = new String(message.getBody());
String redisId = redisTemplate.opsForValue().get(messageId)+"";
// 如果redis中存有当前消息的消息id
// 则证明消费过
if(messageId.equals(redisId)){
return;
}
redisTemplate.opsForValue().set(messageId, UUID.randomUUID());
}
6. 消息大量堆积应该怎么处理
消息堆积的原因有两个
网络故障，消费者无法正常消费
消费方消费后未进行ack确认