我之前用 apscheduler 扩展了一个， 不过这个性能并不是很好

自如吧。。

我用的 m1l 至今没发现什么问题。

@xiaoz 这个我是知道的。 强迫症患者 ， 心里想的是 要么用它 要么不用

不想接受 firewalld, 目前全 6

卧槽 看成京东了。。。

路由器的问题， 你需要双向 nat 转换

非常棒， 感谢有你。

同求， 同时运维也可以。

@eslizn 谢谢， 不知可有借鉴的项目呢

@Sunyanzi 我看看，谢谢

@haozes 嗯， 这个我到是有看到

@jybox 我看一下

@hand515 鄙人运维， 不熟悉 java ， 即便一开始就知道 quartz 也未尝试。


昨晚发完贴后， 有事儿后来没能跟进本帖， 抱歉。

一直撸触摸板， 有个 magic mouse 一直吃灰。。

用了 mweb 就啥都不想用了。

值得一提的是， stackedit 是开源的， 我自己 vps 也放了个， 偶尔也用

恐怕 atom 。

值得一提的是， 我司除了 200 多个实例用的是云， 很多自动化的需求都是运维开发实现的。。

rar 加密下， 密码写长点， rar 的加密除了爆破 没辙。

我们是实现一个 漏桶 来处理这样的事情的， 针对流量分析一下 ip 均匀请求量 自动调整漏桶大小， 如果爬的比较猛就直接 ban 掉 ip ， 值得一提的是 这样的方法防不住有心的爬虫， 总的来讲我们是想挡住恶意的高频请求用户

至于完全的防爬， 我觉得是不可能懂， 人家真想要你的数据， 办法多的是。。

首先， 如果是只想要接口时间， nginx 的 log 是可以获取到的， 如果你需要接口 线程 id 方法名等， 这里需要业务监控等能力支持， 当然， 你仍然可以做简单点， 写个通用方法纪录即可。

至于 dao 也是一个道理， 要么看数据库 log （不建议）， 要么程序上能支持

最后你提到可能一个请求 打了好几次， 目测应该是请求重试导致的， 值得一提的是 同一个 upstream 下有多个实例， 当请求失败了， 会尝试请求下一个， 这也是 ngx 的特性， 尽可能的保证 upstream 下有实例可用.

想减少对主体代码的侵入性？ 你可以打出来 log ， 让运维流 log ， 然后分析出有用的结果

nginx 自己更新自己， 这个恐怕有点艰难， 可行性我还没有尝试过。

我这边是外建一个 register 负责处理注册请求， 有点像 confd ， 但有损耗， 需要 kill -HUB,

不过我负责注册的请求时分布式的， 不影响业务， 目前也在想办法解决这样的问题。 关注。