今日学习总结
我们使用消息队列，一般会关注消息的延迟，然后优化消息的读写性能，但首先要做的是对延迟的监控，那怎么监控消息队列的延迟呢？
1.通过消息队列的工具，来监控消息的堆积情况
一般消息队列都会提供这种工具，拿kafka来说，可以通过 kafka-consumer-groups.sh 这个命令来监控堆积情况。主要关注【lag】列
同时kafka会通过jmx暴露消息的堆积情况，所以可以使用jconsole这种工具进行查看

2.通过生成监控消息的方式来监控延迟情况
这种方式就是启动一个监控程序，并生产一种特殊的消息，比如是消息生成的时间戳，然后循环的写入到消息队列中，真正的消费者对于这种特殊的消息不进行处理，而监控程序会处理这种特殊的消息，通过比较消费到该消息的时间和生成该消息的时间差来判断是否有延迟

那如何减少消息的延迟呢？
1.优化消费端的代码以提升性能
2.增加消费者的数量

关于第2点对消息队列会有限制，比如对于kafka来说，在同一个分区下，消息只能被一个消费者【同一个consumer_group】消费，这样也是考虑到了多个消费者消费需要抢占锁，会有性能损失
【topic的分区数量决定了消费者的并行度】
所以想提高并行度就得增加分区，那如何不增加分区呢？可以在处理消息上做工作了，比如可以在一个消费者中增加处理消息的并行度，比如多线程的方式去处理，或者加入异步处理

【这里有值得注意的，就是消费消息时消费线程的空转问题】
消费端通过不断轮训去topic中拉取消息，就存在线程空转的情况，这里可以增加一个策略就是拉取不到消息，等待一会儿，等待时间可以是固定的。也可以是阶梯的，当然这样可能加重消息消费延迟情况

消息队列本身读取性能提升可以从下面两个方面着手
1.消息的存储
2.零拷贝技术

你先定义一种特殊的消息，然后启动一个监控程序，将这个消息定时地循环写入到消息队列中，消息的内容可以是生成消息的时间戳，并且也会作为队列的消费者消费数据。业务处理程序消费到这个消息时直接丢弃掉，而监控程序在消费到这个消息时，就可以和这个消息的生成时间做比较，如果时间差达到某一个阈值就可以向我们报警。


老师，这里有个问题，你这么做是问了判断当前队列的延迟时间对吧，但是这样子做的话定时生成的时间戳和正式的任务混在一起了，这样不就给正常执行的业务处理程序增加了很多负担，会不会导致太多的这种任务导致对于正式的业务延迟更大？