高并发是工程师老生常谈的事情。高并发简单来讲就是是服务器端，能够及时响应每秒成千上万次的请求，并且没有任何异常。博主根据自身的工作经历，在接下来的几篇文章中，从矛(爬虫)以及盾(服务端开发)两个方面来聊聊高并发。本篇是主要聊矛
先瞎聊几句
- 关于爬虫(网络爬虫)相关的一些概念，请读者自行google。
- 爬虫的主要功能：本质上还是数据采集。
- 本篇文章只是博主的个人见解，仅供参考。大家还是要做个盾法的公民，违法后果自负。
一些前提
- 工具语言使用python（python中线程对于Io基本是单线程，所以考虑进程+协程）
- 假设网站服务端支持QPS是无限的(1s返回结果)
- 数据库存储采用mysql（写入QPS 2048/s）
- 机器是4核8G. 最多支持开8个进程，每个进程可以支持开256个协程。即一台机器的最大并发是(8*256=2048/s)(这个已经算很高了)
- 需要采集10亿个网页数据
- 爬虫执行的任务都是去重后的(去重也是一门学问，后面细聊，本篇不作为重点)
- 不使用代理也不会被风控掉
最原始的爬虫架构（单线程）
- 目前看1/s，一个小时也就采集了3600个网页，对于我们实际需要的10亿条，大概也就跑个760+年吧。看来这个可以做为老祖宗的遗产了。
疯狂的多进程+协程
- 这次我们直接放了大招。直接在一台机器上开了多进程+多协程。我们现在的抓取速度是(8*256=2048/s), 正好是mysql的写入qps，勉强可以。那我们需要多少135天。基本4个月. 怕是跑完之后公司就gg了。
我想飞起来
- 上面就是 加了3台机器( 我们现在需要大概1个多月(前提是入库的速度与抓取的速度是一致的，不存在消息堆积)，也可以再加机器，加个100台，2天就给你跑完（这只是假设的场景）)。
- 上面还多了三个东西。
- 消息中间件集群(一般kafka即可)
- 消费者服务
- 存储服务集群。
- 因为单个mysql的Qps就是2048. 如果并发量再多，mysql就直接炸掉，就算抓取到了数据，数据没有保存起来也是白搭。所以一般就是采用消息中间件，作为临时缓冲，然后搭建分布式存储集群(分库分表)，以保证能够及时存储。
来个小总结
- 看了上面的，这不就是同时请求的并发数目，加机器其实也算提高并发数。对，高并发对于矛(爬虫)来讲其实就是，疯狂的加并发。
别慌，坑多着呢。(基本就是爬虫工程师常遇到的问题，等我有时间来填)
- 我们上面讲的是只是理想情况下。现实很残酷的。一个能够高并发分布式的爬虫系统，大概率是会遇到下面的问题：
- 服务端有风控(风控又是很多种)
- js混淆(有时候难到你怀疑人生)
- token鉴权
- 验证码验证
- 同一Ip请求次数限制(换ip即可)
- 页面定时改版
- 还有其他类型的(参考大厂)
- url去重
- 脏数据清理
- 服务端不行(解决了其他的问题之后的瓶颈)(比如某些渣的网站，QPS就那么多，稍微高点并发，直接服务端500,或者官网直接挂掉)
- …
- 服务端有风控(风控又是很多种)
最后的总结
- 对于矛方的高并发，最核心的其实还是在与服务端的响应瓶颈。所以如果做好一个高并发的盾方才是难度最高的。