如果生产环境上由于某些原因消息消费者宕机了，导致消息积压在RocketMQ上，这时应该如何处理？处理方式如下：1、判断RocketMQ上的MessageQueue队列数是否有一对一的消息消费者进行消费，比如Topic有10个MessageQueue，而这个消费者只有2个，这个时候可以增加8个消费者，

1、配置在broker配置中加入：traceTopicEnable=true创建生产者时，开启消息轨迹追踪：DefaultMQProducer producer = new DefaultMQProducer(“trace-message-producer-group”, true);创建消费者时，

RocketMQ创建topic时可以指定多个MessageQueue，生产者发送消息时默认情况下会均衡得往topic中的所有MessageQueue发送消息，所以如果发送的消息有前后顺序要求的话，那么默认的情况下消息生产者不能保证消息的有序性，因为需要保证有序的这些消息会分布到不同的MessageQ

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("test-consumer-group");consumer.setNamesrvAddr("192.168.253.100:9876");

RocketMQ通过两阶段提交的方式实现事务消息，MQ生产者首先向RocketMQ发送half消息（prepare），RocketMQ响应之后生产者执行本地事务，然后根据本地事务执行情况再向RocketMQ发送Commit或者Rollback消息。如果这个过程中，RocketMQ一直没有收到生产者发

消息生产者发送消息时，Broker把消息存入到CommitLog中，每个CommitLog大小为1GB，CommitLog是一个顺序读写的文件，而且CommitLog并不会直接保存在磁盘中，而是保存在OS PageCache，OS PageCache性能接近内存，然后默认情况下以异步刷入的方式从OS

生产者Producer在发送消息的时候需要指定Topic，例如Message message = new Message(“test-topic”, buildString().getBytes(RemotingHelper.DEFAULT_CHARSET)); 通常Topic需要先提前创建好，在创

1、在前端/客户端设置秒杀答题，错开大量人下单的时间，阻止作弊器刷单。2、独立处理一套秒杀系统，专门负责处理秒杀情况。3、优先基于Redis进行高并发的库存扣减，一旦库存扣完则秒杀结束。4、秒杀结束之后，Nginx层过滤无效的请求，大幅度削减转发到后端的流量。5、瞬时生成的大量下单请求直接进入Roc

一、应该如何压测对RocketMQ的压测不能只关注RocketMQ的TPS，如果TPS达到峰值的同时，服务器的资源负载，比如CPU负载、内存使用率、磁盘IO负载、JVM GC频率以及网络流量负载都非常高，那么其实这个RocketMQ的TPS并不是最合适的峰值，因为有可能会导致服务器宕机，因此我们在压

一、OS内核参数（1）vm.overcommit_memoryLinux内存分配策略，可选值为0、1、2，默认为0.0：表示内核将检查是否有足够的可用内存供应用进程使用，如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用程序。1：表示内核允许分配所有的物理内存，而不管当前的内