这个问题更像是管理缓存机制的策略。
最优策略肯定是利用 CDN 自带的刷新缓存服务去通知各地 CDN 缓存服务器刷新，这才是百分百有效的刷新缓存页面机制。
联系 CDN 服务商，要求开有鉴权主动刷新缓存的 API ，避免验证码这种诡异的请求数量限制。
如果 CDN 节点不支持主动刷新缓存，最好是改缓存策略，只用 CDN 缓存带 hash 标注的静态文件和几乎不会再修改的 HTML 页面。需要更新的 HTML 界面的请求带宽由服务器来抗。只传输 HTML 界面的代码带宽消耗已经很小了，可以通过多开服务器分摊流量负载。至于页面数据解析和请求数据库的负载，可以考虑用 Redis 按 URL 整体打包缓存。

在后台模拟强制刷新网页的请求属于歪门邪道，那样顶天了只能刷新服务器所在地区的缓存。

辞职。
要不然就是以个人能力整合公司开发资源，做一套代码去迎合市场上面几十家公司的需求，这样你们可以做到后续客户都只做改模板界面的事情赚钱。

好一点的外包公司靠服务费生存。
再差一点的靠协调其它外包公司的开发进度生存。
差一点的靠模板项目微调业务代码生存。
再差一点的靠改开源项目生存。
以上都是有特别熟悉行业业务需求的员工或者有几个核心业务很完善的代码框架赚钱。
以下都是没有核心业务的公司。
好一点的根据用户需求改改从大外包公司带出来的项目框架赚钱，通常是挖几个大公司里面的员工带源码出来。可以靠短期差价赚钱，只要核心框架业务不太过时。
差一点的靠能改得动开源项目的员工生存。
最惨的靠接散单各种压榨员工，今天改个界面，明天写个后台。

Python 堆启动项目阶段的功能，快速堆功能占领市场。
真有业务瓶颈就先堆服务器。

如果运气好做大了，考虑到要省钱或者碰上重 CPU 的业务。
看团队愿意学 golang 的多不多：
多的话培养点内部核心员工转 golang 去把性能瓶颈的业务代码转成 golang ，好多 Python 启动的项目都走这条路线，似乎是 Python 开发人员比较愿意学习 golang ？
不多的话大量招 Java 进来用 Java 做性能或者复杂业务的模块开发。 Python 启动的电商项目喜欢这么转，毕竟可以挖阿里的人，试错成本低。

Java 是在大量开发人员共同开发项目的时候，工程规范化轮子最多的语言，只要少量的架构人员写好工程规范的约束，就可以快速扩张开发人员了。
而且在大数据处理领域， Java 的轮子最完善。

开代理、做网站、开项目、写爬虫、做私人网盘。
买服务器做为练习资源，提升自己的能力投资自己才是收益最高的 。

ben 改决定了，他认为还需要几年才能放弃 Python2 ， 4.5 乃至 5.0 都还会是兼容 Python2 、 Python3 。

如果一定会遇到使用 QQ 发文件这种糟心事的话，还是 Windows+虚拟机跑 Linux 好了。

我用过的几个 Linux 桌面发行版或多或少都带一些不好处理的问题。
早年红旗的发行版各种兼容性问题。
Ubuntu 两年一次的大版本升级大概率需要重装。 12=>14 、 14=>16 我都遇到过。
CentOS 版本稳如泰山，需要安装新版的时候往往要靠引入各种非官方源刷不同的版本。还有可能遇到各种问题装不上，我遇到最恐怖的是安装 jsv8 引擎和相关扩展库。
gentoo 版本冲突是日常，滚系统版本烤机太浪费时间，还要花很多时间写配置文件，调试各种软件的参数搭配，新手大概率配出一个基本不可用的系统。


但是如果就是追求开发的畅快，又能忍受配置各种环境的枯燥细节。我觉得 gentoo 也不错，最开始使用 gentoo 那两年，死守着滚动升级每周都要滚系统升级，遭遇各种各样的问题，删删改改配置，编译来编译去，解决各种冲突，浪费了很多时间。
后来我想开了，即便我用 Ubuntu 、 Debian 、 Arch 之类的发行版，也架不住我每周升级这么折腾，大部分系统还是装完之后，有需要的软件才会去安装。于是我改了习惯，只在需要安装软件和更新内核的时候才操作一下。于是变得非常省心，需要测试新的内核，就安装编译一下系统内核，其它软件并没有全部重新编译，需要升级什么就升级什么。

在这样的使用习惯下，需要的软件和内核都是按需升级，并没有遇到多大的问题。系统内核从 3.8 升级到 4.3 、 4.6 、 4.9 都近乎无痛，刷刷内核版本号，安装同一个语言的多个版本，配置灵活切换。整台电脑自从四年前折腾 gentoo 进去之后，换过几次内核和桌面环境，没有遇到需要重装系统丢文件丢配置的痛苦。尤其是写代码需要配置各种插件的时候，要比 Ubuntu 和 CentOS 舒心一些。

收集各种 copy to China 的项目以及现状

另开一个栏目专门介绍那些非常新的项目，还没来得及 copy to China 的。

运营给力的话，说不定可以搞成个不错的产品。

说明这个项目没什么竞争力可言，随便 copy 代码就可以抢走原来公司的资源，这种情况下连最惨的外包服务都做不好。

哪怕是外包项目，最基本的也要做到，即使有别人 copy 走代码，客户也会因为考虑到后续维护升级的技术支持而继续使用原来的代码。

纯粹只是公司不想花费那么多人力成本而已。
五险一金按最低交，剩余计入工资，然后工资按个税全额扣除，一个员工如果 offer 开 20k ，公司实际人力成本不会超过 22k 。员工到手 16k+0.5k 公积金
如果五险一金按全额交，剩余计入工资，再按个税扣除，同样还是 offer20k ，公司实际人力成本将 27k 。员工到手 14k+2.5k 公积金。

所以对于不知情的员工来说，看起来是要不要白白缴养老保险的问题，实际上公司人力成本节省接近四分之一。工资越高这笔支出越明显。

然而创业公司最重要的资产其实是业务，只要办个新公司，把业务转给新公司做，分分钟可以把旧公司做到负资产。老股东不知道怎么举证的话，分钱不成背一身债很正常。

@huanghua123 我的建议是在 anwser 的 restful 接口里面，就可以把 question 的信息一并拼进去，因为一个单独的 anwser 的信息不足以组成一个完整的信息。
这样只要查询 anwser 的时候，额外去查一下 question 的信息拼起来，前端可以根据实际情况决定是否显示 question 的信息。而且此时你的大部分前端功能都是 anwser 与 question 的信息一起显示，没必要为此单独发两个请求。

索性查的时候把答案列表拿出来之后，整个列表的 ques_id 都取出来直接去查一次数据库，把问题描述拿出来，拼成一组完整的数据。消耗不了多少性能，业务还可以简单不少。

纯粹符合范式的数据处理方式有时候兼顾不了性能。适当做做预处理或者缓存性能可以好一些。

拉个现有项目的代码，删掉其中某个小模块，然后把文档和接口要求列清楚，问问实现思路，或者直接让写出来

7 楼的 @branchzero 已经把说明更新出来了，我摘录一下， cm13 要升级到 cm14.1 需要刷新固件。
先刷 MM Bootloader, Ifwi, bom_token Updater 把 BL 破解了
再刷 LP Bootloader Downgrade, Ifwi, bom_token Updater 把固件更新了
最后再刷 cm14.1 就可以。

Official CM-13.0 -> CM14.1 Upgrade Guide

As seen with my previous unofficial CM-13.0 builds based on the MM Stock roms, An upgrade to the MM Firmware and bootloader is required going forward.
This guide is here to assist.

1) Download ROM and 7.1 GAPPS
2) Download my Firmware Update package for Z00A( http://theflamingskull.com/downloads/z00a/MM_BL_STUFF/M_BL_upgrade_for_zf2_551ml_6.0.zip) or Z008 . FASTBOOT AND ADB ARE REQUIRED!
3) Follow the included instructions to update Firmware and flash the new compatible TWRP. If for some reason the new TWRP is not flashed automatically flash it manually via fastboot. "fastboot flash recovery recoverimagename.img
4) Reboot to recovery and flash CM 14 and Gapps, reboot and enjoy. Data Wipe on upgrade is not required

http://www.theflamingskull.com/zenfone2.html

先刷 LP Bootloader, Ifwi, bom_token Downgrade 更新驱动。再刷系统。

在长沙的芒果 tv 有一票用 python 和 golang 的大神。

刷榜、刷单、刷转发、刷安装。

iOS 的系统需要破解拿到更高的权限才能执行。
Android 也需要 root 。

剩下就是模拟操作的事情，执行成功的请求可以放到终端去发出来，如果终端超时，说明任务失败回滚任务队列让任务重新执行就够了。

服务端的业务比较简单，一个添加任务的管理平台，开放取任务的接口和更新任务状态的接口。

给人做过一套类似业务的平台，不过主要做 web 页面的处理，所以终端用的是 electron ，终端获取代理参数和脚本执行各种操作。
开发调试脚本一个月，上线一周后死于目标网站的业务调整。

生产者和消费者模型，七牛的公开技术文档经常提到这个设计模式在内部项目的应用场景。