mq基本梳理 为啥用mq

为什么要用mq？

解耦
异步
削峰填谷

业务—发短信–邮件

高并发有问题

tomcat默认150个链接，业务系统，要1s钟，并发量就是150个链接。并发数150个。
可以做成异步，时间不一定。

业务太大，拒绝请求也不行，可以作为异步，调用第三方接口，都可以导致耗时很长。并发不高。

多线程一种方案。

把业务消息，可以给到消息队列，内存队列q，在启动线程池，但是有一个问题，并发很多，100毫秒，并发可以到达1500.

执行一个扔到q里面，总有满的一天，就内存溢出了，报错了。不太合适。

线程池 导致，发送很慢，电脑性能有限，电脑核数有限制，不断加一个线程，一万个线程，可以，都是在做线程切换。非常卡顿。

一个系统里面，可以拆出来，短信，邮件可以单独拆出来。
队列 是线程，不能跨进程。 mq可以跨进程，
消息队列。
业务系统是一个tomcat， 消息完成后，投递给mq。在给业务发一个通知，投递完成。
同步通知，发一个确定。
投递到mq就可以了。这就是异步了。

mq将我们消息发邮件和短信。

同步消费变成异步消费。

解耦：

  开始在一个进程里面，一个tomcat，业务服务，短信服务，邮件服务。解耦。  可以扩充服务。

业务系统定时来扫描，可以看是否发送成功。

削峰填谷

业务量有峰值，有时候业务 比较小。
同时1500个并发，真实访问10w个并发。 可以先投递到mq，告诉业务系统我这个在处理中，业务系统在慢慢处理，时间很长并发不高的请求。

缺点：
增加系统的复杂度，只需要维护业务系统，需要业务拆分，发短信系统没有问题，邮件系统没问题，mq系统没有问题。
降低系统的可用性，维护一个tomcat。 集群可以解决一部分。
一致性问题，保证消息成功。
重复消费？
网络原因没有收到？
收到没有处理好，确认了？
rabbitmq就丢失了
没有发送确认消息，消息重试，就是重复消费？

一致性问题怎么解决？
幂等性解决

避免mq消息堆积？

  生产的速度很快,每秒1w条，消费100个，这种消费堆积。
  增加100个消费者，简单粗暴。问题在于，有波峰还是平均值，波峰100个浪费了，平均100，可能还不够。看怎么评估。
  mq可以支持批量消费，可以支持单个消费。
  每次消费100个，这样就会快很多。
  支持集群。
  为什么消费这么慢，代码优化，数据库加索引。 多线程。  
  还是不平衡，那就只能加消费者。
  
  如果消费者异常导致消息堆积？
         代码空指针，导致消息一直消费不了。
         mq  存储的文件，1t，有存储上限。 达到80%就会报警，90%就会拒绝。
         这个时候mq就想定于挂掉了。
         这个可用性降低。
        情况1： 消息堆积之后，少了一个判断，空指针，马上上线，原来有两个消费者，现在部署4个。消费完后就变成2个点。
         
         情况2：一时半会找不到原因，存储3天，消息满了也可能造成消息丢失，
                      暂时存储一下，有个数据库，可以全部扔到mongodb，这个保证系统可用。临时消费者，拿到消息直接插入mongodb里面，保证消息不会丢失，系统还可以用，mogodb速度很快，几千上完，分片，集群，不用考虑装满的情况。
                      修复了，消费mq，临时消费者砍掉，在从mongodb读数据，
                       也可以逆向消费，从mongodb读取数据，在存在mq里面，这样就不需要对消费者做变更。一个不够可以加几个消费，消费完在处理掉。


        mongodb  10w 也抗不了，可以在建立一个临时消费者，