fuxiuyin

@wittyfans Support Engineer 基本上就是售后

最简单的 hyper-v 网络就是创建一个 internel 的 switch，然后加一个 nat 。直接搜 hyper-v internel switch internet access

要不来试下 .Net

@chonger 这个是习惯了网购收到货之后什么都不管的人吧。

@fuxiuyin 呸，纠正下，我是 x570

不知道是不是普遍情况，我也是 x470 主板，不过我有两块网卡，l211 和 Realtek 。用 l211 的时候，好多软件网络用到 50-60MB/s 之后系统就开始卡，百度云，bt 啥的都是。Realtek 的没感觉出来，难道说 intel 喂毒了？

@fuxiuyin 发出去了发现最后那个少了一点，要求接收端给回应的话，就是两边互发 promise 。发送端发个 promise，接收端收到以后回个结果的 promise，然后两边异步等 promise，balanala 。

我觉得这个问题应该分成三个，一个是发送者发送到消息队列可不可靠，一个是消息队列发送给接收者可不可靠，第三个是接收者接收了之后处理的可不可靠。第二个问题不用担心，可以简单相信消息队列保证了“至少一次”。第一个问题简单解决就是发送者先写一个数据库，然后一个线程发，或者发送者弄成全异步的，通过 Task 来 track 一条消息。第三个问题就直接接收者全处理完了再给 mq 回 ack，或者接收者先写个 db 回个 ack 再慢慢处理。这个问题的重点在于不要让消息 lose track，一直能够 track 到就不怕细小的问题，因为随时可以有人来查看恢复。比如，发送流程都很好，接收者成功收到以后挂了，然后消息丢了就不好办了。mq 是一个异步和解耦组件，异步了就要在发送者和接收者都保存一些信息。同步状态下只发送端保存，接收端挂了就挂了，发送端保存了还知道接收者处理哪条消息的时候挂了，于是重来就行了。多说一句，其实点对点的发送接收做异步的话也不一定非得用 mq 啦，可以学异步 rpc 那样发 promise 。发送端发个 promise 就走，接收端把 promise 放到监听对列。发送端啥时候闲了，或者 promise 太多了，或者其他线程，去发 promise 的实际内容，接收端等哪个 promise 好了就处理好的那个。