数据中心，2U 机位费，不是重电力消耗的，一年基本费用也就 6K，基本能 12 盘，如果用 2.5 盘就能 24 盘 （以上均扣除系统盘）

然后就看你要多少带宽了，100M 一个月 1000，一年一万二

这么多客户这点钱都分摊不开的话，也不容易……

另外，这个业务基本收费是 3 万左右 /年

@Liang #6
你不会找的是电话客服吧……
那是处理消费者业务的

基本所有行都有接口，全对接过。
部分行在公网就有接口文档。

至少你得开收单，才能有权限访问吧

大字幕组翻译屏幕文字的技术么...

坐标哪里？如果近我公司下次定制电视给你带一个……

@cubecube #222
shift+数字，右手符号，基本不错，键盘别太垃圾，才能达到英文大篇文章输入 360kpm+的速度。

@kidult #30
哦对 忘了一个事
阿里腾讯备基本都是跨管局，很多管局处理跨地区特别慢……

天天给别人备案本省备本省主体都是次日，忘了普遍情况了

域名备案只要一天啊

@shoaly #12
域名备案信息一直是开放给公众查询
但是开放 API 给公众，反正我是看不到任何理由，除了被非法人士采集，或者自动化做什么坏事，我看不到任何应该开放的理由。
而对服务商，API 一直是开放的，随便查。

现在的键盘不太好，正常应该是能 380kpm 的。。。

让我看键盘我就不会打了

https://i.imgur.com/iB644cs.jpeg

@shoaly #8
IDC 飘过
所有接入单位都有接口的，可以直接查。
对公众开放这个接口没啥卵用

@crclz #35
15 年前做一种特殊的秒杀（不是卖东西，但是逻辑跟秒杀没区别），那时候还没有 redis，没有 memcache 。
当时的方案是纯 MYSQL，那时还没有云计算弹性扩容
当时就可以很容易的解决秒杀问题，而且严格不能超售。
多开 webserver，mysql 堆 ram 扩大连接数不让他死掉

比如秒杀商品是 100000 件每人限购一件限购一单，直接预先生成 100000 个订单，不在主订单表内，每个秒杀做一个独立的订单表，引擎 memory(heap)

简略的单一项目秒杀独立订单表如下
order_id user_id，……………………其中 user_id 挂唯一索引

所有订单 user_id 预先都设置成 0
秒杀逻辑就是大家拼命往里堆执行
update [table] set user_id = [Your user id] where user_id = 0 limit 1;

秒杀完成后（ 30 秒级），直接预置一个逻辑，把这个特殊表按规则合并到主订单表

缺点就是，30 秒内，[我的订单]看不到秒杀成功的订单……


如果不想依赖手速网速，或者不像搞死最大连接数只有 800 左右的单机 MYSQL，就在前面下概率控制，随机数有一定概率往数据库里写。随机数可以引入时间加权。

@libook #9
1.1.2 > 1.1.10 这都不算啥，毕竟可以人肉控制小节最大是 9
11.1 < 2.5 才要命

@Showfom #62

所以我看之前那些搞笑级别的回复，真的一头雾水。
DNS 协议层就不需要这些，碰瓷概念非得给搞出来

我这边做过本地大项目的 DNS （不是互联网项目，民生刚需项目，天天访问量恐怖），因为主要服务省内，所以省内两大城市两个最小的 VPS，阿里云腾讯云 2C4G 两个省外备份，轻松扛下来。

基本一天就运营商的递归 dns 请求一些记录，以及极少数瞎改 DNS 的境外请求

@Showfom #59
对国内，十亿 PV 每天的项目，三个最小的云服务器 2C4G 啥的都能 handle，轻松加愉快
实际生产环境 handle 过
也不用集群，dns 集群，高可用啥的都没啥用，对 dns 这种东西根本不需要集群也不需要负载

一个数据库服务器兼配置器（记录保存器），多个最小配置的 vps 作为 dns 服务器，分布在三个供应商的不同地区机房就够了