@ryd994 我就是在 win server 上开存储开虚拟机，当然没钱买正版授权上淘宝买的序列号，勿喷。

@zhhmax 刚才忘了说，与其关注有 smart 实时通知，做好整个服务器的散热以及环境控制，这种即时同时在个人使用场景下其实也可有可无了，硬盘做好温控和避震，一块就能用好多年，做好阵列隔两散年主动换下其中一块盘整个阵列挂的几率大大降低了。

@ryd994 你说的这个确实没问题，回归一下实际的场景，楼主是找一个平台做一些 all in one 的事情，你说的是单个 nas 系统的事。zfs 有 snapshot ，hyperv 也有 snapshot 。我们再来考虑一下在具体实施后各个虚拟机的扩容以及迁移问题，硬盘直通给各个虚拟机，存文件后的剩余容量能否有效利用，以及后续扩容时的操作便利性。与其关心各个虚拟机的直通后硬盘监控以及备份扩容，那么让 Windows 去管理所有磁盘创建一个阵列，在后期的维护性上是否更省心呢？还有就是 smart ，nas 系统确实自带可以做到即时通知，不过在选购硬盘时就考虑好采用不同品牌硬盘或者同品牌不同批次创建好合适的阵列，那么硬盘出故障后，迟几分钟或者几天知道有何不可，不会有人搭建好 nas 从来不去系统看一眼就等系统监控发出邮件通知再去进系统查看吧。保护数据安全解耦和后期维护很重要，前期的方案也决定了后期维护的复杂度。

@jonsmith 这种方式确实简单，gpt 上 iOS 没多久站内就有人发了，不过后面看站内好多人都反馈这种方式最后翻车了，尚不清楚具体是什么原因。

@YICHUJIFA 用你的账号，我只需要第一次绑我的卡到你的号上操作时登陆一次你的账号。

再多说一句硬盘直通问题，我之前在家里的一台全 ssd 服务器上用 hyperv 开了六台服务器搭建过大数据集群，然后虚拟机的硬盘是用的虚拟硬盘，在虚拟机里测试文件读写速度和 win 里面测对应的那块硬盘读写速度没差。如果 win 上搞存储池的话虚拟硬盘可以随意移动备份还原只需要关注这个虚拟硬盘的备份恢复问题，如果把硬盘直通到虚拟机内部的话你要考虑硬盘故障后应急预案了，以及虚拟机内部的文件格式问题（比如说群晖的文件协议，增加了维护复杂度）在数据恢复方面引发的风险。

@dknagi esxi 在网络上的内容确实要比 hyperv 多，我们现在的需求 hyperv 和 esxi 其实差别不大，硬盘直通网卡直通这俩性能没有特别悬殊的差异。不过多说一句，如果你后面要引入显卡直通就得重新考虑了。

@rainbowStay 我们可以讨论更严谨一点，这个 kafka 如果连接的是两个不同的系统，那么你说的无法通过 ID 得到完整消息确实是个问题，保存 ID 的时候可以做到把这条失败的完整消息再保存到其他地方而不用再考虑重发问题。如果是上游的消息生产者也是自己内部系统，只能在消息队列中才能得知完整的消息内容而无法通过 ID 再从其他途径得到同样的内容在我个人看来是属于重大的设计缺陷，即便是这样，那也可以换个方式，新建一个队列把失败的消息放进去让消费原来消息队列的任务也监听一下这个队列就可以了，那么新的问题又来了，这样做到重发了，但是如果任务一直处理失败会不会放大数据量引发其他问题，比如说某段时间某批数据永远无法处理成功而一直重发会不会影响到其他批次正常消息的处理效率问题。

@rainbowStay 不用重发了，因为消息已经发成功了，有 ID 就能通过其他方式拿到完整消息的，要是消息再发一遍就重复了，这里和消费已经没关系了。楼主的异步处理消息的方式已经决定了不能再有重发消息的步骤，不然处理消息的那部分逻辑还得加上消息是否是处理失败的消息，增加代码复杂度。

@dknagi 那你这个跟我的需求差不多，我是 winserver 宿主机，共享用 smb ，mac 上挂载上去速度也没问题，特别重要的文件是用 resilio sync 在三台不同位置的电脑实时同步，我也有收集影视资源的习惯，单独一块大容量盘用 smb 共享到 mac 上看，然后 hyperv 启动也几天虚拟机满足其他需求。硬盘是创建了不同规格的存储池应对不同安全级别的数据。我感觉这一套下来要比一些成品 nas 灵活一点，运维也简单，win 远程共享不挑客户端。至于不同虚拟平台的性能问题我没有考虑，因为我没有需要极致性能的使用场景。

全篇没看到你准备拿 NAS 具体干哪些事情，存照片还是影音库还是还是文件服务器，其他设备都是什么，对应的系统和平台都不清楚。

我以前也折腾各种方案的 NAS ，现在的我会选择这么做：宿主机用 Windows server ，然后在系统里面组一个存储池，用 hyperv 搞虚拟机。这样的好处是，你可以根据不同的数据要求配置不同规格的存储池然后给虚拟机去用，硬盘出现问题也能直接挂到其他 win 主机上处理数据。文件共享会采用 smb ，照片库影音库再找方案开虚拟去实现。

@oppurst 不行的，用实体注册的 stripe 去放在个人网站审核不会通过的，而且申请开通支付宝微信的时候这俩也会审核一次实际运营的业务，不知道楼主收款的具体内容是什么，我估计难度不低。

办法很多，比如说消息 ID 放到 redis ，处理成功就去更新一下 redis 这个消息的自动过期时间等自动过期就行，一直没过期的就是处理失败的，如何确定一直失败呢，消费一次计数器加一即可。这样也不影响其他线程消费队列导致阻塞。失败到一定次数还可以加入其他逻辑人工干预。

@googlefans 理论上没问题，这样做账号也比较稳定，不过有些厂商的 IP 可能没解锁 GPT 的服务或者 IP 段被拉黑了就不太行。

我用的比较多的就是代码相关的东西，GPT4 回答的准确效率高，3.5 写个小脚本还行。

@sighforever 目前最简单的就是 Apple 或者谷歌的订阅，不过最近看站内这种方式封号的案例还是挺多的。我这边既有 API 服务也可以代付 plus ，可以看看我在这个帖子 https://v2ex.com/t/982658 14 、53 、67 楼的回复。代付 180 元/月，价格没法与其他同行卷，美卡+原生 IP 为你的 plus 旅程保驾护航，昨晚又为一位 v 友丝滑开通 plus 订阅，API 价格可以看看历史发帖。

@zpaeng 服务器在哪无所谓，一个后台服务和一个监控收款的服务，监控收款可以在手机上监听也可以电脑上安装监控服务。

@appreciated 咸鱼淘宝去搜一大堆，直接国内给你寄卡到家，坛子里面好多人也在出这卡。