大多数人一辈子都接触不到淘宝双 11 流量冲击？那么我们怎么去锻炼这样的能力？

[ppllss]

很多时候我在想，在写业务的我，怎么去提升自己，我毫不犹豫的回答自己那就是庞大的用户基数和每时每刻数以万计的流量产生。

但是我们会遇到吗？也许（肯定）一辈子都遇不到吧。

平时去实践都是写一个 demo ，更别谈数据量了

比如我们把用户基数划为几个等级

1. < 100
2. < 1 万
3. < 10 万
4. < 100 万
5. < 1000 万
6. < 1 亿
7. < 10 亿

我相信你没有接触过更高等级的用户基数，你可能会忽略这方面的可能会采到坑，比如代码，表设计，中间使用等等。。

无论我们怎么去模拟和实践，我相信现实问题，永远比你模拟的问题更加出乎意料。

我也不是怂恿大家一定去大厂

我只是觉得大家要接受一个平凡自己罢了。

[pupboss]

接触到又能怎么样呢？ 5 年前研究出来的方案已经很成熟了，现在只要做好流量预估，各种预案，按照图纸施工就行，也挺平凡的

[julyclyde]

既然都遇不到，何必要锻炼呢？

[murmur]

淘宝已经觉悟了，双十一搞得大家都不爽，现在是从 10 月促销到 12 月，说明技术钻牛角尖还得用业务化解

[Building]

不可以模拟吗？

[Mirage09]

这种能力也就是在面试的时候画虎烂罢了…

[Thresh]

@pupboss 说的对。我是感受过的

[xunxuntj]

人生苦短，用在有意义的事情上
没有目标的精益求精，就是内卷

[MacDows]

为什么要假定一件不会遇到的事情呢

[hyq]

根据我的经验总结，只需要牢记一些常识就行：
1. mysql 的 tps 你就按 5000 算，每秒超过 5000 请求，直接用 myql 肯定不行
2. 单机 redis 的 qps 可以到 100k ，把一些数据 /缓存，存到 redis ，能有效提高并发
3. 利用消息队列实现削峰，实现生产与消费的解耦
4. 保证处理逻辑可以并行，可以扩展，谨慎使用锁
5. 尽量将服务做成无状态可扩展的，把状态扔给 redis 或者其他高效的存储

[hyq]

6. 对于频繁访问的数据一定要做缓存，然后去解决缓存的雪崩，穿透，失效等问题

[totoro52]

又被公众号洗脑了？

[lscho]

遇不到为什么要锻炼呢？很多能力都是在解决问题的时候积累的。遇不到问题，只锻炼是不行的。

[shyrock]

屠龙之术，习之何用

[js8510]

10 亿以上用户的的服务也有很多啊。。。google.com, facebook.com. IG. Twitter, amazon.com ....

service scale 大了以后，却是有很多问题是之前无法想象的。。举个几个简单又常见的两个小问题：
1 ） 很多大型服务开发周期长，参与的团队太多，时间久了，executable 太大了以后会造成很多困难。比如 compiler overflow ，OOM 等等。
2 ） 有时候遇到一些 bug 会很难复现。比如你有 100k 台机器的时候每天都有一两台有相同的 crash stacktrace. 你明明每天都看的到，但是因为 1/100k 太小了。logging sampling 往往没有那么凑巧可以抓到。结果就是往往每个大型服务都有一些长期修不好的东西。

[sadfQED2]

😂😂别觉得这么大的流量用户量有多牛逼，你接触以后可以会感叹，这屎山代码居然还能跑起来，还没挂

[utyyyreee]

中国人不骗中国人 😁

[wonderfulcxm]

不锻炼，就用 ab 测试一下

[CoderGeek]

经历 6 次了 不想加班 - - 想回家好好睡觉

[cat9life]

各自媒体吹的太猛了 仿佛“抵御”了双 11 。我们就是全球第一

[jones2000]

这个不需要锻炼， 砸钱买机器加带宽不就完事了。只要构架不太傻，支持分布式，剩下的就是钱的问题了。没钱再高的能力也没用。