@namaketa #41
HP 那一堆卖不卖 hhh

@ps1aniuge #33
现在 X86 服务器也已经这么操蛋了
服务器的 BIOS 已经不在乎什么可用性了
我这有个垃圾服务器 1.5TB 内存，不是 GB，启动过 BIOS 要 6 分钟，才能交给磁盘引导系统。
进个 BIOS 也没法绕过自检。

我的小型机还都很新 不是旧架构的

来源：
某银行傻屌信息负责人采购，我们给了一套私有云，然后他跑数据库非得要小型机，然后用了各种我怀疑是 1990 年资料论证了小型机性能是 X86 的 10000 倍以上，最后我们强行卖了他们几套小型机跑 oracle


然后呢，不巧，小型机集群故障了，有 oracle 备份数据，而技术支持排不开要很久才能来，边缘业务系统虽然不超级敏感也不能停好几天。他们一线的 oracle 维护决定，从我们私有云上开几个大规格的 VM，把 oracle 弄上面去运行。

因为我这边全 SSD 的存储，本地缓存都是 NVME 的，IO 性能爆棚，结果就是，临时应急的这套 oracle 上线以后，原来用小型机做一个账务处理要分钟级，现在变成了 3 秒左右……

然后信息负责人死性不改等小型机修好了又要迁移回去，迁移回去第一天，所有一线业务部门全不干了……

当然国企，有很多领导关系户，去找领导了……

然后小型机就报废了

@namaketa #10
亲，你还要这种小型机不，我用几台换你的一堆 X86 垃圾……

全部管理暴露公网的飘过……
这样才能促进更安全

@yangyuhan12138 #40
其实，这点量，我们都没高度依赖 redis 的特性

当时是用阻塞语言写的，redis 就缓冲一下快速给确认，完事都怼 MYSQL 里去了

在前端和后端都做了特殊的优化，适应比较低性能的硬件解决问题 甚至很多逻辑都不依赖后端

跟你这个有关的，比如超时不能支付这个事，都不依赖后端。限时秒杀的接口是有验证码，有反秒杀器的逻辑，跟正常下单入口不一样，这里会生成特殊的订单号，自身验证支付有效期，能不能跳转支付网关选择，能不能拉起支付接口

而清理订单，依赖一个 delete from orders where STH limit 1，这个功能调用一次删 10 个过期订单，这个异步功能集成到了没一个非秒杀逻辑请求里，就是说，只要有一个人访问一次整个系统，就会删掉一条没用记录

这个逻辑，这个并发量（不超过 70 万的订单超时），曾经 MYSQL+redis 就无性能瓶颈抗住过
我觉得你的超时流程，在程序这边逻辑设计有问题

楼主是不是野鸡电视台专家荐股看多了。。。

@misty8873 #68
TG

取决于你的应用性能。

应用写的好，且 IO 不密集，4C16G 轻松 handle

你要是应用写的性能渣，那就没救

不懂你们 JS 程序员的引用方式
难道不精确限定版本么？

@wangxiaoaer #43
网络成型翻译都不是用来翻译单词的
翻译单词请找词典类软件

基本所有的翻译类东西都是基于机器学习的

openjdk 不香么

不画画，买山寨即可。

用公共 stun 就完了
本来 stun 协议就是公共服务

@bsder #55
刚不动 虚商 死猪不怕开水烫