前些天，朋友圈被一首歌刷屏了。
数据有多牛逼？除了揽获各大新闻头条，新歌发售3小时，数字专辑就在QQ音乐卖了360万张。以单价3元计算，一首《说好不哭》已狂揽千万，无人匹敌。
结果因为访问量太大，不少网友反映“QQ音乐崩了。。。”
在大家眼里，好像只有微博服务器是“不堪一击”的。那天晚上，QQ音乐持续崩溃，周杰伦以一己之力成为了干翻QQ音乐服务器的男人。
在这首新歌里，大家还意外看到“周五合体”。还原了经典场景，也掀起了一波关于青春的回忆杀。当回忆和回忆相撞，啪，泪花四溅。
歌迷有没有被感动哭我不知道，但是QQ音乐的程序员估计是要哭了。不奋战个一天一夜，怎么对得起嗷嗷待哺的歌迷朋友们。
诸如双十一淘宝瘫痪，明星恋情导致微博宕机事件，说到底还是“高并发”的问题。
高并发带来的后果
服务端：
导致站点服务器/DB服务器资源被占满崩溃，数据的存储和更新结果和理想的设计是不一样的，比如：出现重复的数据记录，多次添加了用户积分等。
用户角度：
尼玛，这么卡，老子来参加活动的，刷新了还是这样，垃圾网站，再也不来了！
程序员的经历： 在做公司产品网站的过程中，经常会有多样需求，如果没有考虑到高并发下的数据处理，就会出现各种超出正常逻辑的现象，因为这些都是面向大量用户的，而不是像做ERP管理系统只是面向员工。
回归技术本身，面对如此大的高并发流量和屡次崩溃的系统，程序员们如何抵挡？
提高系统并发能力方式
在这个“云”的时代，提高分布式系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。
1、垂直扩展提升单机处理能力。垂直扩展的方式又有两种：
增强单机硬件性能，例如增加 CPU 核数如 32 核，升级更好的网卡如万兆，升级更好的硬盘如 SSD，扩充硬盘容量如 2T，扩充系统内存如 128G；
提升单机架构性能，例如使用 Cache 来减少 I/O 次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间。
2、水平扩展
只要增加服务器数量，就能线性扩充系统性能。虚拟化技术的出现，让水平扩展变得轻松且简单。现在的云主机几乎是虚拟主机，而不是物理主机。这样的话，线性扩充也就是分分钟的事，前提是要有足够的物理主机支撑。
高并发的三个经典问题
1、单台服务器最大并发
单台服务器最大并发问题，一般是指一台服务器能够支持多少 TCP 并发连接。一种理论说法是受到端口号范围限制。操作系统上端口号 1024 以下是系统保留的，从 1024-65535 是用户使用的。由于每个 TCP 连接都要占一个端口号，所以我们最多可以有 60000 多个并发连接。但实际上单机并发连接数肯定要受硬件资源（内存、网卡）、网络资源（带宽）的限制。特别是网卡处理数据的能力，它是最大并发的瓶颈。
2、C10K 并发连接问题
C10K 并发连接问题是指单机 1 万个并发连接问题。如何突破单机性能局限，是高性能网络编程所必须要直面的问题。这些局限和问题最早被 Dan Kegel 进行了归纳和总结，并首次成系统地分析和提出解决方案，后来这种普遍的网络现象和技术局限都被大家称为 C10K 问题。C10K问题本质上是操作系统的问题。对于 Web1.0/2.0 时代的操作系统而言， 传统的同步阻塞 I/O 模型都是一样的，处理的方式都是 requests per second，并发 10K 和 100K 的区别关键在于 CPU。创建的进程线程多了，数据拷贝频繁（缓存 I/O、内核将数据拷贝到用户进程空间、阻塞）， 进程/线程上下文切换消耗大，导致操作系统崩溃，这就是C10K 问题的本质。
3、C10M 并发连接问题
C10M 并发连接问题指的是单机服务器实现 C10M（即单机千万并发连接）。回顾过去的 10 年里，我们面临高性能网络编程领域著名的 C10K 问题，最终也成功提出解决方案。下一个 10 年，是时候考虑 C10M 并发问题了。
在很多程序员眼中，掌握海量高并发技能，就能走上人生巅峰。
anyway，学得会就学。我倒觉得与其痴迷某些技术的尖端，不如解决某些行业的业务落地。
经典评论
1、操作系统上端口号1024以下是系统保留的，从1024-65535是用户使用的。由于每个TCP连接都要占一个端口号，所以我们最多可以有60000多个并发连接。我想有这种错误思路的朋友不在少数吧？（其中我过去就一直这么认为） 我们来分析一下吧。 如何标识一个TCP连接： 系统用一个4四元组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。好吧，我们拿出《UNIX网络编程：卷一》第四章中对accept的讲解来看看概念性的东西，第二个参数cliaddr代表了客户端的ip地址和端口号。而我们作为服务端实际只使用了bind时这一个端口，说明端口号65535并不是并发量的限制。 server最大tcp连接数： server通常固定在某个本地端口上监听，等待client的连接请求。不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4元组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。
这个也算不上大牛吧，会数学的基本上都算得出。不考虑端口被占用，ip地址分配的问题，理论上一台机器能够监听六万多个端口，同时每个端口可以被全世界所有的ipv4地址访问，合计就是 最大端口号乘以最大ip数，结果就是你电脑炸了。
操作系统上端口号1024以下是系统保留的，从1024-65535是用户使用的。由于每个TCP连接都要占一个端口号，所以我们最多可以有60000多个并发连接。我也觉得这个说法有问题，并发数指向的应该是占用一个端口号的服务的问题。
一个socket，更准确的应该说是一个socket对，指的是ip:port（发起方，客户端）ip:port（监听方，服务端），这是一个socket对，服务端可以固定监听一个serverSocket，这是端口监听的概念，可以监听65535个端口。当服务端监听80端口，那么客户端可以发起60000多对socket，加上ip变化，所以理论上服务端统一个端口可以接受到2^32（ip容量，ipv6不考虑）*65535个socket对。
2、这种适合最忙的不一定是敲代码的，应该是运维吧？运维是运维，程序员是程序员，不要混为一谈。
程序员会的运维基本都要会，程序员不会的运维也要会。
3、我在想，当服务器爆满的时候做个排队不行嘛，LOL周年庆经常排队。
不错的想法。
战斗之夜排队到100000
音乐软件啊，毕竟不是游戏，我打开这个窗口可能就是现在有时间想听几首歌，但是来个排队，肯定不妥噻。
Lol一开始也是没排队的，后面才加的。可能QQ音乐还没遇到需要排队的情况，毕竟一直都比较稳定。
4、为什么单机最大连接数和端口数量有关啊，一个服务不是开启一个端口嘛？
你说出了我的疑惑。
有关的，因为受限制服务器的端口。
5、楼主说的很对啊，要想工资多，就得有高并发问题的解决办法。
6、 我觉得也是尖端虽然重要，但是现实还是业务。
7、谁能看到幕后程序员的辛苦？只有同行们惺惺相惜吧。
8、话说服务器不都是多线程的吗，共用一个端口，何来端口数目限制一说呢？
9、林俊杰的 将故事写成我们，qq音乐也是炸了。
10、可能他们需要多台服务器去负载，毕竟每台机器端口号有限制。
閱讀更多 小陸老師 的文章
