@BingFoon 小兄弟你不讲究，拿 linux 和他们 windows 比，这不纯凡尔赛吗

应该皱紧眉头

@cathedrel 那就不知道了，除非实际调试

@cathedrel

本地没啥问题，看看你的交换机，是不是 1 个 G 口 1 个 100M 口，把 debian 的网线插到台式机测试一下，看着是交换机限制到了 100M

网卡启动加载上了，ip 也分配上了，驱动也 r8168 没问题的，自信点

在下彦祖，rust 可以 web，有框架

用 crc64 可以小一点，md5 得 32 位 char 做索引，然后 hash 拆库

@cathedrel 发 imgur 的图片不用空格，v2 会直接解析显示图片

我查了一下，看看你的内核版本

uname -a

我看到有人和你遇到同样的问题，内核在 4.18.16 修复了

如果升级内核还有问题，看看 dmesg

dmesg | egrep -i '(enp2s0|8168)'

@cassyfar #43 100 万 qps，具体什么业务，还是你们被人 cc 了

其实全贴没人假设必须是在单机

要么网卡有问题，要么驱动有问题

ip address show enp2s0
ip link show enp2s0
lspci -kv

上面三个命令的输出看一下

@lewis89 bbr 当让不是万能的，满负荷下 bbr 还可能降低发包能力，但不至于自己设置窗口扩大缩小的策略吧，能改窗口，又觉得没几个人能手写 epoll，看来你是写 C/C++，做驱动开发的吧。应用层开发不会动 tcp 协议层，现代所有业务开发语言都支持异步和协程，很简单的语法糖。你说的手写异步模型超纲了，再说下去我就要开始改电路，处理 INT 中断，做真异步了，告辞

@lewis89 线程和并发不一定是 1 对 1 关系，同步任务是 1 对 1，现代 aio 下，协程 epoll 可以做到单线程多并发。

@lewis89 根据你说的饿了么订单这类及时任务，拆分业务，分表，是唯一选择。可以从 DNS，LB，业务才分，hash 分表，数据库集群解决，我没说有问题。

@lewis89 你不用发这么多问号，不同业务有不同的处理办法。#8 的业务是发送短信，短信任务入队列削峰是正确的方式，现代短信发送一遍是 http 做接口调用，不仅有单机 100k 接收请求问题，还有单机 100k 发送 http 请求问题。

@lewis89

#7 我补充一点，不知道对不对

限制单机，100k 的 get 。
由于 redis 从内存读，所以内存没有限制。
主要是 cpu，假如单机 cpu 不够的话此问题无解，除非升级 cpu 。
带宽问题需要保证，一个 get 10 字节，100k * 10 = 1MB/s = 10Mbps，100 个字节就需要 100Mbps 。
linux 可使用端口一般默认为 32768 - 60000 之间，可以通过 sysctl(/etc/sysctl.conf)修改 net.ipv4.ip_local_port_range 增加更大范围，1024-65535 。但这样会存储一个问题，假如 3306 被 redis 分配掉，你再想启动 mysql，只能手动释放这个端口，然后启动 mysql 。这里只是举例，这种负载情况自然不建议单机起多服务。
由于大量短连接会造成系统大量 TIME_WAIT 的端口，导致端口不可用，可以通过 sysctl(/etc/sysctl.conf)的 net.ipv4.tcp_tw_reuse 来快速重用。
大量链接下系统 nofile 会快速占用，debian 系默认通常为 1024，通过修改 ulimit(/etc/security/limits.conf ）的 nofile 解决，需要注意的是它是用户的 pam 限制，需要给启动 redis 的用户增加此选项，可直接修改全局文件全部增加即可。
关于 redis 磁盘落地问题，使用三星的 1T pcie 4.0 接口的 nvme ssd，顺序读写基本在 3GB/s 以上，随机 4k 读写可达到 500k 以上，是读和写，感谢时代。
网络拥塞问题，debian 系可以直接修改 /etc/sysctl.conf 文件的 net.core.default_qdisc=fq 和 net.ipv4.tcp_congestion_control=bbr 来抢占发包。rhel 系自行升级内核到 4.10 以上，我说的就是辣鸡 centos 。
由于现在 aio 一般使用 epoll，C10K 导致大量上下文切换，可以使用最新 linux 内核 5.1 以上，使用 io_uring，根据有关评测，系统调用只有 epoll 的 1/10 。


同时回答楼主，扩展到 10 倍或者 100 。做横向集群扩展的时候，压力在 LB 的 hash 均匀分配和性能上。同时可拆分业务，通过 LB 或者 DNS 分配到不同子集群。

@qwer666df
@lewis89

#8 属于削峰问题，正确的方法是入消息队列，前端线程只做任务入消息队列，后端线程消费任务。前端 cpu 爆了的话只能横向扩展机器，由于只入消息队列，所以是可扩展的。

@liuxu 我是说后半部分，k3s + helm

公司的项目用的 gitlab + gitlab runner + docker-compose
我自己的项目用的 github + github actions + k3s + helm

目前建议用我项目的方案，我也准备给公司的项目迁移一下

apache 查查对应的文件，应该也有

nginx 有 access.log 日志，默认有 body_bytes_sent