现在的键盘不太好，正常应该是能 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 服务器，分布在三个供应商的不同地区机房就够了

没你想象那么复杂……

多建几个，不需要集群，增删改查时候，多个服务器都应用一遍即可……

@0o0o0o0 #9
看起来像是一种坐标系的数据点

抛开 49 秒的问题，你这 SQL 应该回炉了

@ShuoHui #15
我有说这个事情跟我个人以及我的公司有任何关系么

我只是告诉你，事实上，这个就是羊毛出在羊身上。
你看看给码农个选择，他们选择用正版不。

不是针对楼主提到的问题
针对 1 楼 5 楼说

这个还细？
难道你们做的系统 URL 里改一下订单号就能看别人订单？

@whywaoxaks #8

羊毛出在羊身上

@villivateur #23
都是 iframe

@powerman #38
李老鼠最近几天做了日系法系美系二手车的大坑，你可以学一下
虽然李老鼠其他的不咋样，这三期基本没毛病

@powerman #10 十年马六比你说的那几个车配件还满大街……hhh

明码标价看看值不值当

@xuarong #6
我认为也是我自己授权的，支付宝又不会给爱奇艺做嫁衣

但是因为什么授权，授权时候是让我干什么，我绝对不会去开任何爱奇艺会员