@nezhaxiaozi1015 limit 行数就行

如果在考虑 mysql 扩展性，分库分表就行了

如果只是做简单处理，或者转发，单机基本就够了。考虑高可用可以起多个进程并发扫，以 update 状态 sql 的 affected rows=1 来判断抢没抢到

起一个进程不停查预约时间早于当前时间的行，扫到以后 update 状态然后进程内处理或者扔到消息队列里

mysql 扫表其实挺好的，简单好维护，时间加上索引就行

如果公司业务比较大，流量大，比较注重稳定性和性能建议用 tengine，小厂随便了，反正换起来成本也不高

minikube 安装的问题大多数都是没有科学上网导致拉镜像失败，你截图里就是

准备一个 http proxy，然后用下面的方式启动
minikube start --docker-env HTTP_PROXY=$http_proxy --docker-env HTTPS_PROXY=$https_proxy --docker-env no_proxy=localhost,127.0.0.1,::1,192.168.31.0/24,192.168.99.0/24

另外第一次启动失败之后，要 minikube delete 之后再 start，否则不会重新拉镜像

对于个人，囚徒困境，多说无益。

宏观角度来说，中国的国际竞争力靠的就是低劳动力成本。所以短时间内现状也不会变。

保重身体，及时行乐

有可能收不到验证码，大厂的应用还好，一般是两种情况，APP 图省事验证码和业务短信用了同一个通道，还有一种情况是小的短信供应商各家的乱七八糟短信放一起发导致一家被举报其他跟着遭殃

@xiaoshenke 你试试用 rxjava 或者 java8 自带的 CompletableFutrue 写个复杂业务试试，比同步模型写代码速度慢不知道几倍，java 只要不加协程，业务层就不可能大规模应用非阻塞模型

楼主这个问题从经验上看就是 tomcat 线程池跑满了，请求排队了。

这个问题可以这么确定，在系统高延时看一下系统的 cpu 磁盘 网络 内存有没有任意一项被打满了，没有的话就不要去优化代码了，调调各种配置先让某个资源打满再说

@neoblackcap 我就这么说吧 国内大厂 java 的业务层就没有大规模应用非阻塞模型的，原因是完全的非阻塞模型带来的性能提升一般也就是 20%，而开发难度的提升一倍都不止

应用层和中间件的技术选型考量是不一样的，应用层要兼顾开发效率，你当然可以说去用 openresty nidejs go 之类原生支持非阻塞模型或者协程的语言框架，但是这就是另一个技术选型的复杂问题了

@neoblackcap 一般应用根本用不着去抠线程上下文切换的性能消耗 而且业务层不是都能写成无阻塞模型的

@neoblackcap 你要理解同步模型和异步模型的区别

加内存缓存 提高 tomcat 线程数到 500
tomcat 一般都是 io 密集操作 线程要开大，不然线程都是 block cpu 跑不满

@dcsite
@kofip

大致可以推测出是单点，至少 SQLServer 是单点

把这种对单机性能要求很高的服务部署在阿里云上确实是很蛋疼。阿里云对计算性能的超售确实有些过分，系统如果不能水平扩展在确实不适合部署在云服务上。