天机学堂

简介 于2026年2月7日正式开始学习tjxt的项目,good luck 系统: mac 编辑器: cursor,idea,vscode ai: gemini,gpt

day1

把虚拟机用vmware fusion安装完成并设置好网卡,注意,mac在按照教程进行的时候需要根据虚拟机内的enp*的ip进行修改

关键知识点

阅读代码

1. 找到请求入口
   在企业开发中，通常接手他人代码，可以通过与同事交流确定入口位置；如果无直接渠道，可从前端请求出发，逆向定位后端核心入口。

2. 理清请求链路
   找到入口后，先整体浏览项目结构，梳理前端请求如何一路传递到微服务，依次经过哪些模块与组件。此过程有助于定位和解决BUG。

3. 紧跟主线，逐步深入
   面对复杂源码，不必试图一开始就理解全部细节。应以业务主线为引导，聚焦核心流程，从宏观脉络逐步下沉到关键细节，理清主业务流程，再按需跟进细节问题。

4. 形成整体流程图
   梳理清楚请求链路与业务主线后，画出整体流程图，便于查找问题、团队沟通以及后续持续优化。

day2

开发一个新业务的一般流程

1. 分析产品原型需求拆解基于产品原型和需求，分析业务流程，抽取业务实体，设计业务接口。
2. 设计数据结构建模与数据库设计根据业务实体和接口，设计数据库表以及接口关联的相关实体。
3. 实现功能接口代码开发基于之前定义的接口用代码实现相关功能，如有必要也可以对接口小调整。
4. 测试本地验证接口开发完成后先做本地测试，确保每一个接口基本可用且满足业务需求。
5. 联调前后端/多服务对接接口开发完毕后与其它微服务及前端联调，修复 BUG。 设计接口
6. PO (Persistent Object) —— 持久化对象 定义：它与数据库中的表结构一一对应。

职责：它的字段必须和数据库表的字段名、类型完全匹配。

例子：比如你的课表表 tb_lesson。

数据库里有 create_time（创建时间）、update_user（更新人）等字段。

PO 类中也会有这些字段。

核心逻辑：PO 只负责把数据从数据库里“捞”出来，或者“存”进去。

2. VO (View Object) —— 视图对象 定义：它是接口返回给前端的数据结构。

职责：只包含前端页面真正需要展示的数据。

例子：参考你刚才提供的分页接口 /lessons/page。

前端可能只需要展示：课程名、讲师名、学习进度。

前端不需要看到：create_time、is_deleted（逻辑删除标志）。

核心逻辑：VO 会对数据进行“瘦身”或“组合”。比如数据库里存的是 teacher_id (PO)，但 VO 会通过查询转换成 teacher_name 返回给前端

day3

雪花算法

之前其实cq项目有说过，稍微再提一嘴： 花算法生成的id是64位的，其中：

• 41位时间戳
• 10位机器id
• 12位序列号

@TableId(value = "id", type = IdType.ASSIGN_ID)
    private Long id;

这种就是雪花算法生成的id，它可以实现一种不依赖数据库、自增、高并发下也能生成“全局唯一 ID”的算法，并且可以保证id的唯一性、有序性、可读性。

高并发

什么是高并发？ 高并发（High Concurrency）是指系统能够同时处理大量的请求。在互联网应用中，高并发通常指的是在短时间内有大量的用户访问系统，例如秒杀活动、抢购活动、大型促销活动等。 高并发系统需要具备以下特点：

• 高吞吐量：系统能够处理大量的请求，不会因为负载过高而出现性能瓶颈。
• 低延迟：系统能够快速响应用户的请求，不会因为等待时间过长而影响用户体验。
• 高可用性：系统能够持续稳定地运行，不会因为故障而影响用户体验。 高并发系统需要具备以下特点：
• 高吞吐量：系统能够处理大量的请求，不会因为负载过高而出现性能瓶颈。
• 低延迟：系统能够快速响应用户的请求，不会因为等待时间过长而影响用户体验。
• 高可用性：系统能够持续稳定地运行，不会因为故障而影响用户体验。 在并发较高的情况下，会给数据库带来非常大的压力，所以需要使用一些技术来解决这个问题，比如： 提高单机并发 尽可能减小业务接口的 RT（ResponseTime），提升单机性能和并发能力。 水平扩展 将热点服务水平扩展，做好负载均衡，提高整个集群的并发能力。 服务保护 做好服务熔断、降级保护措施，提高服务的高可用性。 水平扩展和服务保护侧重的是运维层面的处理，程序员可以做到的是提高单机并发,主要有：
• 优化代码及SQL
• 变同步写为异步写
• 合并写请求

变同步为异步

利用MQ可以把同步业务变成异步，从而提高效率。

• 当我们接收到用户请求后，可以先不处理业务，而是发送MQ消息并返回给用户结果。
• 而后通过消息监听器监听MQ消息，处理后续业务。 这样一来，用户请求处理和后续数据库写就从同步变为异步，用户无需等待后续的数据库写操作，响应时间自然会大大缩短。并发能力自然大大提高。 优点：
• 无需等待复杂业务处理，大大减少响应时间
• 利用MQ暂存消息，起到流量削峰整形作用
• 降低写数据库频率，减轻数据库并发压力 缺点：
• 依赖于MQ的可靠性
• 降低了些频率，但是没有减少数据库写次数 应用场景：
• 比较适合应用于业务复杂， 业务链较长，有多次数据库写操作，并且对响应时间要求较高的业务。

合并写请求

合并写请求方案其实是参考高并发读的优化思路：当读数据库并发较高时，我们可以把数据缓存到Redis，这样就无需访问数据库，大大减少数据库压力，减少响应时间。 合并写请求就是指当写数据库并发较高时，不再直接写到数据库。而是先将数据缓存到Redis，然后定期将缓存中的数据批量写入数据库。 由于Redis是内存操作，写的效率也非常高，这样每次请求的处理速度大大提高，响应时间大大缩短，并发能力肯定有很大的提升。 而且由于数据都缓存到Redis了，积累一些数据后再批量写入数据库，这样数据库的写频率、写次数都大大减少，对数据库压力小了非常多！ 优点：

• 写缓存速度快，响应时间大大减少
• 降低数据库的写频率和写次数，大大减轻数据库压力 缺点：
• 实现相对复杂
• 依赖Redis可靠性
• 不支持事务和复杂业务 场景：
• 写频率较高、写业务相对简单的场景

持久化思路

对于合并写请求方案，一定有一个步骤就是持久化缓存数据到数据库。一般采用的是定时任务持久化 但是定时任务的持久化方式在播放进度记录业务中存在一些问题，主要就是时效性问题。产品要求的时间误差不能超过xx秒。(tips:如果产品对于时间误差要求不高，定时任务处理是最简单，最可靠的一种方案 ) 那么问题来了，有什么办法能够在不增加数据库压力的情况下，保证时间误差较低吗？

延迟任务

一个延迟任务，等待超过一个提交周期（20s）后，触发任务执行。 延迟任务的实现方案有很多，常见的有四类：

实现方案	原理	优点	缺点
DelayQueue（JDK 延迟队列）	JDK 自带的延迟队列，基于阻塞队列实现，元素只有在到期后才能被取出	- 不依赖第三方服务 - 实现简单	- 占用 JVM 内存 - 只能单机使用，不支持分布式
Redisson 延迟队列	基于 Redis 数据结构（ZSet 等）模拟 JDK DelayQueue 的实现	- 分布式系统下可用 - 不占用 JVM 内存	- 依赖第三方服务（Redis） - 增加系统复杂度
MQ（如 RabbitMQ）	利用消息队列特性，如 RabbitMQ 的 TTL + 死信队列（DLX）实现延迟消费	- 分布式系统下可用 - 不占用 JVM 内存	- 依赖第三方服务（MQ） - 配置和维护成本较高
时间轮（HashedWheelTimer）	基于时间轮算法，将任务映射到时间槽中，指针轮询触发到期任务	- 不依赖第三方服务 - 性能优异，适合大量定时任务	- 占用 JVM 内存 - 只能单机使用