简历和面试辅导

简历怎么写

简历辅导

⻩⾦法则： 清晰！亮点！匹配度！让别⼈看了你的简历就想约你⾯试！

项⽬介绍：说清楚你写了个什么项⽬，能⼲啥，有啥⽤，有数据⽀撑最好！

个⼈职责：写清楚你在项⽬⾥作为什么⻆⾊，做了哪些事情，抓住重点写！写到别⼈的⼼坎⾥。项⽬收获：这个项⽬给公司带来啥收益，你从这个项⽬学到了啥。

你写到简历上的项目要有一个项目背景（无论是你编的还是你实际工作过过的都要事先准备好一个项目背景）；项目背景就是你在一个什么样的公司写了一个什么样的项目，你在其中做了什么。（要尽量真实一点，没有真实的也得真实起来。）
这个项目的优势是可以在任意公司的任意系统中存在（只要有用户登录，就可以说有签到这么个功能，不违和），缺点是如果只写个签到功能会比较单薄，重点是突出【签到功能】的底层设计和【积分兑换】的事务操作，积分兑换可以支持道具、优惠券、实物等，当然你也可以把这个签到中心和账号中心、会员服务、任务中心等关联起来。
比如：我之前实习/工作的公司是一个xxx的公司，有一个网站/APP/小程序，我进公司之后在用户中心或者会员中心，部门主要是做一些用户运营和用户增长相关的业务，提供基本的用户注册、登录等信息管理，通过一些运营活动来提升用户留存。
组里大概有多少个人（小公司一个组三五个人差不多），当时我作为/跟着组长/leader从零做了一个签到系统，通过引入积分系统吸引用户每天来签到，后续会出兑换礼品的功能。

把签到系统项目写到简历上的示例

项⽬介绍：作为公司 xx 小程序用户增长的核心抓手，签到中心通过每日签到、积分体系构建用户活跃闭环，目标提升用户留存率与会员转化效率。项目上线后，带动小程序 MAU 从 500 万增至 630 万（提升 26%），为会员服务日均引流 1.2 万新用户，占会员新增量的 18%，成为用户活跃与会员体系的关键连接节点。

核心架构：打通账号系统、会员系统及任务系统，构建 “签到行为 - 积分积累 - 权益兑换” 全链路服务，支撑日均 10 万 + 签到请求与 2 万 + 积分兑换操作。

个⼈职责：

基于 goframe 框架搭建高可用服务，利用其模块化设计与Go并发性能优势，支撑峰值 QPS 800 + 的签到请求，服务可用性达 99.95%。
针对海量签到数据，设计 Redis Bitmap+MySQL 分层存储方案 —— 用 Bitmap 高效存储当日 / 近期签到状态（内存占用降低 60%），支持毫秒级连续签到天数查询；历史数据按周批量持久化至 MySQL，兼顾查询性能与存储成本。
积分兑换支持虚拟道具（如补签卡、优惠券）与实物礼品的差异化兑换流程；
基于 MySQL 事务 + 分布式锁实现积分扣减与礼品发放的强一致性，保障兑换过程零资损，兑换成功率稳定在 99.9% 以上。
根据运营策略编写 lua 脚本，对即将断签的用户发送签到提醒，使连续签到用户占比提升 11%；

项⽬收获

主导签到打卡服务向服务化、平台化发展，抽象出独⽴的签到中心能⼒。
熟练掌握了 goframe 框架的主要特性，能够熟练使⽤ goframe 框架进⾏业务开发。
能够灵活使⽤ MySQL、Redis 解决业务中的存储痛点问题。
锻炼了⾃⼰的⾃主学习能⼒，积累了⼤型项⽬设计和开发经验。

面试可能会问的问题

0、MySQL 事务是一定会被问到的点

直接点链接查看👉 牛客网MySQL事务相关的面试真题

1、如何保证MySQL和Redis的数据一致性

在典型的互联网应用架构中，MySQL 作为关系型数据库，提供 ACID 事务保证；而 Redis 通常用作缓存或高性能键值存储，其事务 (MULTI/EXEC) 是原子性的，但不支持跨多个 Redis 命令的回滚，更不支持与外部系统 (如 MySQL) 的分布式事务 (XA/2PC)。

因此，我们无法实现一个能同时原子性地覆盖 MySQL 和 Redis 操作的“真”分布式事务。我们需要采用最终一致性的策略，并优先保证核心数据存储 (MySQL) 的一致性

使用消息队列实现最终一致性 (更复杂，适用于高并发或解耦场景)

启动 MySQL 事务。
执行核心数据库操作 (如上所述)。
在同一个 MySQL 事务中，向一个“本地消息表”或“事务性发件箱表” (Transactional Outbox Pattern) 插入一条消息。 这条消息包含了需要对 Redis 进行的操作信息 (例如，用户ID，新的总积分等)。
提交 MySQL 事务。
- 如果事务成功，数据库操作和“待发送消息”都已持久化。
- 如果事务失败，所有更改 (包括消息) 都会回滚。
一个独立的后台轮询进程或消息中继服务：
- 定期扫描“本地消息表”。
- 将消息发送到真正的消息队列 (如 Kafka, RabbitMQ)。
- 发送成功后，标记或删除本地消息表中的消息。
另一个独立的消费者服务：
- 从消息队列消费消息。
- 根据消息内容更新 Redis 缓存。
- 处理消费失败的情况 (重试、死信队列等)。