消息队列概念举例
小红是小明的姐姐,小红为了督促小明多读书，经常寻找好书给小明看，先前的方式是这样的，小红先问小明什么时候有空，然后把书送到小明跟前并且监督小明读完书再离开，久而久之，两人都有些厌烦，可书还是要读的，否则怎么跳槽加薪啊？
所以改变了方式，小红把小明需要看的书都放到书架上，小明直接从书架上拿下来书看即可，这时书架就是一个消息队列，小红是生产者，小明是消费者，这样做带来了四大好处
- 小红不必费劲把书亲手交给小明，甚至不关心小明在不在，而是直接把书放到书架上，这样小明回到家看书架有书自然就去阅读，这样小红小明的时间都更自由了
- 小明本身是能够自觉读书的，即使没有小红监督也能很好的完成读书任务，所以不需要小红一直监督着，能节省小红很大力气(涉及到异步发送)
- 如果哪天强行加入了一位爱读书的小伙伴，他也直接去书架拿书(姑且理解为一本书被俩人拷贝后拿走)
- 书都在书架上，小明读的快就早点看完，读的慢就晚会看完，都是可以的，不会和之前一样在小红的督促下拼命赶工完成读书任务，解放了小明
消息队列解决的问题
-
解耦：消息队列要解决的最本质问题,你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束即可,而不需要直接调用他人的接口，大大降低耦合度；如下图，消息队列诞生前B需要A找那个的数据只能掉A中的接口，后续更多的服务器B1,B2掉用了A接口，那就产生接口耦合了
案例中的三人(今后读书小组可能还会发展到n人的规模)不必受其它成员时间和习惯等因素的影响，只通过一个简单的书架来进行联系，他们眼里只有书架没有其它人，甚至后期小红都不关心谁来取书看，读书者们也不关心谁把书放到书架上的，和一个简单的消息队列打交道显然比和一个个人打交道简单的多 -
广播(发布订阅模式)：消息队列的基本功能之一。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。这里小红只需一个简答的放书动作就能使读书小队人人都能读书
-
错峰与流控：讲用户请求存储在kafka，消费端也就是服务器端定额拉去处理请求，如果因为短暂的流量激增(比如秒杀业务和双11等场景)而扩展服务器那无疑是一种巨大的浪费，这样用于流量削峰场景，起到一个缓冲的作用。小红猛然发现一堆好书，此时如果还是采用之前的方法督促小红去完成小明会裂开，因为小明的读书能力和精力都是有限的，妈妈(用户)也很因为小明完不成任务恼怒，但有了书架后，小红就随缘了，把这一堆书放到书架上即可，并且会给妈妈打一个招呼，让小明慢慢看去吧，虽然速度还是那样，但总比小明累死强啊。
-
恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
-
最终一致性：两个系统的状态保持一致，要么都成功，要么都失败。最终一致性不是消息队列的必备特性，但可以依靠消息队列来做最终一致性。小红在书架上按个监视器，因为最终目的是要让小明把书读完的，而不是简单的把书放到书架上，小红通过监视器能知道小明的读书情况，大部分情况下小明肯定是能正常完成任务的，但也不排除一些意外如书丢了或者书错了导致小明没有成功读完书，小红也能知道小明没有完成任务
-
异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许生产者把一个消息放入队列，但消费者并不立即处理它。生产者想向队列中放入多少消息就放多少，然后消费者在需要的时候再去处理它们。小明突然身体不舒服不想读书，难道小红还要等小明身体回复再监视他读完吗？并不是这样，我们只需要让小明立一个FLAG,然后小红把这个flag汇报给妈妈（公司用户），让妈妈知道至少小明是有这个意愿读书的，等小明身体恢复就会立刻爬起来读书。
缺点
1 引入复杂度，书架本身就是多出来的
2 暂时不一致，其实最终一致性和展示不一致性是同一概念,先前的方式小红监督小明读书，虽然费劲，但如果妈妈问小红小明的读书情况那么小红可以理直气壮的说小明读完了or没读完，但现在小红只能模糊的回答：应该读完了或者快读完了，也就是说中间存在一段时间就是我们认为小明已经读完了，但其实小明正在阅读还没读完，但最终小明会读完的，这就是最终一致性
3 无法获取反馈，采用这种方式可以看出来小红
