Hyper-V Server + 对应的 Admin center

是打开后点击 Benchmark 后计算得到的时间哦，不是打开文件的时间
Office 365 x64; R7 4800H;未关闭额外的后台线程
不开多线程 71s
开启多线程 29s

还是按照层级关系查询然后拼接吧，可能的问题就是 sql 查询次数的问题：
https://stackoverflow.com/questions/169817/is-it-possible-to-query-a-tree-structure-table-in-mysql-in-a-single-query-to-an
或者 fullname 不存一个名字拼接的内容 存 id 的串 比如 1>2>3>4

需求方可以完全不理会需求合不合理，瞎吉儿折腾，一个星期改仨需求，问业务场景都描述不出来个 1 2 3 ，验收嘛开始挑刺，指望接单的当蛔虫。需求我不说，就是玩
接单的呢就别说代码质量了，交差是第一目的。我先给你这玩意糊上去, 也没指望能赚尾款的钱，见到需求方就:"好的 明白，对，是这样的"，样子长得像就行了 谁管你是鹿还是🐎
大部分都是草台班子, 糊弄糊弄交差了还能咋地

执行计划

你们面试别人别人反问你答案是什么你知道吗？

程序如果注册了比如右键菜单、打开方式等 注册表还是要处理一下的

C# 好多票

pull 的模式，需求速度>接口吐数据的速度，巧妇难为无米之炊。需要做的是明确需求
1. 一定是实时吗，或者调用的窗口能不能延长。
2. 找 api 提供方，看能不能给放松一些限制(多 token 模式)
3. 如果请求数据是一个周期性的过程(比如每天早 8 点报表) 可以考虑在周期前做请求(当然得看是不是数据有时间属性)

需求是硬性的话，2 应该是一种比较好方式，比如对 token 和账户做好分区(贴着限速的要求)，10 个 token 对应 2000 个账户。保证某一个分区内的 token 不会被限速。账户增加 token 也要随之增加

也负责审核+优化查询

安装了 64 位的，在 Office 365 OneNote 里面显示为非活动应用程序加载项

有没有可能是在修 log4j2 然后上线上崩了 :doge

反爬是个持久战，就是攻防双方看谁的成本高。
1. 先把限速什么的常规方法加上看下效果
2. 再然后触发条件的时候可以考虑返回随机生成的脏数据；
3. 复杂一点可以参考大众点评猫眼类的字体反爬。

很像是 kafka 的一套东西
多条队列(或者队列内分区)(q1,q2,q3)
1. 消息在队列内的分布上需要考虑同一个 UserId 的消息有 FIFO 的顺序。(UserId Hash 保证落到同一个队列 /分区内)
2. 每一个队列(分区)的接收者需要做绑定，用类似锁的机制处理 receive 的断链和补位 q1->r1

不喜欢公司配的开发环境:
× 找老板 battle 换
× 自带
√ 上 V2 发帖寻求认同

@smileherd 很期待楼主分析资产增长成因、过程。

> 你一个人的命运啊，当然要靠自我奋斗，但是也要考虑到历史的行程

人的足够努力，和后面的赚钱 /成功之间很多情况下只是有一点点相关性，甚至是成功后反推出来的因果(成功学)。

什么是电梯理论？

一个人乘坐电梯到达了摩天大厦的顶楼，但在乘坐电梯的同时，他也在电梯里做了几个俯卧撑。

到达顶楼后，他解释自己之所以可以到达顶楼，完全是自己努力做俯卧撑的结果。

完全忽略了电梯的存在。

emmm 我觉得 rpc 还是 http 这个可能不是重点？
> 很笨重，开发效率低，也容易出 BUG
rpc 还是 http 无非就是协议，感觉重点应该在各个不同系统之间 payload 的定义如何管理，保证各个系统都能遵守对应 payload 的 scheme ？

自己实现应该有一个窗口期，比如 5 分钟，从 Topic A 和 B 中取数据，每份数据没有匹配最多向后等待一个窗口期，超时后没有匹配到扔到错误处理流程。正确匹配的数据合并后进入成功的 Topic 作为下游处理队列