有关简历如何准备
下面看看做简历这款
- 做简历或者还有一种方式，把“了解”换成具备 XXX 技术或者工具类的实战经验，并且有过 XXX 的项目实战使用。
- 一定要有技术选型、设计方案等字眼出现！
- 上面的简历存在中英文排版的问题，中英文之间要存在空格！
- Spring 这块千万别写了解，IOC 和 AOP 必须熟悉，而且一般就问问浅层的 Bean 生命周期，代理模式，Bean 注入，设计工厂，也不会跟你三级缓存，Spring 配置文件这种去跟你讲。
- RocketMQ 这块也是一样，关于微服务、中间件等，尽量就是在技术栈去写他的八股文相关的知识，可靠性，死信队列，幂等性，重复消费，等等，从小点切入，别写太大，让面试官可以提问的情况下，你也可以提前准备，相当于提前背题库！
- 不建议大家项目中写 ES，毕竟这是一个完全没必要的情况，大多数公司的量级都达不到使用 ES 的级别，而且维护起来更加复杂，当然可以花钱买 ES 服务。
指简历上全是技术点堆砌，没有业务支撑？
尽量结合业务说技术点优化，比如，写了“基于redis ，优化查询”，可以基于你的业务系统，改为“针对某某系统（电商、物流、供应链、营销之类，你真实负责的业务系统）的某个问题，设计了某某多级缓存架构，然后列具体的技术点实现，最后实现了什么优化结果（核心链路接口耗时降低到多少毫秒以内巴拉巴拉）”，这样你就可以更好地准备面试的点，因为你给了面试官绳索，“按图索骥”减少面试官的思考，你也轻松一些，要准备的八股内容就更有针对性一些。
简历格式方面：
简历名称与格式： 一定要包括姓名、求职意向（岗位）、“简历”，格式强制PDF，信息之间用下划线分隔，不要有空格。
例如：
神里绫华_Java后端开发_简历.pdf。
技术栈方面
技术垂直
·熟悉 Java 语言，阅读过 jdk17 核心源码，包括常用集合包、常用并发包、线程池、并发工具类等核心类，有并发编程实战经验。
·熟练使用MySQL ，深入研究过Innodb存储引擎原理，熟悉锁机制、索引原理，有线上系统SQL优化经验，有分库分表经验。
增加了技术栈的细节与深度，不是泛泛而谈。
业务垂直
3 年供应链系统开发经验，深入供应链-物流一线系统开发，有百万行复杂业务系统重构经验，对长链路系统的数据一致性问题有深入理解和生产实践经验。
如何梳理简历项目亮点
如何梳理项目？
先讲一个小点，关于架构梳理。 主流的架构划分一般有4 种：业务架构、技术架构、应用架构、数据架构。
业务架构，是系统蓝图，主要描述的是： ·做什么（目的） ·为谁做（客户） ·怎么做（方法）
比如你在一家电商公司，那公司的业务目的就是方便他人买卖东西，客户就是商家和买家，方法就是打通供应链，打通商家与客户信息桥梁。 我们写项目简历之前可以思考怎样用浅显易懂和简短的语言，让面试官理解你们系统的整体业务目的，为什么要做这个项目。
技术架构，技术架构是我们最熟悉的架构，阐述了系统的基础设施和工具链：部署环境（上云、自建）、微服务架构（单体架构）、技术栈。 在这一步，我们就可以埋下钩子，引导面试官提出你熟悉的技术栈问题。
应用架构，大概讲一下你的系统拆分或者你的模块拆分，比如订单、支付、库存、履约等子系统或模块。 在这一步，开始进入项目场景的沟通，面试官大概率会问一些延伸出来的场景题，或者针对系统薄弱点，提出连环炮问题。
数据链路依附于业务流程，比如订单的正向链路（下单、支付、履约）与逆向链路（退单、退款、退货履约），订单数据的流转、钱款的流转、货物信息的流转，抓住核心链路，我们就理解了系统的脉络，写起简历才能有的放矢。
我觉得要想写出项目亮点，得先捋清楚上面四个部分，这是“道”的部分，你可以试着把上面几个架构都在心里过一遍，文字描述+画出架构图，成功后，你就有一个好的开始了。
什么是项目亮点？
简单来说，所谓的“项目亮点”是指能一下抓住面试官眼球的内容。
比如我的简历上写系统是微服务架构的系统。这体现了我解决问题的能力了吗？不太能。 但如果我说因为服务代码量，太过庞大，业务耦合严重，所以我参与做了服务拆分，这就能体现我解决问题的能力，写上去，这就是亮点。
再比如我说用了分布式锁，这体现我解决问题的能力了吗？不能ヽ(`Д´)ﾉ 但如果我说为了解决系统某个业务的并发争用与数据一致性问题，用了分布式锁，这就体现了解决问题的能力，写上去，这也是亮点。
当然，亮点有大有小，有些太过常见的亮点，写的人太多了，面试官也便觉得普通了。这时候就需要考验你技术的深度了： “看你用了这个，你读过它的源码吗？聊一下他的底层实现吧”๑乛◡乛๑
比如架构、技术深度、三高、线上问题等等方面来写。
架构
·针对某某系统业务的日益复杂化所引起的高耦合与低性能等问题，为了降低业务耦合度、优化核心链路性能瓶颈、提高系统的可维护性，作为核心人员深度参与了该系统的边界划分与服务拆分过程，最终将服务拆分为六个子服务，服务解耦后核心链路响应时间降低30%，研发效率提升40%，支持独立部署与弹性伸缩。
·针对某某业务对数据强一致性的要求，调研引入 Seata 管理分布式事务，采用AT模式实现权益数据（涉及资损）的一致性。
·针对某某业务对数据最终一致性的要求，调研采用定时任务、本地消息表与 rocketmq 事务消息相结合的方案，保障核心链路的数据一致性与高吞吐量。
·针对B端业务定制化需求复杂多变的问题，基于 SPI 机制自研插件化开发组件，通过标准化接口与动态加载能力，使开发者可灵活实现扩展点并快速集成，最终提升定制效率50%，降低核心模块耦合度70%，覆盖80%的定制场景。
·针对订单生命周期管理中状态流转逻辑复杂、硬编码导致维护困难的问题，采用状态模式与事件驱动自研状态机框架，支持订单状态（待支付/已发货/已完成等）的动态配置与事务一致性，最终实现订单状态处理代码量减少60%，异常流转错误率下降90%，并支撑日均百万级订单稳定运行。
·针对某某核心系统数据库性能瓶颈与复杂查询压力问题，设计并实现多级缓存架构（本地Caffeine + Redis + Elasticsearch），通过分层策略（本地缓存抗流量、Redis削峰填谷、ES缓存复杂查询结果）与热点数据预热机制，最终将核心接口响应时间从200ms降至50ms，数据库QPS下降80%，复杂查询耗时减少70%，系统稳定性提升95%，支撑日均千万级请求与亿级数据检索。
·针对某某业务系统规则、配置多样性而频繁改动硬编码上线问题，设计并实现基于某某开源规则引擎的策略引擎系统，支持规则热加载，减少服务上线与重启频率，上线后需求开发效率提升90%。
·针对核心链路服务定时任务分散、无监控的问题，引入xxl-job作为分布式任务调度中心，实现定时任务的统一管理，方便监控任务状态与异常实时告警，避免线程假死、任务异常等问题，任务异常响应时间缩短90%。
针对 传统线程池静态配置僵化、监控困难及配置变更需重启等问题，基于 Dynamic-TP 动态线程池框架（集成 Nacos 配置中心与 Prometheus 监控），通过运行时热更新线程池参数（核心/最大线程数 5-20）及熔断降级策略，实现资源弹性伸缩与实时监控告警，使系统吞吐量提升 30%、任务响应时间从 200ms 降至 50ms，支撑日均千万级请求的高并发场景。
技术深度
·针对分布式任务调度系统中单节点（基于zk ）任务分发的性能瓶颈问题，自研了集群式调度中心，通过协同调度、动态负载均衡、任务优先级管理和智能资源优化等技术手段，支撑日均过亿 AI 任务的高效分发。
·针对分库分表场景下的全局ID唯一性与高并发生成瓶颈问题，设计并实现基于 Snowflake 变种的高可用 ID 生成服务，通过 ZooKeeper 动态分配 WorkerID 保障节点唯一性，结合分级时钟回拨处理机制（短时回拨自动补偿、长时回拨熔断告警）与 本地 RingBuffer 预生成号段（提前缓存 10 万个 ID）实现 QPS > 50 万，支撑分布式系统日均亿级请求的无损扩容与故障恢复。
·针对某某老旧系统业务数据需要迁移新库问题，使用canal （解析binlog ）+ rocketmq（增量数据消息消费）+ datax（全量数据初始化），实现亿级数据平滑迁移。
·针对某某电商、票务系统库存扣减超卖问题，采用redis与Lua 脚本实现库存原子性检查与扣减，实现库存一致性与高并发控制，保障了该业务系统在千万级流量下的稳定性。
·针对内部核心链路中文件存储模块吞吐量出现瓶颈问题，基于零拷贝技术重构下载功能，实现文件下载吞吐量提升50%，cpu占用率下降30%。
·针对某某复杂业务系统内部锁使用乱象与性能瓶颈问题，梳理并采用细粒度分段锁、cas无锁化设计，使该系统QPS提升30%，锁竞争开销几乎为零。
·针对某某权益中心历史业务债导致的开发迭代困难问题，重新梳理并进行了等级、积分、权益一体化设计，实现业务解耦，业务开发迭代效率提升70%。
·针对 高并发接口被恶意刷接口导致依赖雪崩问题，基于sentinel 设计并实现自研轻量限流框架，支持按 IP、用户 ID、接口 URI 多维限流，结合降级、熔断策略自动熔断慢依赖，提升系统鲁棒性，峰值时段稳定性从 P95 响应 800ms 降至 200ms。
如果没有三高，那就可以从一些细一些的点切入，比如：接口是否做过幂等、简单限流（没接入sentinel或者hystrix ），用户权限是否做过隔离、对接第三方是否做好了重试机制、有没有做过单元测试。如果有报表模块，报表的SQL优化上有什么心得。是否用过设计模式呢？即使是单体系统也可以用到很多设计模式……对于高并发，假想你的系统业务量扩大了一千倍，你会如何重新设计？你的线上jvm现在参数是怎样的，cpu核数、内存配置多少，有过抖动吗？为什么抖动？慢SQL有遇到过吗？慢SQL监控过吗？如果没监控过，换成是你设计，怎么监控……
线上问题
以下是一些线上问题亮点的思考方向（就不按照前述文章示例的格式来写了）：
·慢SQL 的排查：怎么发现的（告警、定期巡检、客户工单），怎么定位到具体的SQL （慢SQL监控、告警、日志)，如何优化（没加索引、索引失效、索引巴拉巴拉、只查必要数据、多表换宽表…），结果如何
·cpu飙升问题：怎么发现的（告警、客户工单），怎么定位到具体问题的，原因是什么（无限递归或循环、线程池计算任务异常、正则回溯、序列化循环引用、算法逻辑漏洞、正常流量激增），如何解决（改代码、换框架、扩容…），结果如何
·内存问题：怎么发现的，堆内、堆外、元空间，如何排查（jvm自带工具、开源工具、自研工具、付费工具），如何解决（优化代码、改jvm参数、扩容…），结果
·存储问题：什么问题（IO慢、磁盘满），如何发现的，如何排查（数据归档、mq消息无限重发、日志异常，我在蛮久之前做dfs系统的时候，遇到过一个分割缩略图文件，导致写inode数量异常的血案，辛酸泪），如何解决，结果如何
还有一些细小的点，比如： ·数据库死锁（今天我又遇到了Ծ‸Ծ） ·接口变慢问题 ·数据更新的ABA问题 ·常见的mq消息丢失、堆积、重复、乱序等问题 ·缓存不一致问题 ·Bigdecimal踩坑 ·海外服务时区问题 ·本地可以、线上报错问题 ·等等等
最后是简历其他建议
对于【开发与运维】这一部分的开发工具内容，我觉得可以不用放,，尤其像 IDEA、Git 这些。因为做 Java 的，对于这些常用工具的使用，其实都太熟悉了。
“寸土寸金”的简历，放上这一行，显得有些不够“专业”了。