@passerbytiny #121 一般这种 web 改性别都是需要同步了吧，而且这种情况用传统 RPC 不也一样吗，消费者也可能不是一个消费者，消费速度也不一定一样，RPC 收到的顺序也不一定是按顺序的，这就涉及到分布式锁的问题了吧。
额，我的姿态很高吗？我平常打字容易口语化吧。

@wysnylc #118 这三个单拿使用场景确实不是一个从层面，我的意思类似于“我拿个电风扇可以改成搅拌机不，和原来搅拌机有什么区别”

@passerbytiny #117 我没有例子，我不知道是什么效果，我也不是来发论文说队列比传统 RPC 好。关于制定消息内容，编写的时候不就已经确定好了吗，head 头可以标识或者消息过滤器不可以实现吗？关于重发机制，在超时之前我认为发出消息就是一直有用的，堆积在队列中不一样可以等待 server 启动吗，传统 RPC 好处就是可以快速判断所有连接是否断开，但是既然消费者都挂了，重试不也没用不是。

@feelinglucky #100 1 楼和你想到的可能是 队列和传统 RPC 之间的本质区别，我的意思是在用 传统 RPC 和 队列 实现的消息通讯上有什么区别，在微服务上有什么效果，不是他俩的本质区别。

@passerbytiny #110 顺便问一下“队列无法保证顺序执行”，为什么不可以用呢？现在的消息不都是带标识 head 头吗

@webee #109 我说的是类似于饿汉式的抢任务。


@passerbytiny #110 第一点我确实不是很了解，第二点我的意思是类似与饿汉式的主动抢任务，不是由队列主动分配。其实第三点我想的是解耦，注册中心我只是举个例子，调用者只需面对中间件，不用面对众多的 Server。

@sampeng #106 不是，那你想说什么？那他俩到底有没有可比性？是那个观点让你觉得我在胡说？

@webee server 端加 buffer 并不能解决负载的不均衡问题（相比较而言）啊。关于满不满足我的需求，我也不知道效果怎么样，首先我能明显知道的缺点就是性能不如传统 RPC，但是差多少？我不知道，我的标题就是我想说的，我不知道是什么效果，我是来想问问而已，大家只是一味的在抨击。

@sampeng #101 业务上的同步异步。那如果我用 队列 和 传统 RPC 来实现消息通讯，那两者有可比性了吗？两者理论上也都可以实现同步和异步不是吗

@sampeng #96 ？？？这个帖子压根就不是讨论同步异步的问题，是楼上歪楼了，他们的认知是 RPC 就只是同步的，用队列实现通讯就是只能是异步的。

@Duluku #81 我觉得都使用微服务了，是否对代码由侵入性显得没那么重要，而且我觉得对于微服务中使用 传统 RPC 代理的模式 本身就有点不那么清真，微服务“远程调用”就该显式的告知调用者这是远程服务，调用者也不会滥用。队列消息可以设置被一次消费还是多次消费。关于性能，开头我就说了肯定不如传统 RPC，但是吞吐量应该还是有一定保证的。

@1ffree #82 解耦、相较之均衡的负载、（可能）更稳定的消息，在微服务种有的话不会好一些吗。

@langxuan #83 延时肯定有的，开头我也说了。关于消息堆积，本质上还是消费者消费速度慢，你消费速度慢不管用什么 RPC 他都得堆积，只不过传统 RPC 堆积的地方在消费者网卡缓存 /内存中而已，而堆积过大会可能导致消息丢失 /内存溢出等问题。

@justRua #87 消息的 100%的成功是每个程序员的梦想，既然都到了业务逻辑块了，为什么不处理一下呢，多浪费，直接返回繁忙不会显得失败率高吗？我觉得微服务面对的又不是用户，在超时限制之内这个消息就是有用的，返回繁忙只会徒增调用者的处理逻辑。你说的负载均衡是由调用者或注册中心判断的，由消费者直接判断自己的负载不是更简单和准确吗？ kafka 的确是用 zookeeper 做注册中心，我开头第三条的意思其实是用队列可以解耦，就算用 kafka，调用者面对的只是队列，而不是众多消费者。

@version #89 我不知道你用的什么队列，2、3 秒实在夸张了，多数监听队列中间件的 driver 并不是轮询的方式，而是长连接，能做到什么样的性能我也不知道，所以我就是来问的。

@Duluku #78 我知道，是楼上们在较真同步和异步的调用，跟他们解释好费劲。

@petelin #63 ...... 我没有说颠覆性，我理解的优缺点我开头就说了，实现所需要付出的代价肯定是有的，但是同时也会带来一些队列的特性，我想知道如果两者放在微服务效果是怎样的，是否值得。我不是鼓吹队列肯定比传统 RPC 好，你们只是一个劲的反驳，看的我莫名其妙。

@scnace #61 性能不如传统 RPC 是必然的，但是同时高并发的压力也会转移到队列中一部分去。关于炸了，个人觉得现在队列都有分布式，应该还好。

@luozic #66 都可以放在微服务通讯中，为什么不可以比较？

@reus #70 我想的就是因为不是互斥的，在某些场景是可以替换的，想知道两者在微服务中的差距。

@javaWeber #75 关于 Spring Cloud，我在开头专门给它和其他传统 RPC 做了逗号分隔，就是因为 较真的话，http 也可以实现 RPC 的，只是不像我们理解的传统 RPC 是 socket 流传输的，其实 GRPC 默认还是 HTTP2 传输的呢。

@ccpp132 #56 我一开始想问的就是在最大利用 MQ 特性实现异步“ RPC ”的特性的同时，他俩效果有什么差距，我也并不想鼓吹队列多么多么好，只是上面很多人回答的不到点上。

@ccpp132 #56 你是用传统 RPC 和由 MQ 实现的“ RPC ”直接进行比较，我想的是在微服务中他俩效果有什么差距，我并不希望由 MQ 实现的“ RPC ”是同步调用，本来就不符合队列的特性，只是利用它来传输信息并异步返回数值，同时拥有 MQ 的特性。

@ccpp132 #54 额，这样理解的话，连接数据库也属于一个 RPC 了。
关于检查成功、重试等问题，也是事先想到了，因此性能肯定不如直接传统 RPC 调用，一开头我也说了。
也正因是如此复杂，所以带来了队列的一些特性，开头我也说了。

@ccpp132 #51 1.一开始括号里我也说了，指的是以传统 RPC 来比较。2.为什么要通过 RPC 把消息放入队列，直接用消息队列的驱动放进去不好吗？

@l8g #41 我没说 RPC 是用来解耦的，难道拥有解耦的特性不好吗

@NewDraw #45 大家都认为传统 RPC 的主要功能就是同步调用，但是使用同步 RPC 调用本身就是高性能编程的大忌（指无协程的语言），我想用队列实现类似 RPC 的功能 其实更想要的是队列的特性所带来的好处。

@petelin #38 传统 RPC 没有消息冗余、解耦等队列的特性