@sumarker #1 八股我觉得也挺看运气，有些面试官就只问一下浅层，有些就会往深追问，如果没有实操经验，一问就完

@thevita 我的需求和您提到的 schedule 定时任务很像，第一次用户手动配置，请求接口，执行扫描任务。然后会设定这个扫描任务定期执行一次，我纠结的就是每次执行如何获取第一次请求中的参数配置。

@vance123 接口参数变的话，就存一个新的请求信息吧，不对原来的做修改

@vance123 我这里的意思是：审计和重放都可以使用存 JSON 这种方式来实现，不是一表两用。确实应该按你说的，分开用，毕竟日志审计和重放还有差别，重放的话，管理模块还需要知道重放哪一条参数，所以我认为重放参数的持久化还要和某些属性关联，比如用户。

@Avn #6 非常感谢，您提到的两种情况我都有涉及，请求体信息（接口地址，时间等）我是准备在网关层持久化的，以便后续审计。但我的业务不像您提到的：必须要有前端显示，它可以理解为一次任务，第一次的任务配置需要用户前端填写，后续的任务执行都可以使用同一套配置。所以任务执行需求和审计需求是否都能用“直接存储 JSON 请求体”的方式满足呢？

如果是的话，每次管理模块调用子模块，就先从库中获取 JSON 请求体，再构造请求调用子模块接口。我还想过另外一种方案：管理模块不直接构造请求调用子模块，而是告诉子模块接口请求参数的存储地址，由子模块自行获取参数执行任务。对于前者，子模块接口接收不同类型的 RequestBody ，比如登录接口接收 LoginBody ，注册接口接收 RegisterBody 。对于后者，子模块接口的接受类型就固定了，都是“参数信息存储地址”。除此之外，我目前还没有想到这两种方式在实际开发中的优劣。

@julyclyde #1 但内部调用实际干活的接口时，还是需要前端 POST 过来的参数

@higker #154 研一，再一年找工作了，研究底层的时间确实不多了，个人发展方向也是后端应用。GraalVM 还有 Java21 新出的 loom ，virtual thread ，这些离普及还很远吧，我觉得公司做一套升级要考虑的太多了，求稳还是保守一些。当然个人可以提前开始学习了

@c2const #41 卷也不算是语言问题，算是社会问题了哈哈

@gitrebase 这个是开发者自身的问题吧

@CaptainD 偏底层研究的人应该更偏向于 cpp 和 rust ，这可能是一个原因

@PTLin 是这样的，水平还不够，只有都懂才能对比优劣

@Betsy 这样嘛，之前认为日志是非结构数据，所以觉得 MySQL 存不太好。现在学到了，谢谢

@Betsy 我的初衷是学东西，找工作。这个项目肯定是要作为简历中的一项。加上我是主要开发，所以我更倾向选择一些企业常用的，比较成熟的方案。

@Jat001 嗯，这确实是我的错误，想选一个功能对口的组件，没太考虑学习成本

@wwwz 日志上传好像是无回执，就是没有返回值，所以别人可能不知道自己上传是否成功，还得简单学一下 es API

@fatyoung 这是不是相当于我把 es 的 CRUD API 自己实现了一遍？我现在是通过配置 logback ，GELF UDP 发到 graylog ，这样是实时发送吧。如果用 API 的话，是不是只能定期上传，做不到实时吧，实时是否意味着要一直调 API

现在架构想法是：子模块还要自己维护一个子日志库，同时所有组还要给上传给总的日志库，如果我用 graylog ，es 存储的话，也就意味着各个子模块的开发也要用 es ，对于学生来说存在学习成本，所以其他人提议使用 MySQL 存

@Betsy 也不算是小项目，我研究生，导师接的国家级项目，我是主要开发

@liuhan907 公司一般都是买吗？我以为都是自己搭的