第72章 模擬器更新（5.1k大章）
斯坦威警长在fbi工作，从这警衔就能看出对方的地位，工薪在13万到18万美刀之间0
实际上美利坚联邦调查局只是称警长，职衔正常来说，是属於高级探员，至於主管和助理局长就都是文职一类，在美利坚复杂的官僚调度体系里难以琢磨，不过肉眼可见的也是地位很高。
陈哲本来以为对方也是留学生，可是照现在这么看，这傢伙反而是个土生土长的美国人！
“我对此深感惋惜。”
陈哲心中思绪起伏，表情没什么波折。
“没关係，也不是我第一次跟別人提起这件事了。”书虫摆了摆手，声音低沉。
陈哲拍了拍对方的肩膀。
他並不打算利用书虫的身份做些什么，和对方交谈片刻之后，就整理好了自己脑中的所想，回到了聚会之中。
聚会下半场，本端著咖啡回来的时候，气氛已经松下来了。七八个人散坐在草坪上，有的靠著树干，有的盘腿坐在枯黄的草上，有的趴在野餐桌边刷手机。阳光从云层后面露出来，把整片草坪晒出一层薄薄的暖意。
本没坐下。他站在野餐桌旁边，喝了一口咖啡，目光从人群里扫过，最后落在陈哲身上。
“陈，”他忽然开口，“上次在绿点区跟你聊的时候，有个问题你没答完。”
陈哲抬起头。
本把咖啡放下，走到桌边，从背包里翻出一支马克笔，在白板——其实就是一张a3纸上写了一行字。
“python的gil，你怎么看”
桌上几个人抬起头。提米的手指停在键盘上，莱拉把可乐罐放下，全民超人从树干上直起身子。
这一句话的信息量极大。
“又是出难题的时候了。”莱拉低声说。
“这次是针对陈一个人的”
“看来他俩线下已经单独约见过了。”
“群主对有潜力的新人真是上心————”
席中短暂骚动只言片语。
陈哲想了想：“gil是cpython的全局解释器锁，同一时刻只有一个线程执行python字节码。”
本点点头，等他继续。
“所以多线程cpu密集型任务在python里是偽並行，”陈哲说，“只能跑在一个核心上。i0密集型可以用多线程，因为有阻塞等待，gil会释放。”
本没评价，又写了一行字。
“怎么绕过gil”
陈哲答：“多进程。用ultiprocessg模块，每个进程有自己的解释器和gil，能跑满多核。或者用c扩展，把计算密集的部分用c写，在c层面释放gil。还有asyncio，协程，適合i0密集型但不是cpu。
本又写了一行。
“那你在实际项目里用过asyncio吗”
陈哲想了想，摇头：“用过一点。不过有一次写异步爬虫，aiohttp搭配asyncio，跑起来之后发现有些请求没发出去。后来查了半天，发现是事件循环里有个地方忘了await。调了一天才找到。”
提米在旁边笑了一声：“我懂。我第一次用asyncio的时候，在代码里写了个ti.sleep，整个事件循环都卡住了。后来才知道要用asyncio.sleep。
“7
几个人笑了。气氛鬆快了一点。
本没笑。他看著陈哲，又写了一行字。
“那gil在什么情况下是真正的瓶颈”
陈哲的手指微微紧了一下。这个问题的方向和他预想的不太一样——不是基础题，是在问真实场景的边界判断。
他想了想，开口：“如果是纯cpu计算，单线程已经跑满一个核心，gil就是瓶颈。比如科学计算、图像处理、机器学习训练这些场景。但那种情况一般用nupy，它底层是c，不在python层面算。”
本等著他继续。
“如果是混合场景，”陈哲说，“计算加i0，比如web服务，gil的影响要看请求量和每个请求的计算占比。qps不高的时候，gil不是问题。qps上去之后，每个请求的计算时间只要超过几十毫秒，gil就会开始卡。”
他顿了顿。
“具体閾值要看业务。一般估算的话，单核能撑的qps上限除以cpu占比，再除以並发係数。比如单核能撑1000qps纯i0，如果每个请求有10%的cpu计算，那实际能撑的qps大概在100左右。超过这个数就需要多进程或者换语言。”
本听完，没说话。
他低头在白板上又写了一行字。这次写得很慢，像是在斟酌什么。
“你写过多线程的生產级代码吗”
陈哲看著那行字，沉默了两秒。
然后他摇了摇头。
“没有。我写的都是单机脚本和web后端。多线程只在deo里跑过，没上过生產。”
本的眉头微微动了一下。
他盯著陈哲看了两秒，然后问了一个更细的问题：“如果让你设计一个多线程的爬虫系统，抓取一万个网页，你会怎么处理线程池的大小”
陈哲想了想，开口：“先看瓶颈在哪。如果是i0阻塞，线程池大小可以设大一点，一般设100到200。但也要看目標网站的承受能力，不能把人家的伺服器打崩了。所以要用信號量限流，或者用队列控制並发数。”
“如果伺服器返回429呢”
“加退避。指数退避，第一次等1秒，第二次等2秒，第三次等4秒。如果连续失败超过三次，就把这个url丟回队列，等后面再重试。”
本又问：“那如果队列满了呢”
“满了就阻塞生產者。或者用有界队列，满了之后生產者等待，等消费者空出位置。”
本的眉头没有鬆开。
他又写了一行字：“你怎么保证每个线程拿到的url不会重复”
陈哲的手指在膝盖上轻轻敲了一下。这个问题比他预想的深一不是问怎么去重，是问分布式的去重。
“用布隆过滤器。”他说，“每个线程拿url之前先过一遍布隆过滤器，已经爬过的就跳过。布隆过滤器可以用redis的bitap实现，多个线程共享。误差率可以通过哈希函数个数和位数组大小控制，一般能接受千分之一的误判，少爬几个页面问题不大。”
本点了点头。但他没停。
“如果布隆过滤器误判漏了一个重要页面呢”
陈哲这次真的停住了。
他沉默了两秒，然后开口，声音很平。
“用確定性去重做备份。布隆过滤器只是第一层过滤，漏掉的页面可以靠第二层校验，比如把url的哈希存在redis的set里，精確去重。但set的內存占用太大，所以可以用布隆过滤器做预筛选，set做兜底。”
本盯著他，又问：“那如果set也扛不住呢”
陈哲的手指停住了。
他看著本的眼睛，沉默了三秒。
然后他嘆了口气，声音里带著一点无奈，又好像只是很坦诚。
“这个我不知道了。”
他顿了顿，又说了一遍，语气更轻，像是自言自语。
“学艺不精。没做过这么大的量，没碰到过这种级別的瓶颈。”
本的目光在他脸上停了两秒，像是想確认什么。
桌上安静了片刻。
提米在旁边嘖了一声，替陈哲解围：“本，你这题出得也太偏了。分布式爬虫的去重方案，那是架构师才需要考虑的问题。他一个刚入行的新人，能想到布隆过滤器加set兜底已经很不错了。”
全民超人点头：“就是。你问他gil、问线程池、问退避策略，这些还算正常。问到分布式去重，那已经超出普通开发的范围了。”
莱拉也帮腔：“我工作三年了，也没设计过这种量级的系统。平时业务里碰到这种需求，直接用现成的消息队列和分布式框架，谁会自己造轮子”
本没说话，只是看著陈哲。
陈哲靠回椅背上，端起那杯凉透的咖啡，喝了一口。苦的。他的表情很坦然，像是一个真的不会的人。
“確实不会。”他又说了一遍，声音很稳，没有辩解的意思。