这是我的第10篇原创
放假回老家，老爸正在修围墙，喊彭小贝去帮忙搬砖。果然放假还是别到处乱跑的好，在家吹着空调唱着歌，他不香吗？
没搬两下，彭小贝就累屁了。这不行啊！想到平时老板对他的教导，要用大数据技术驱动业务发展。于是他找了一个阴凉的地方开始进行技术选型。
技术选型可以简单分为三步：需求理解、提出方案、落地及优化。
一、需求理解
搬砖是指对砖头的运输， 从A点运输到B点。期望越快越好（这话怎么这么熟悉？）。影响搬砖速度的因素有：
1、A、B两点的距离；
2、砖头的数量；
3、搬运工的人数；
4、异常天气的影响；
5、搬砖工艺。
二、提出方案
彭小贝分析了一下这5个因素，其中距离和天气是不可抗力，emmm砖头的数量好像也是不可抗力，毕竟老爸会打死他。看来能优化的就是搬运工的人数和搬砖工艺了。
所以方案一出炉：增加一个搬运工，由单线程变成多线程，效率增加50%！
优化效果是非常明显的，但是会有1个问题：AB两地的距离恒定，两个人都要跑来跑去。
于是优化版方案二出炉：优化搬砖工艺~~串行执行任务。由于不需要移动，因此效率比两个人跑来跑去还要快，效率再次提升30%。
三、落地及优化
于是彭小贝喊来彭小宝，一起来搬砖。不一会儿就搬了很多砖，效率贼高。但是没一会儿搬砖系统就出故障了：天气太热，彭小宝又累又热，罢工了，给冰棍也不好使！于是又回到最初的单线程时代，彭小贝快要崩溃了！此时老板的话又萦绕耳边：要用大数据技术驱动业务！突然，一个念头闪过：可以用kafka（MQ）的原理去解决！
彭小贝翻出了以前的学习笔记，上面写的很清楚。
kafka（MQ）对信息传输流程的优化点有：
- 上下游解耦
- 同步变异步
- 削峰填谷
- 可靠性增加
最终方案出炉
在彭小贝和彭小宝之间增设一个消息中间件，生产者彭小贝把砖头放在MQ里，彭小宝从MQ中拉取砖头，堆放到B地。任何一方短暂罢工或者爆发都不影响整个链条的砖头搬运工作，完美！
同时可以做更多：
- 生产者只需要不断搬砖到MQ，实现最大运力（最大吞吐量）
- 把A地的无序砖头有序码放在MQ中，写入速度更快（有序写入）
- 消费者按需搬砖，不怕上游一次性搬太多砖（削峰填谷）
- 生产者把砖头放在MQ就行，不用交给消费者，俩人各做各的（业务解耦）
