看起来你的消费者是一个单进程？那样的话我觉得写一个全局的令牌桶然后按请求限流那样做比较方便，kafka pull 消息的时候是可以指定最多拉多少个的。

1000qps ，根据你的查询复杂度和数据量，从一个 4c32g 小机器就能绰绰有余，到一个 10 节点集群都扛不住。一切皆有可能

@drymonfidelia
你不应该用数据库做这个工作，这种事情很适合用本地 Log 存储。例如说微软自家的 https://github.com/microsoft/FASTER 。每次收到消息就写入提交，然后你本地多开几组 Task 去处理本地日志就行了。

自己搭的

我们用 loki ，便宜

消息队列还是用老牌的 kafka 靠谱

@gangsta include 是可以包含目录的

@CY4suncheng 准确来说我是不使用在线图片的，而本地图片管理我头疼的就正是全放在一起很乱，而每篇文章都单独搞一个文件夹也很烦。而且不方便在 ob 里直接管理

ob 我之前尝试最大的问题是图片附件管理起来实在不合我的喜好，不知道有没有插件能改这个的

@TESTFLIGHT2021 new 那是堆空间当然没问题

@huage
看 calico 的文档吧。metallb + calico BGP 可以实现你想要的功能。配置略微复杂且在云上配置比较麻烦，一般本地部署用，云上就还是老实的用云提供的 LB 。

你是否在寻找: calico BGP mode

我可以非常肯定，按你们那么玩，go 性能也不会比 C#好。asp.net 的性能是能和 rust 的一些库掰掰手腕的，哪能是 70qps 这么拉的

我觉得吧，就 Electron 一把梭吧。

我选择用 blazor server 一把梭 (

@rekulas
因为写业务有更好用的语言，那不当然显得 Go 麻烦嘛。

@coder001
说不定你再改改配置和 GC 选项，连重连都没了（

@coder001
以我对 IOCP 的认知，Windows 上应该不会发生这个问题。因为 Accept 慢主要是慢在创建 Socket 上，而 IOCP 创建是系统内核在处理这个问题，不会拖慢应用。
至于 Linux 上，鉴于我对 epoll 的熟悉程度不如 IOCP ，所以我不是很确定。但是曾经读过 devblog 的文章，里面表示 Linux 上的实现是 epoll + 线程池，所以我觉得可能也没有你担心的问题，可能。

@coder001
aspnetcore 的代码可真是不容易看懂，稍有些绕。这个自定义处理 Tcp 我还是在 SignalR 的源码里翻出来的 (
不过后来我就直接用 ws 了