C# 好多票

也负责审核+优化查询

安装了 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 作为下游处理队列

感觉是 Flink

Swagger 的两分钟有没有可能是 Swaggerui 渲染比较慢? 实际的网络请求也同样的慢吗？

sorry 提供错了

感觉是 ActionResult 的问题?

``` c#
[HttpGet(Name = "GetWeatherForecast")]
public async Task<ActionResult<IEnumerable<WeatherForecast>>> Get()
{
await Task.CompletedTask;
var list = Enumerable.Range(1, 1000).Select(index => new WeatherForecast
{
Date = DateTime.Now.AddDays(index),
TemperatureC = Random.Shared.Next(-20, 55),
Summary = Summaries[Random.Shared.Next(Summaries.Length)]
}).ToList();
return list;
}
```
这样的代码也会卡一会

建议是先和领导沟通一下自己不想干自动化测试这件事情，如果没有好的结果，后续考虑骑驴找马吧