写文章之前要先谋篇，写代码也一样。

并没有什么多套，要买就买全家桶

没必要特意去学一门语言。

语法没啥好学的，大家都是差不多的。API 也没啥好学的，用的时候利用一下搜索引擎就完了。但你需要去了解 go 或者别的语言的一些生态，要知道有哪些好的工具，可以帮你做什么。这个非常重要，不了解生态，就做不好技术选型，就会掉坑里面。。。

为啥要怼？你亲戚对你做了什么？

长辈面前不妨乖巧一点，说一句：谢谢，我知道了。这不就完了吗

20 万+。

长 /短连接指的是 TCP 的链接，http 是在 TCP 链接之上的一个传输协议，这两个链接不是一回事。

你可以把 TCP 链接看做机场的行李传送带，http 链接就是传送带上的行李箱。所谓长连接就是用同一条传送带传送不同的行李箱，短连接就是每传送一个行李箱都换一条传送带。

先求移动平均值，这样应该就可以把抖动消除了。

出了问题第一个永远就是让前端背锅排查

这个完全正常，有问题需要先从前端开始排查定位。别的问题其实后端也有类似的，譬如产品需求大改，先跳起来的肯定是后端啊，他们前面通宵写的代码全都作废，前端倒是经常是小改动。

人太多，基站连接数满了你就连不进去。

万人同屏，肯定要在渲染上面偷梁换柱。。。

老板估计已经放弃了。

@xuanbg sql 复制过来忘记改了，15 楼的是正确的。

@saulshao 你这个不等价啊，人家是每个型号 1 条，你的可能 3 条都是 1 个型号。

正确答案是使用 union all 关键词。

SELECT 生成时间 FROM result WHERE `型号`='1' ORDER BY 生成时间 DESC LIMIT 1 union all
SELECT 生成时间 FROM result WHERE `型号`='2' ORDER BY 生成时间 DESC LIMIT 1 union all
SELECT 生成时间 FROM result WHERE `型号`='3' ORDER BY 生成时间 DESC LIMIT 1;

text 这种属于历史遗留，现在已经没必要使用了。

其实我的建议是：超过 4K 的数据使用对象存储才是正经。2-4K 的数据如果数量较多(10w 以上)，建议使用 NoSQL 。

@feelapi 用这个方案估计大家都不能愉快滴玩游戏了。。。

可靠性越高，系统复杂度就越高，可用性也就越低。游戏嘛，还是回档+补偿就完了，最简单。研发满意、策划满意、运营满意、玩家满意，你还有啥不满意的？

首先，这个不是幂等性问题。有 3 个办法可以解决这个问题：
1 、前端防抖，按钮点击后立即禁用，等接口返回后再视情况启用或跳转页面。
2 、后端限流，同一来源在一定时间间隔内只允许调用一次。这个方案的好处是通用，且可以顺便减轻接口被非法调用的压力。
3 、使用令牌，前端提交数据前先获取一个令牌，后端限制令牌只能使用一次。

电磁炉一定要配那种厚厚的铸铁锅，否则锅底都烧红了，锅沿还是凉的。这种受热极度不均匀的情况下，炒菜你就别想了。

在接口响应特别慢的前提下，是应该先返回一个任务 id，然后用这个 id 轮询另一个接口获取数据。