星光不问赶路人,时光不负有心人，时间总是一年有一年的过去，可是自身的积累可能没有随着时间的推移而进步，然后可能就会愈发急躁，就像王小波说的那样，世间很多的痛苦都是来源于自己无能的愤怒，我之前读过一本德川家康的自传，他的思想对我深有感悟，就是以时换空，时间会推移，但是只要坚持不懈，自己也会在这段时间里成为自己想要成为的人，也就是时光不负有心人，也就是德川的那句话，人生入负重致远，不可急躁。
下面来讲讲组件了，前几天和朋友一起吃饭，他说现在很多人都在谈组件，已经不向以前了，那消息组件是啥呢？
Mq，翻译一下 Message Quene，在翻译一下消息队列，这回知道他为啥是Mq了吧。
然后他有很多中，什么activeMq，rabbitMq，rocketMq，kafka
今天说的是其中的rabbitMq，当然也会和他们对比
先说优点
1 解耦
如果工作几年，那么一定就会发现，解耦常用的一种方法，就是增加一个中间层，比如，我明明可以直接调用一个方法，为啥我要搞一个抽象类，再比如，我之前说的redis中，都有这样的涉及，rabbit也是使用的这种思想，本来A系统可以直接调用B系统，也可以直接调用C系统，也可以同时调用BC系统，但是我现在不这么干，在他们之间加一个中间层rabbit，为啥这么干呢，因为直接调用的方式虽然快，但是耦合性太强，而且还要担心如果发送失败是不是要进行重试的问题，而中间层rabbitMq就能解决这个问题
2 削峰
数据库的处理能力是有限的，每秒最多处理2000个请求，多了他就gg了，那如果来了5000个咋整，当然我们可以通过redis缓存，但是数据库的请求也不仅仅是查询，还有修改删除之类，这时候也可以把相应请求给rabbitMq
3 异步
这个就简单了，和多线程处理的科特尔处理法则一样，降低方法的执行时间，也可以增强用户的体验，毕竟对于一个互联网项目，如果响应时间很长，那用户绝对不爽。
但是，哈哈，突然想起权利的游戏里面的一句话，我叔叔告诉我听别人说话，要听别人但是后面的话，这个但是就是缺点。
1 系统可用性降低
引入rabbitMq，系统就会依赖他，如果他gg了，那么系统也要跟着受伤害。
2 系统复杂性增加了
就像之前说的redis，mysql，每一项技术不只要向前看，还要向后看，除了问题怎么办，rabbitMq会出现重复消费，这要怎么解决，他发消息到ABC系统，如果B系统没处理成功造成数据一致性问题，又该怎么解决，所以针对这样的问题还要写解决方案，所以复杂度就上去了
说完优点，缺点再说说几个Mq的对比
简单说说吧，active他和mq处理的任务大小都是万级的，而后面两个就都是10万级别的，而rabbit有低延迟性，这个是其他几种Mq都比不了的，但是rabbit底层是用erlang来开发，这个语言太小众，所以懂的人少，也就造成了没办法研究他的源码，是一个缺点。
