MQ和kafka这类消息队列现在使用的不少，而且Pulsar的崛起我看有望将来一统江山。我今天的会引用一些别的连接的图文数据，更加客观来说明。
这个连接是https://www.cnblogs.com/linjiqin/p/5720865.html
可以看出这样是能提高效率的。这是没有问题的，至少在逻辑上是没有问题的。
但是有一点需要质疑一下的，那就是写入数据库的那块，上图是50ms。也就是说一秒能写入20条。在任何一个数据库来说（除了区块链这种史上最慢的数据库），一秒写入20条这种龟速的一定是数据库出了问题，这种情况下其实我觉得用不用消息队列都是表面问题，深层次的问题大了去了。理论上每秒写入1000是最保守的，即一条1ms。不见得比队列慢，甚至可能比队列还快。为什么？
上图的数据说到使用了队列使得系统QPS达到了20.这是基于那个龟速来说的。那么我们继续假设就是这种有问题的场景下，如果一个系统的业务量QPS小于10,就能满足，那么是否还需要多次一举呢？
好的，我们继续。这个下面一个连接是kafka的写入。
https://www.cnblogs.com/lshan/p/13030923.html我引用这个主要说明一个点那就是写入不要光看多少条，其实每条的大小不一样速度是不一样的。
上图用官方的工具，作者比较客观的说明了每条是100K，也就是0.1M的情 况。那么最终除了中间件本身的能，主要的制约力看的就是你的IO能力。这就是想数据库一样，数据库自身能力是其产品功能特性所有的，还要一部分就是基础环境。比如以前磁盘是机械磁盘，现在是SSD以及Nvme等等，用来提高速度。
所以如果用很差的IO的话，消息队列也是发挥不出来的，如果在这种情况下（IO很差），还用下来没有问题，那么我觉得不用消息队列也可以。
至于说解耦，其实是队列最大的特殊，但是如果我们的模块是紧耦合的，（业务场景限制），那么又是对消息队列的使用又一个打击。
再比如说一个用户有10元钱，要买两个东西，一个是5元，一个是6元。我觉得不管用不用消息队列，他都只能买一个。这种多了一道环节也解决不了的数学问题。还是不要用了。 消息队列还是好的，在超过数据库的处理能力的场景下应该使用，但是除了极端场景的，大部分其实数据库都是处理的了的。
其实就是说在没必要的情况下我们是不是一定要设计队列环节？就像明明血压正常，是不是要学高血压的人吃降压药？说为了防止血压升高？
