各位大佬，事情是这样的：前几天有个初学者朋友问我关于高并发的技术，这个话题有点大，在微信上简单跟他介绍了一些，然后想着周末抽个时间详细写出来，我列了一个提纲，大概这样展开：
应用程序本身：

套接字编程技巧
经典多进程、多线程并发
IO 多路复用：select => poll => epoll
协程
内核参数：fs.file-max 以及 ulimit fileno
跟操作系统和处理器架构相关的，比如 SMP MUMA CPU 缓存等
etc

负载均衡架构：

为什么要负载均衡
nginx
haproxy
lvs
dns
会话保存
均衡手段和策略
etc

数据库优化：

SQL 调优、索引调优
读写分离
查询缓存
数据分片（分表分库）
etc

关于高并发方面，我目前知道的套路基本就是以上列的这些。我自己工作后这类场景涉及不太多的，肯定有疏漏，有经验的大佬帮忙补充一下，帮我补全知识面
另外，由于我遇到的业务场景都不怎么牛逼，感觉也写不出彩，各位大佬有什么典型的应用场景也请不吝分享一下
我梳理完毕，把文章整理好后，也会回来分享
不胜感激~

都不是关键，关键应该是加钱🐶

他确实是想加钱，但面试时被问到这些没答好

查询高并发 跟 写入高并发，区别还是挺大的。
一般高并发还得搭配高可用。
除了编码技巧，更多的还有架构设计，什么扩缩容降级之类的。
而且理论跟实践差距也蛮大，我司的一个写入高并发业务，从最开始 Mysql/Redis 到 MongoDB 到现在 C++自己写 Raft 也折腾了好多年才勉强高可用了...

没错，这个话题确实有点大，涉及面也广。你提到的 [服务降级] 我记下了，多谢~

不如针对场景写项目、晒代码，否则极容易形成八股

再加一层硬件方面的弹性伸缩，单机应用性能再高也是有个明显瓶颈摆在那，能堆硬件完成更高负载反而是现实业务最需要的指标

没错，所以想跟大家收集一些比较典型的场景

嗯嗯，弹性扩缩容打算归到负载均衡部分讨论

加一层硬件大佬是指类似 F5 这种吗？

天天 oncall 离不开的只有 监控 p999 长尾
其次要说扩容 限流 熔断

监控测量 限流 熔断 确实被我忽略了，已记笔记，多谢提醒

高并发 ❎ 加机器 ✔️

嗯嗯，负载均衡部分就是讨论如何加机器实现水平扩容

mp.weixin.qq.com/s?__biz=MjM5ODYwMjI2MA==&mid=2649770551&idx=1&sn=2089df5a70b538fe6c2d5337ccc37c46&chksm=beccd94c89bb505afd3f466e6280f0d7cc223998803232a23a5930bf1176646c3cc86377062b＃rd

后台服务架构高性能设计之道

看看这个。

核心概念：以空间换时间

能分清串行并行并发就已经很强了

你们的并发, 都是 IO 并发吗? 没有人来聊聊非 IO 纯 CPU 并发计算吗?

是指并行计算吗？

这个挺全面的，多谢

话题太大了，具体实施要看业务场景。

是啊, 一个计算量很大的任务, 如何用到多个处理器核心来减少任务耗时

你这些太细了，高并发基本几个套路

缓存 + 异步 + 分区

真不是几句话能说清楚的

1 、理论上横向弹性伸缩可以无限加，
2 、 采用合适的技术或优化可以节省核数

高并发不得用 dpdk 吗，epoll 不行

你可以关注美团技术团队，里面有不少实践的内容，包括但不限于：

1.日志系统
2.高峰期下单和订单查询
3.广告系统
tech.meituan.com/

这些系统对可用性要求都比较高，加上请求的流量都很庞大
（刚才手抖发出去了）

没具体业务谈这个就跟太监谈上青楼一样

有业务加钱自然有办法解决， 到现在有哪个流量平台是被流量增长搞死的，caoz 以前写过一些文章， 当年 BAT 里以技闻名的 B 都搞过很多土法炼钢的解决方案

而且 c10k 、c100k 这种问题不是十年前流行的么， 现在还有人会问? 不都是八股么， 不要假想一些问题

期待一波大佬的分享

套路有很多，队列，CDN ，anycast ？
想要高并发，从浏览器-----中间设备-------服务器------数据库，各个阶段缓存
用队列削峰填谷，异步处理，提高并发
根据 dns ，src-IP ，cookie ，id ，做水平切割，画逻辑区做负载

不敢苟同。太监谈上青楼固然尴尬，但也有一句俗话：没吃过猪肉还没见过猪跑吗？有具体业务固然好，但这不是没机会接触嘛。

土法炼钢我觉得要他要传达的思想是业务第一，技术第二，毕竟技术是服务业务的，不能盲目追求技术。但这个贴我不想讨论业务问题，就一个纯粹的技术讨论帖，讨论实现高可用都有哪些技术手段可以采用。退一步讲，如果有更好的技术方案，我不相信他们会土法炼钢。这也是这个帖子的初衷，学习更多更科学的技术方案。

c10k 、c100k 我解释一下，算是一个技术发展史介绍吧，主要目的是让初学者知道技术是怎么一脉相承，一步步发展到今天的。

感谢各位大佬无私分享，好多大佬都提到了异步化和队列，我之前也干过。但最近几年都在打杂，竟给忘了，哈哈

其实没有具体业务场景经验，问高并发真的是很八股，基本只能听别人的经验和自己猜想的一些情况，心里不靠谱不踏实

的确是个问题，但有一些了解总比没有好咯

呵呵 屁事多。 队列能解决 9 成问题。

其实吧，你说第二句就行了，第一句说了有什么意义呢？不过还是谢谢你

就当图个槽， 主要是喷面试的。 还有就是你朋友既然是初学者， 我还是不建议你普及太多概念给他， 废脑子。

纯 cpu 优化算法呗， 减少 cpu 占用，还能怎么样？

我其实是想借此机会梳理个提纲性的材料，简单罗列一下都有些什么，用来做什么的。因为初学者想学也不知道要从哪入手，有个知识地图之类的指引应该会好一些

最好的方法就是堆机器

面向具体业务， 不是假设具体业务

初学者不需要学这个， 因为根本没有任何意义

架构和业务层的调整什么时候是一个需要面试才能入职的能影响的?

这是面试干活儿的， 不是面试 VP 或者技术合伙人

等初学者通过项目实践成长能干涉到架构的调整， 能去协调业务层配合的职级， 他就不是初学者了， 他也不需要再看这种

架构有大有小，比如说你负责厂里一个很小的模块，它可能不需要 VP 或技术合伙人来做决策，但不意味着它不需要支撑高并发压力。我也不认为干活的人就不需要懂这些技术，难道干活的人只配 if else 堆业务逻辑吗？退一步讲，从干活能干涉到架构调整，也需要一些知识储备吧？一个人不可能天生就会这些东西呀。

我不否认干活大部分情况下，是不需要用到这些东西的；我也不否认成长到能干涉架构调整时，这些东西早已掌握了，也不需要再看这种。但从前者到后者，起码有个学习过程吧？这个帖子就是想梳理一下，都有哪些技术点可以去了解、学习，仅此而已

看来国内真是人均手写 raft 的水平啊

怎么看出来的？感觉比人均水平差太多，raft 的原理是什么我现在都说不清楚，更别说写出来了……