看待遇，给多少钱干多少事。
看环境，同事普遍高水平就严要求。
看老板，如果你意见和老板不一致，那老板说得对。

只能说 java 是这样的，不然也不会云原生时代被 go 按脑袋了。

我猜是中心发号段+预分配。
不是来一个帐号发一次，而是一个登录服务器会预取一段号码（ 1000-几万个），中心发号器只需要一段段分配就行了。

这也能解释为啥有人就是登录卡了一下，uid 直接上 100 多万了都。。

高并发系统嘛，无非就是来来回回几个方案，去中心化，批处理，异步队列。核心就是打散 IO 压力。

互联网产品的聪明才智唯有在坑蒙拐骗上才表现的淋漓尽致。

哎... 之前远程指导朋友换硬盘，他吭哧吭哧把硬盘硬塞进硬盘笼，问我为啥要费这么大劲。
我心里一咯噔，让他抽出来一看果不其然装反了，4pin 供电硬是把 sata 口怼了个稀烂。。

@yyzh
看了下我原文。。确实说的有歧义，我的意思是，两年前达量降速，现在不会降速了。大概是去年 3 月开始的。
但 PCDN 刷起飞一样会被限速+整改。

具体情况应该就是 6 楼说的，电信换设备导致的，我这 116 对端是中兴的 V6000 vBRAS

一个月前被局端重启然后重拨就是 116 ，4 周流量统计如下
PT 大概只挂了 2t 多种子吧，BT 很少挂。基本挂满 5 个分享率就停了。
网络方面没觉得有啥问题。

@yyzh 另外一楼说限流的，2 年前上海电信就是月下行限制 1T ，达量降速。

https://i.imgur.com/E8OsIy5.png

@zzzlight
米游如果把周常砍一砍还行。。但哪个二游不是电子盆栽呢，每天都得上去摸两下基本是策划默认的玩法了。

倒不如说米在已经赚的盆满钵丰的情况下还能稍微坚持做点新赛道的玩意已经算不错了。但目前这个进一行卷死一行的作风，真的搞的行业内卷起飞。mhy 这个游戏工业战车总有一天会让人回想起黑暗降临时的恐惧（笑

@zzzlight
说实话作为崩 3 老玩家，我认可你这套说辞对于崩 3 是完全成立的。现在崩 3 就是经典看天下饭+版本之子。

米的几个出名的二游，原在数值膨胀控制上非常优秀，三年到现在开服角色凑一队仍然能轻松打满深渊。
铁最近的流萤宇宙对于老角色也做了相当程度的补正，体验都很不错。

zzz 嘛，我也担心后期数值上来之后会不会变成崩 3 现在样子，但是策划不可能不知道这个问题。
总之，目前制作人在前瞻吹出的爽快战斗的牛逼已经实现了，拭目以待后续更新方向如何，毕竟人家是吃策划那碗饭的，应该有两把刷子。退一步讲，万一玩坏了我就当亏张月卡吧。

最近被还呗贷款打的我头疼一天几个，还一堆贷款短信。
最离谱的是 tm 推销电话拿普通手机号打的，真的是一点脸都不要了。

@aaronlau
喜欢对策卡的你可以玩玩崩 3 ，大写的没卡你不配打。。
zzz 还是强度那套，只不过目前操作给的正反馈很强。
前瞻里制作人一直在强调的：爽。这个有逐渐感受到。
崩 3 早期其实也是这个路子，无限制配队和连段，但是后期数值强度上来以后，真的组队和套路都是定死了。现在策划就直接教你怎么玩，想自己研发组队和打法？不存在的，大循环都是已经定死的，自研流程只在战场这种短流程还有点用。

@Tiger511
在我的设计里，DNS route 是一个整体，你也提到了，dns 负责分流和宣告路由。分流这个词就隐含了代理决策，所以 dns 和代理服务要写在一起，这也是我为什么坚持二开 v2ray 而不是 mosdns 的原因

符合我对外包软件的想象

@matrix1010
进一步倒推，最源头的方式：你不要把敏感信息打到日志里，为此你要重新审计每一行代码并提交证明
再进一步，所有敏感信息操作都必须 trust computing ，不允许在内存里直接存放敏感数据

现实总是妥协的，我不反对关键的敏感信息在源头处理，但敏感信息是分级的，大多数业务并接触不到也不需要接触非常机密的信息，那何必因噎废食呢。
This is an eternal chasing game of cat and mouse.

终端行为审计罢了。
如果微信的通信数据能被中间人截获并解密，我建议微信团队立刻原地解散。

老生常谈的问题了，没什么太多讨论的。
google：hidding sensitive data in log

我认为下策：在采集时直接替换
因为究其原因，它属于 sensitive 的原因是，有人的权限不够看而已。你直接采集时干掉就会影响后续一整条路的分析。而且分布式的采集，你更新屏蔽规则又要搓轮子。

举个例子：
我是做账号系统认证的，所有业务都集成我的认证中间件，这个中间件产生的 log 里含有用户 token ，业务研发看到之后可以拿用户的 token 去伪装用户身份。所以 token 不能给业务研发看。
但我是做账号系统的，这个 token 对我是有 debug 价值的（通过私钥解开后，可以看签发时间，是向哪个端签发的，对抗黑产很有用）

中策：采集后在日志网关统一替换
优点：规则集中管理
缺点：同上，没有原始数据。而且集中式处理在海量日志时 cpu 成本太高。依旧存在日志敏感内容泄露问题。

上策：zero trust 生产网络，禁止研发直连，日志原样采集存储，提供 clickhouse/es 平台的查询前端，前端展示时依据用户权限系统在查询网关吐出时做敏感信息遮盖。有查看需求的走审批流程。
优点：懒得分析了
缺点：没一个团队这个方案你怕是不好做

总之，这只是个道高一尺魔高一丈的对抗过程。服务都在研发手里，想要什么信息不是随便拿捏。
你需要做的是好好想想自己的威胁模型，你要控制/缩小哪些攻击面，可能遭遇什么类型的攻击。

通常来说，我遇到的提这个要求的，一般都是合规，不合规 toB 不好卖啊。

全真 IP ，无 DNS 污染，geosite 按需分流，配置集中化管理，客户端 0 配置，可一键秒切任意内网 IP 科学/直连且无副作用。
https://github.com/povsister/v2ray-core