@cassyfar #131
原文前面就给你引用过了，而且我也跟他聊过，就是面向爬虫场景做的。别杠了，没意义。

---

有价值的东西标题再烂也会被发现？ V2EX 这个版块下有价值的东西可多了去了，但真的火起来的有多少个？很多有价值的东西帖子下面连评论都没多少、GitHub 上的 star 也没多少，就因为标题起得过于朴素，或者起得让非相关行业人员连意思都看不懂。

另外再告诉你一个很现实的情况，我之前写的一些被大量爬虫、安全领域的人称之为“入门必看”、“内容清晰”的文章，自己发在知乎上的时候几乎没人看，而一些号主换了个夸张的标题转发到公众号直接就阅读量爆炸了。

标题起不好，东西很难被更多人看到，这就是现实。不是我浮躁，而是大部分人都浮躁。

---

最后一句话说了什么？说了自己按应用场景选择部署方式，还能说什么？你是觉得别人做个东西分享出来还得给所有人的所有场景都准备好方案呗？人家自己的场景单机就够用了，还要多机做什么？

迷信？我并不迷信大厂，每个东西的适用场景不同，人家的设计是基于人家的应用场景搞的，并不一定就完全适用于爬虫场景。但人家是用在了核心业务上，人家的架构师总不可能比你菜吧？两个不同公司的核心业务，都选择了这种方案，并且也都用了这么长时间，说明出现的问题完全在可控范围内，借鉴一下当然没问题。

至于“业界应用场景很少有需要严格递增的”，牛批啊，在你的世界观里很少有需要所以就没价值了？又在忽略一开始说的面向爬虫场景问题，又在用你觉得的应用场景往上套。人家这个场景就是需要严格递增、就是为了解决自己的问题，又不是给你做的东西，是不是开天辟地的东西关你屁事了？这年头开天辟地的东西有几个？你又贡献了几个？

我说实在的，你觉得没价值、吹破天那你就直接关页面点个拉黑完事了，拿着个自己觉得的应用场景套了半天还感觉良好，人家给你做的东西？

最后，跟你扯皮太浪费时间了，扯来扯去都意识不到问题的人我觉得没什么必要再说了，走好不送，拉黑拜拜。

@autoname #43 不应该啊？你英文的都可以成功，说明就是用户名的问题了，还是失败就很奇怪了，感觉是触发了什么别的东西...建议发个抓包对比图看看。

验证码分很多种，简单的纯文字还是要鼠标轨迹之类的拼图、滑块那些？纯文字的话网上有些免费的打码模型可以用一下，难搞的那些你自己搞不定可以接打码平台。

@autoname #41 抓包对比吧，可能还有别的区别

@autoname #38 一般碰到这种一串%xx 的就是 urlencode 了，直接拿到 http://tool.chinaz.com/tools/urlencode.aspx 里面试一下，哪个解出来的结果正常就是基于哪个编码的。

@locoz #37 顺便再补充一下，字库量 gb2312 < gbk < gb18030，通常情况下直接使用 gb18030 处理 gb 系列的编码即可，它是向下兼容的。

@autoname #35 具体用什么编码要抓包看的，乱试没有用。我刚刚看了一下你说的这个网站，它用的是基于 gb2312 （ gb 系列）的 urlencode，比较老；而现在一般的 urlencode 会是基于 utf-8 的，所以你前面的尝试失败了就是因为这个原因。
解决办法就是把代码里的 urlencode 部分设置使用 gb2312 或更高版本的 gb 系列编码，java 的代码应该是 java.net.URLEncoder.encode(str, "GB18030")这样。

@autoname #31 抓包跟是不是走的 Java 内部无关，你代码里是可以设置代理的，直接设置个代理然后设置忽略证书就好了。
你新号可以但旧号不行的原因多半是因为你没有对中文进行编码操作，毕竟你浏览器可以...

@locoz #29 补充一下，参数指整个 HTTP 请求流程中的所有东西，包括但不限于 URL 、Headers 、Body 、SSL/TLS 的一些参数等。

给你个建议：打开抓包工具，先抓一遍浏览器发出去的登录包，然后再抓一遍你自己程序发出去的登录包，接着拿这两个包进行对比，有差异的地方就是你需要注意的地方了。两个静态参数一样、动态参数生成方式一样的请求，是不可能得到不一样的结果的。

@cassyfar #122 直白跟抬杠是两回事，不要混为一谈谢谢。前面有很多直白的评论，人家没有忽略掉文章中所说的应用场景，而你是完全忽略。

他文章中没说“只是给爬虫做的”，但他是“面向爬虫场景做的”，能理解这个区别吗？原话写得很清楚：
“在爬虫场景中，这条数据在进入数据库之前会进行数据清洗、校验、矫正、分析等多个流程，这期间有一定概率发生重试或设为异常等操作，也就是说在进入数据库之前它就需要有一个 ID 来标识它。”

标题我说了，他确实标题党了，这当然有问题，但是这跟一个东西有没有价值毫无关系。看标题噱头比较大就觉得内容没价值的话，那你怕是会失去很多有一定价值的东西，毕竟标题起不好的文章连火都没机会火。

“只做到单主机 service”？文章最后那句“至于怎么选择，可根据实际业务场景和需求与架构进行讨论，选择一个适合的方案进行部署即可”你是没看到还是咋的？而且前面举例的美团和腾讯哪个不是按实际应用场景去部署的？不考虑实际应用场景强行套个自己的应用场景抬杠还有理了？

至于“迷信美团腾讯”就更搞笑了，你说只能这东西只能单机服务，我告诉你美团腾讯也这么搞，有问题？你自己也看到了人家美团知道可能会出问题，但人家还是这么用了，说明什么？嗯？

任何东西都不可能适用于所有应用场景，就像 Snowflake 在分布式使用的情况下做不到严格递增一样，你拿 Snowflake 往文章中所说的场景上套，一样会得到“毫无意义”这个结论，毕竟连个严格递增都做不到呢 hh 。

有点意思，可以把好久以前攒的地图都理一下了（虽然也不打开玩）

#3 +1，都在讨论的时候基本就是快出事情了，差不多就撤。

写个机器人一直获取评论和弹幕，然后自动删除不正常（ AI 判断）的内容？比较治根。

首先内容得对别人有价值，有了价值别人就会自发地帮你推广，像 opengps 老哥做的那个网站就很独特又有价值，我都看到好几次给他加友链、发朋友圈推荐的情况了。

当然你自己说的那几个方法也同样需要进行。文章写了没什么人看可以往各种群里、论坛里发一发，自然就有人跟你讨论了。

千万别学楼里一些（注意是一些）见个相关帖子就发自己博客链接的人这么玩，又令人厌恶又带不来多少流量。搞来搞去最后就变成抱团取暖，每天互点别人博客啥的都会搞出来…没有实际意义。

@byte10 #114 ObjectID 按文档里的说法分新旧两种版本，但两种版本都不适合：
1 、时间戳+机器 ID+进程 PID+随机数
做不到严格递增，只能靠时间戳做到趋势递增，完全不适合。
2 、时间戳+随机数+自增序号
和他现在这个很像，但随机数在高位，做不到严格递增。而且自增序号只有 3bit 可用空间，比 snowflake 的 12bit 还小，也不适合。

虽然他并不知道 ObjectID 实际也可以转化为类似的形式，但就实际需求来讲，ObjectID 仍然是不适合的选择。

@byte10 #114 对于他的需求而言，确实不行…入库才能生成这个倒确实是明显没有了解到位。

@D3EP #116 这种东西还是结合实际应用场景看。前面不是也说了吗？
首先他是在爬虫的数据处理链路上用，这种场景没有千万 QPS 的需求；

然后 Snowflake 多机使用性能肯定够他用，但是 Snowflake 多机生成 ID 的话又会有机器 ID 的问题，
做不到严格递增，他想要排除掉这个问题；

而如果单机部署成这种发号器的话，Snowflake 获取时间戳和末位序号范围过低的设计又可能会导致单机生成 ID 的性能满足不了他的需求；

结合这种需求想到用递增序号搞不是很正常？

然后他又会有数据对外展示的情况，考虑到这种情况加个随机数操作一下，让大部分人看不出 ID 怎么来的，也让别人的爬虫没法直接按着递增的 ID 爬自己的数据，这东西不就这么出来了？

至于实际部署时的可用性问题，微信那个不是就给出了个很合适的做法吗？直接做个主备不就完事了？反正单机性能已经完全足够使用了，又哪来的需求会需要将这个发号器也分布式化？爬虫有 IP 就行，跨机房大可不必。

还是那句话，不要忽略别人说的实际应用场景强行套上自己的需求…

@quericy #102 其实就他所说的「在爬虫的数据处理链路上用」这种应用场景而言，异地多机房部署出现的情况概率极低，使用时基本都是单机房下的分布式，瓶颈问题其实没那么严重；而且没有了多机房之后可用性问题也没那么严重了，所以问题也不大。不过对于后端的大部分服务而言，薄雾这东西可能确实没多大的必要使用，毕竟应用场景差异太大。

@cassyfar #111 你说的话确实像为了喷而喷，并且你明显没有好好看别人说的话。给你列一下主要问题：

1 、你上来第一句就在阴阳怪气地嘲讽，但后面指出的问题确实又并不符合人家所说的实际应用场景，而是以你自己以前的公司的那种场景作为基础在质疑百万、千万 QPS 怎么办。
这能怎么办？应用场景都不一样啊，人家文章开头就说了是在爬虫的数据处理链路上用，得多大量级的数据才会碰到百万、千万 QPS 还必须硬扛过去的情况？我之前（ 19 年左右）在一份报告上看到 360 搜索的爬虫每天爬的页面是 10 亿，均摊下来也就万级 QPS 就够用了。在这种应用场景下说百万、千万 QPS，是要上天？

2 、人家好好给你举例，问你「你认为怎么做才合适」、「你会怎么设计」的时候你啥都不说；人家文中和回复中都说了的“用了预存预取”你又完全不看，然后你就又开始对数据库操作部分开喷？
依赖数据库持久化、ID 递增的 ID 生成系统又不是只有他这一个，文章前面提到的美团和腾讯的做法中同样是有数据库 /硬盘 IO 操作和号段预存预取+缓存的机制，你要不顺便把他们也喷一喷？反正在你看来应用场景这种东西是不存在的，只要有数据库依赖就是“垃圾”呢。

3 、这是个人项目，不是团队项目，代码仓库都是放在个人名下的，文中的描述也是“我”而不是“我们”，他也从来没说过这是团队项目，哪来的“一群”、“你们团队”？

他标题党当然有问题，主流应用场景有差异的情况下不应拿性能做对比，毕竟没有多大意义，这点不可否认。但你所谓的“心气很高”、“反驳不了就扣帽子”的情况显然是不存在的，这说法放到你身上我觉得倒是挺合适...好好地就事论事不行，非要人身攻击；喷的点有问题还自我感觉良好，人家好好回了又不看，实在🐂🍺。