如何将技术派写到简历上？-技术派

大家好呀，我是技术派社区的二哥呀。

之前有粉丝反馈自己的项目经历太少，不好写简历，影响找工作，不知道你有没有这样的困惑。

今天我就针对校招毕业生，手把手教大家如何将技术派项目写到自己的简历中。校招毕业生对于项目的考察，主要还是偏基础和应用。

1.1 如何写简历

项目名称：技术派社区项目（2024.6-2024.8）

技术栈：Spring Boot、MyBatis-Plus、MySQL、Redis、ElasticSearch、RabbitMQ、MongoDB、Docker

项目描述：技术派是一个前后端分离的，面向互联网开发者的技术内容分享与交流平台，包括前端 PC 和管理后台。我们通过文章、教程、AI 助手等产品和服务，旨在打造一个激发开发者创作灵感，传播优质技术内容，陪伴开发者快速成长的技术社区。

在线地址：paicoding.com
GitHub 仓库（已有 1.9k星标）：https://github.com/itwanger/paicoding

责任描述：作为核心研发人员，主要负责登录认证、消息通知、文章教程、AI 助手，以及管理后台的开发工作。

通过验证码和前端保持半长链接映射关系，当用户扫码关注公众号并输入验证码后，发起回调，识别用户信息并找到对应半长链接，实现系统自动登录；
将用户评论、点赞、收藏、系统消息发送到 RabbitMQ，实现消息的异步解耦；
利用 AOP 切面技术，当系统收到新的消息时（如评论、点赞等），自动将这些消息发送至 Kafka 消息队列中。接着，通过消费者服务从 Kafka 中取出消息，并将其存储到 Redis 缓存中等待用户消费。
通过 Canal 框架实现了 MySQL 与 ElasticSearch 的数据同步，确保了实时搜索的准确性。
通过 Redis 的 zset 实现用户活跃度排行，并通过先写 MySQL，再删除 Redis 的方案来保证高并发场景下的缓存一致性。
基于 ThreadLocal 在登录校验拦截器中封装线程隔离的全局上下文，以便在线程内部存储用户信息，减少用户信息的数据库查询次数。
实现自定义的 Markdown 编辑器，通过复制粘贴即可将非同源的图片上传至 OSS 实现智能化转链，并借助线程池和异步任务 CompletableFuture 提升系统的高并发能力；
通过 Nginx 代理，将客户端请求转发到目标服务器的后端 API 接口，从而解决跨域问题；并配置 SSL 证书以保证 HTTPS 请求的安全性，配置动静分离以提升资源的加载速度。
采用 HandlerExceptionResolver 的全局异常处理策略，提高代码的健壮性，用户体验得到了很好的保证；
通过 AOP + TraceID 记录接口访问日志，实现任务的追踪、监控和诊断。
集成本地缓存 Guava 和 Caffeine，有效提高服务的吞吐率，QPS 经过实测提升了近 30%；
为了满足社区在高并发场景下业务 ID 的唯一性和可追溯性，我们实现了一套基于雪花算法（Snowflake）的 ID 生成方案，进一步降低了ID生成的延迟。
通过 Liquibase 实现数据库表的自动创建和初始化，以及版本管理，并且兼容 MySQL 和其他不支持 Liquibase 的数据，如 mariadb。
通过提前建立 Socket 链接，来解决本地服务启动时 8080 端口可能被占用的问题；
搭建 Redis 集群、数据库的读写分离，以实现服务的高可用和高性能；
引入 Caffeine + Redis 构成多级缓冲，解决热门数据（首页流媒体、专栏教程）的吞吐量瓶颈；
通过集成 xxl-job 实现了定时任务的管理和执行，如自动清理过期文章缓存、社区数据统计等。
借助 Redis 的 zet 数据结构实现轻量级的作者白名单，提升优秀作者发布文章的用户体验；
我们通过 Shell 脚本实现了一套可以在 Linux 生产环境下一键源码部署源码的成熟方案，极大缓解了社区在生产环境下热部署的压力。同时也支持 Docker 容器化部署，显著提高了社区的运维效率。
采用自旋锁策略优化缓存架构，针对热 key 的并发访问进行同步，防止其失效时导致的缓存击穿；
派聪明 AI 助手通过 WebSocket 实现前后端的及时通信，并且通过异步流的方式实现消息一点一点输出的效果；
应用策略模式来支持多家 AI 大模型的灵活对接，目前已经成功集成了智谱 AI Alltools API、讯飞星火 4.0 API 和 ChatGPT 3.5 API。
由于 AI 生成复杂响应时需要等待，所以选用了大模型的流式 Stream API 并结合 SSE 实时推送返回给前端，实现消息一点一点输出的效果。
鉴于生成式的回答可能存在不可靠信息，所以借助敏感词校验开源库 sensitive-word 对用户输入内容和响应内容做了自定义过滤，极大保证了内容平台的合规性。
利用 Spring Boot Actuator 集成 Prometheus 和 Grafana 搭建一套完整的服务监控体系，确保了社区平台的稳定运行。
结合 MyBatis 拦截器和 DFA 算法实现了一套完善的敏感词自定义过滤方案，确保了社区内容的健康和安全。
通过 React+Ant-Design+Vite+ECharts 完成了 Admin 端的开发工作，界面非常漂亮，并且极大地提高了项目日常的运营效率。
利用 RestHighLevelClient 接入 ElasticSearch 的全文搜索能力，极大提升了首页文章的关键字检索速度，同时兼容 ES 未安装时继续走 MySQL 的查询逻辑。

推荐样例：

还有这个球友的创意，也非常棒，来自二哥的编程星球，创意保留版权，如果没有付费，请勿直接搬运，保留追责权利。

1.2 核心面试点

考点 0：项目介绍

技术派是一个基于 Spring Boot、MyBatis-Plus、MySQL、Redis、ElasticSearch、MongoDB、Docker、RabbitMQ 等技术栈实现的社区系统。

技术派首页

这个系统旨在为创作者提供一个可以发布文章和教程，并赚取佣金的社区平台，同时又兼顾一些社交属性，比如说用户可以通过阅读、点赞、收藏、评论的形式和作者互动。

与此同时，为了紧跟时代潮流，该系统还为用户提供了一套基于 OpenAI、讯飞星火等多家大模型的派聪明 AI 助手，帮助用户在工作和学习中大幅提效。

项目中有哪些难点，如何解决？

在技术派这个项目当中，遇到了蛮多有挑战的任务。

比如说 MySQL 的库表自动初始化，用户在启动项目前不需要手动导入 SQL 文件，只需要在 application.yml 中配置好 MySQL 的用户名和密码，run 以下 main 类，就自动完成了。这个是通过 Liquibase 实现的。

技术派教程

再比如说技术派是一个前后端分离项目，admin 端请求后端 API 接口时会遇到跨域问题，这个可以通过 Node 代理或者 Nginx 设置同源策略解决。

再比如说用户点赞、收藏文章的时候，可以通过 RabbitMQ 的发布/订阅模式来提高异步效率，保证用户的操作能够得到及时反馈。

再比如说为了满足社区在高并发场景下业务 ID 的唯一性和可追溯性，我们实现了一套基于雪花算法（Snowflake）的 ID 生成方案，进一步降低了 ID 生成的延迟。

还有我们通过 Redis 实现了计数统计和用户活跃度排行，并通过先写 MySQL，再删除 Redis 的方案来保证高并发场景下的缓存一致性。

还有在对接讯飞星火、OpenAI 等大模型平台的时候，为了提高代码的复用性和可扩展性，我们采用了策略模式+抽象工厂的模式来实现。

考点1：微信公众号自动登录

用户在前端点击登录时，会展示公众号二维码和待输入的验证码，并会和前端构建一个半长连接，同时保存验证码和半长连接之间的映射关系。

当用户向公众号发送验证码时，微信公众平台会将用户发送信息转发给技术派的服务器，然后通过验证码来识别请求登录的用户身份。

由于验证码保存了和半长链接的映射关系，所以可以找到该半长连接，实现用户的自动登录跳转。

那如何保证验证码的唯一性、唯一设备、唯一用户识别，以及刷新验证码时，如何将之前的验证码置为失效呢？

登录后，如何通过 Cookie 和 Seesion 机制实现登录鉴权呢？

由于内容较多，这块详见技术派教程。

考点2：通过 RabbitMQ 实现消息异步解耦

首先说一下，为什么要异步解耦？

当用户订阅、点赞、评论时，就会触发消息通知，如果当用户操作时，消息同步发送，当消息出现异常时，会影响主流程，或者当消息过多时，也会有影响服务的性能，所以需要对消息进行异步解耦。

选择 RabbitMQ 的原因是什么呢？

首先是社区活跃度高，然后 RabbitMQ 还提供了有一个易用的用户界面，可以让用户监控和管理消息，同时我们的系统对并发要求没有那么高，消息通知也可以无序，且 RabbitMQ 也支持消息路由，宕机后的消息也能自动恢复，所以就选择了 RabbitMQ。

由于是应届生，所以面试官一般不会考察消息队列的选型，万一考了，可以看看后面“工作 0-3 年”的回复。

考点3：MySQL + Redis 相关知识点

问题 1：如何提高系统并发呢？

其实主要是在 MySQL 上游加一层 Redis 缓存，因为 Redis 支持集群、分片，单机就可以支持上万 QPS，所以可以大大提高系统性能。

实现方式主要是将热点数据放入 Redis 缓存，比如文中的分类和标签，使用频率会非常高，因为这些数据不会经常变动，且后台配置完毕后，会实时存入缓存中，非常适合作为热点缓存，并对热点缓存设置失效时间，比如 30 分钟，可以作为 Redis 和 MySQL 不一致的兜底策略。

然后对于计数、排行榜等，也可以依托 Redis 来实现。

问题 2：为什么可以用 Redis 实现计数和排行榜？如何实现？

由于 Reids 的内存具有高性能和存储能力，并且实现原子性操作，所以非常适合用来做简单的计数统计，通常会使用 INCR 或者 INCRBY 来完成自增操作，就可以实现实时计数功能。

对于如何通过 Redis 实现排行榜，详见技术派教程。

问题 3：如何解决 MySQL 和 Redis 缓存的一致性问题呢？

这个问题应届生一般问的不多，可以参考 “工作 0-3 年” 的回答。

考点4：图片自动转换等其它知识点

由于很多博主会将 MarkDown 格式的数据，直接 Copy 到我们的文本编辑器，但是里面的图片链接，由于是通过第三方工具生成，所以不一定能打开，所以需要将这些图片的链接进行转换。

我们会识别文章里面所有的图片链接，然后将这些图片批量上传到 OSS 图片服务器，实现图片链接的自动转换。

除了实现了 MarkDown 格式的图片链接自动转换，用户也可以手动上传本地图片，主要是为了方便习惯在文章编辑器直接写文的同学，支持功能的多样性。

考点5：管理后台相关知识考点

后台界面是基于 React 的一套开源系统，采用前后端分离的方式，我们是基于该套框架进行二次开发。

管理后台主要是用于 PC 端日常的运营和配置工作，主要包括 6 大模块，分别是运营配置、文章管理、教程配置、数据统计、标签和分类管理、用户权限管理。

由于我们有专门的前端同学，所以我主要负责后台这块，后台的功能开发其实都不难，但是很好地锻炼我的编程能力。

考点 6：CDN 缓存过期策略

CDN（内容分发网络）的过期策略对于优化内容传递速度和减少带宽消耗至关重要。CDN 缓存过期策略（Cache Expiration Strategy）决定了缓存内容在 CDN 边缘节点上保存的时间。

在设定 CDN 的过期策略时，需要平衡缓存内容的新鲜度和资源的加载速度。

技术派中的静态资源大部分是存储在阿里云的 OSS 中，然后通过 CDN 进行转发，可以在 CDN 的管理后台配置静态资源的过期时间。

技术派：CDN 过期时间

对于 JavaScript 和 CSS 文件，也可以通过 Thymeleaf 的 src 和 href 属性控制资源路径以保证 CDN 的及时更新。

th:src="${global.siteInfo.oss + '/js/biz/loadMore.js'}"
th:href="${global.siteInfo.oss + '/css/views/home.css'}"

除了上传至 OSS，也可以将静态资源上传至服务器，并通过 Nginx 配置实现动静分离。

server {
    location / {
        proxy_next_upstream error timeout http_502 http_504;
        proxy_set_header X-real-ip  $remote_addr;
        proxy_pass http://127.0.0.1:8080/;
        proxy_redirect default;
        proxy_intercept_errors on;
    }
    
    location ~* ^.+\.(ico|gif|jpg|jpeg|png)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
        
        proxy_pass         http://paicoding_host;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

expires 为不支持 Cache-Control 的旧浏览器提供一个明确的过期时间（当前时间加 30 天）。
Cache-Control：为支持 Cache-Control 的浏览器提供更精确的缓存控制，指示资源在 30 天内有效。

1.3 社招核心面试点

考点1：架构和方案设计

该系统包括前端和运营后台，前端主要划分 5 大模块，包括登录鉴权、用户中心、文章教程、评论、消息通知，整个生态其实主要围绕用户和文章来展开；运营后台主要对文章、教程、标签、广告位、用户权限进行管理。

对于登录鉴权，我们主要依托微信公众号，通过扫描完成系统自动登录，这个主要是和微信第三方信息对接，同时借助 Cookie 和 Session 机制，实现登录鉴权。

对于文章教程，借助开源的 Markdown 文本编辑器，结合 OSS 图片服务器，实现图片自动转链和上传。

同时在高并发、异步、效率这块，也进行了很多设计，通过 RabbitMQ 实现消息异步解耦；通过 Redis 承接高并发流量，并解决 MySQL 和 Redis 的一致性问题；通过 ES 去承接文章搜索功能，提高文章搜索效率；通过 MongoDB 实现高效计数等。

目前服务也是通过多机部署，DB 采用分库分表 + 集群模式，Redis 也是集群模式，进一步提升服务的稳定性、容错性和吞吐量。

考点2：微信公众号自动登录

用户在前端点击登录时，会展示公众号二维码和待输入的验证码，并会和前端构建一个半长连接，同时保存验证码和半长连接之间的映射关系。

当用户向公众号发送验证码时，微信公众平台会将用户发送信息转发给技术派的服务器，然后通过验证码来识别请求登录的用户身份。

由于验证码保存了和半长链接的映射关系，所以可以找到该半长连接，实现用户的自动登录跳转。

那如何保证验证码的唯一性、唯一设备、唯一用户识别，以及刷新验证码时，如何将之前的验证码置为失效呢？

登录后，如何通过 Cookie 和 Seesion 机制实现登录鉴权呢？

由于内容较多，这块详见技术派教程。

考点3：通过 RabbitMQ 实现消息异步解耦

首先说一下，为什么要异步解耦？

为什么选择 RabbitMQ，不选择其它的消息队列呢？

目前常用的消息队列有 Kafka、RocketMQ 、RabbitMQ 和 ActiveMQ，对于 Kafka，它主要适用于大量数据的互联网服务的数据收集业务；对于 RocketMQ，吞吐量非常高，支持消息时序，对可靠性要求很高的场景会更合适，比如电商业务；对于 ActiveMQ，目前社区维护少，就直接放弃。

那么对于 RabbitMQ，虽然语言是 erlang，不利于二次开发和维护，但是社区活跃度高，同时我们的系统对并发要求没有那么高，消息通知也可以无序，同时 RabbitMQ 也支持消息路由，宕机后的消息也能自动恢复，还提供了有一个易用的用户界面，可以让用户监控和管理消息，所以就选择了 RabbitMQ。