- 博客(2480)
- 资源 (1)
- 收藏
- 关注
RSS订阅
原创 你不是 leader，怎么推动事情走下去？
你不是指挥官，但你是facilitator —— 促动者，让人听你不是因为你大，而是你有组织力。有时候你不说话，事情就真没人记得了。不是你说了算，但你提的方案有道理，大家就会照你说的做。为了不耽误进度，我先拟了一个初步下一步，欢迎补充修改。不是甩锅，而是聪明地引入该出现的人，顺带洗清责任。提前提醒一下，如果要推进，可能需要领导的决策。你作为这方面的专家，是不是可以牵头一下这块？这边我草拟了一个初步方案，欢迎大家补充建议。我只是想帮大家对齐一下，方便推进下一步。我把这个加进我们的进度表，方便持续关注。
2025-06-26 00:16:36
662
转载 服务端高并发分布式架构演进之路
1. 概述本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径2. 基本概念在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署
2021-05-25 17:47:54
494
转载 警惕软件复杂度困局
简介：对于大型的软件系统如互联网分布式应用或企业级软件，为何我们常常会陷入复杂度陷阱？如何识别复杂度增长的因素？在代码开发以及演进的过程中需要遵循哪些原则？本文将分享阿里研究员谷朴关于软件复杂度的思考：什么是复杂度、复杂度是如何产生的以及解决的思路。较长，同学们可收藏后再看。写在前面软件设计和实现的本质是工程师相互通过“写作”来交流一些包含丰富细节的抽象概念并且不断迭代过程。另外，如果你的代码生存期一般不超过6个月，本文用处不大。一 软件架构的核心挑战是快速增长的复杂性越是...
2021-05-19 18:17:58
746
转载 常见代码重构技巧，非常实用
关于重构为什么要重构项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。造成这样的原因往往有以下几点：编码之前缺乏有效的设计 成本上的考虑，在原功能堆砌式编程 缺乏有效代码质量监督机制对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。什么是重构重构一书的作者Martin..
2021-05-13 10:01:52
1298
转载 JAVA线上故障排查全套路
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。一、CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用js
2020-09-22 17:45:24
542
转载 图解+代码|常见限流算法以及限流在单机分布式场景下的思考
大家好，我是 yes。今天来说说限流的相关内容，包括常见的限流算法、单机限流场景、分布式限流场景以及一些常见限流组件。当然在介绍限流算法和具体场景之前我们先得明确什么是限流，为什么要限流？。任何技术都要搞清它的来源，技术的产生来自痛点，明确痛点我们才能抓住关键对症下药。限流是什么？首先来解释下什么是限流？在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。题外话：我之前看到个新闻，最不想卖门票的景区“
2020-09-22 13:06:08
657
转载 springboot实现定时任务,异步操作,统一结果返回,全局异常处理,拦截器及事务处理
本文都是springboot的常用和实用功能,话不多说开始吧定时任务1.启动类开启注解@EnableScheduling //开启基于注解的定时任务@MapperScan("com.pdzx.dao")@SpringBootApplicationpublic class VideoApplication { public static void main(String[] args) { SpringApplication.run(VideoApplicatio
2020-08-26 20:22:41
2082
原创 聊聊微服务架构及分布式事务解决方案
分布式事务场景如何设计系统架构及解决数据一致性问题，个人理解最终方案把握以下原则就可以了，那就是：大事务=小事务（原子事务）+异步（消息通知），解决分布式事务的最好办法其实就是不考虑分布式事务，将一个大的业务进行拆分，整个大的业务流程，转化成若干个小的业务流程，然后通过设计补偿流程从而考虑最终一致性。什么是事务事务（Transaction）及其ACID属性事务是由一组SQL语句组成的逻...
2020-04-21 22:34:45
710
转载 Java线程池实现原理及其在美团业务中的实践
随着计算机行业的飞速发展，摩尔定律逐渐失效，多核CPU成为主流。使用多线程并行计算逐渐成为开发人员提升服务器性能的基本武器。J.U.C提供的线程池ThreadPoolExecutor类，帮助开发人员管理线程并方便地执行并行任务。了解并合理使用线程池，是一个开发人员必修的基本功。本文开篇简述线程池概念和用途，接着结合线程池的源码，帮助读者领略线程池的设计思路，最后回归实践，通过案例讲述使用线程...
2020-04-03 14:58:43
801
转载 Synchronized 和 Lock 锁在JVM中的实现原理以及代码解析
一、深入JVM锁机制：synchronizedsynrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null对象作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁...
2020-04-01 16:00:25
627
转载 一文带你理解Java中Lock的实现原理
当多个线程需要访问某个公共资源的时候，我们知道需要通过加锁来保证资源的访问不会出问题。java提供了两种方式来加锁，一种是关键字：synchronized，一种是concurrent包下的lock锁。synchronized是java底层支持的，而concurrent包则是jdk实现。关于synchronized的原理可以阅读再有人问你synchronized是什么，就把这篇文章发给他。在这里...
2020-04-01 15:04:40
988
转载 业务复杂=if else？刚来的大神竟然用策略 工厂彻底干掉了他们！
对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。一旦代码中if-else过多，就会大大的影响其可读性和可维护性。首先可读性，不言而喻，过多的if-else代码和嵌套，会使阅读代码的人很难理解到底是什么意思。尤其是那些没有注释的代码。其次是可维护性，因为if-else特别多，想要新加一个分...
2019-10-24 13:41:06
942
转载 springboot 每个 web 请求是一个线程吗？
Spring Boot 服务挂了，但 CPU 利用率只有 3%。内存没满，磁盘没满，网络也通。什么资源都没耗尽，请求就是进不来。这种场景在用 Spring Boot 的团队里不算罕见。200 个工作线程全部卡在等 IO——等数据库、等第三方接口、等 Redis——没有一个线程空出来接新请求。CPU 闲着是因为线程什么计算都没做，纯粹在等。搞清楚 Spring Boot 底下的线程模型到底是怎么回事，这种问题就不用排查半天了。
2026-03-18 04:09:06
25
转载 生产事故！一个 @Transactional 注解，把数据库连接池打爆了
/ 自定义事件类// 构造器+getter// 监听器 (解耦 + 异步)@Component// 关键注解：只有在事务成功提交后，才执行这个监听器// 这样保证了：如果数据库回滚了，就不会发短信@Async("taskExecutor") // 异步线程池执行，不阻塞主线程@Async// 自定义拒绝策略 (打印日志 + 降级处理)// 对于非核心业务（如发短信），宁可丢弃也不要拖死主流程。
2026-03-18 04:02:49
48
转载 COLA DDD
从这里出发，就会产生很多有意思的东西：比如，什么样的业务需要聚合在一起，什么样的服务要分开。所以，后面又引入了一些DDD之类的方法论，指导大家去实现业务模型到代码结构的映射关系。还有很多这种等等，，但是只要你明白整体是怎么回事儿，那么就很容易理解这些细节了。到这个层次，大家应该明白，上面提到的所有的东西，都是为了解决业务复杂度的。，都是为了搞定技术复杂度的，解决技术难题，引入开源组件这些。大家都知道，我们搞软件研发的，面临两大复杂度，深入懂业务的不懂代码，深入懂技术的不了解业务。而业务复杂度，我们一般用。
2026-03-02 21:48:32
22
原创 Spring httpMessageConverter（七）
传参本质：前端传参的核心是遵循 HTTP 协议，不同传参方式对应 Request 不同存储位置，这是所有处理的基础；封装逻辑：Tomcat 完成 Request 基础封装，Spring MVC 完成扩展封装（路径 / 文件参数），最终参数分布在 Request 的不同属性 / 方法中；处理核心：Spring MVC 通过「参数解析器链」完成参数提取，通过「WebDataBinder+ConversionService+HttpMessageConverter」完成参数转换，注解是解析器匹配的关键标识；
2026-02-09 01:40:30
631
原创 Spring httpMessageConverter（六）
/ 1. 自定义转换器@Component@Override// 2. Controller方法// 前端传 hobby=篮球,游戏 → String "篮球,游戏" → List<String> ["篮球","游戏"]// 底层：ConversionService 调用自定义 StringToListConverter 转换参数提取：核心是「按来源精准取值」，不同参数来源对应 HttpServletRequest 不同存储位置，由专属解析器完成提取，遵循懒加载、多值优先取数组的规则；
2026-02-09 01:29:55
648
原创 Spring httpMessageConverter（五）
不加注解：仅适用于「简单类型（查询 / 表单参数）」或「实体类（查询 / 表单参数）」，依赖 Spring 按参数名自动匹配，规则固定、灵活性差；加注解：显式指定参数来源（路径 / 请求体 / 请求头等）、匹配规则（参数名映射、非必传、默认值），覆盖默认逻辑，支持复杂场景，且代码可读性更高；底层逻辑。
2026-02-09 01:17:48
604
原创 Spring httpMessageConverter（四）
路径参数：URL 路径中，标识资源唯一 ID，用接收。查询参数：URL 末尾，用于筛选 / 分页，用接收。请求体参数：请求体中，传递复杂数据，JSON 用，表单用，文件用。请求头参数：请求头中，传递非业务参数（Token），用接收。Cookie 参数：客户端存储，自动携带，用接收。实际开发中可根据参数用途选择传参方式：业务标识用路径参数，筛选条件用查询参数，复杂数据用请求体，通用配置用请求头 / Cookie。传输层面。
2026-02-04 00:59:31
510
原创 Spring httpMessageConverter（三）
Data// 日期字段，测试默认转换格式默认的日期格式是 ISO 格式，实际开发中我们常需要自定义（如），这就需要自定义的配置。// 自定义JSON转换器@Override// 1. 创建Jackson的ObjectMapper（核心：自定义序列化规则）// 自定义日期格式// 忽略null字段（返回结果不显示null的属性）// 关闭默认的日期时间戳转换// 2. 创建自定义的MappingJackson2HttpMessageConverter。
2026-02-04 00:48:52
590
原创 Spring httpMessageConverter（二）
的底层入口是，由触发调用，核心依赖 Servlet 的处理字节流。请求转换（read ()）：根据+ 目标类型匹配转换器，底层调用 Jackson 等序列化框架将字节流转为 Java 对象。响应转换（write ()）：根据Accept头 + 返回值类型匹配转换器，底层将 Java 对象序列化为字节流，写入响应输出流。转换器的注册由 Spring Boot 自动配置完成，也可通过自定义，顺序决定优先级。
2026-02-04 00:43:21
620
原创 Spring httpMessageConverter（一）
在 HTTP 请求 / 响应的报文（Message）和 Java 对象（Object）之间做双向转换。简单类比：它就像一个「翻译官」，把前端发来的 JSON/XML 等格式的 HTTP 请求体，翻译成后端能识别的 Java 对象；也能把后端要返回的 Java 对象，翻译成前端能识别的 JSON/XML 等格式的 HTTP 响应体。// 判断当前转换器是否支持将请求报文转换为指定的Java类型// 判断当前转换器是否支持将指定Java类型转换为响应报文。
2026-02-04 00:37:19
624
原创 springMVC开发手册V2.0
一、普通形式一、普通形式第一种第二种第三种第四种第五种二、json形式例子第一种第二种总结三、日期类型四、响应第一种第二种第三种第四种总结。
2026-02-03 13:30:18
30
转载 token的失效与续签问题
① 类似于 Session 认证中的做法： 假设服务端给的 token 有效期设置为30分钟，服务端每次进行校验时，如果发现 token 的有效期马上快过期了，服务端就重新生成 token 给客户端。客户端每次请求都检查新旧token，如果不一致，则更新本地的token。说明：JWT 最适合的场景是不需要服务端保存用户状态的场景，但是如果考虑到 token 注销和 token 续签的场景话，没有特别好的解决方案，大部分解决方案都给 token 加上了状态，这就有点类似 Session 认证了。
2026-02-01 03:10:55
90
原创 springMVC开发手册
MVC是一种软件架构的思想，将软件按照模型、视图、控制器来划分M：Model，模型层，指工程中的JavaBean，作用是处理数据JavaBean分为两类：V：View，视图层，指工程中的html或jsp等页面，作用是与用户进行交互，展示数据C：Controller，控制层，指工程中的servlet，作用是接收请求和响应浏览器MVC的工作流程：用户通过视图层发送请求到服务器，在服务器中请求被Controller接收，Controller调用相应的Model层处理请求，处理完毕将结果返回到Controller
2026-02-01 00:49:33
653
原创 DDD 领域驱动设计（五）
核心工作：明确不同限界上下文之间的交互关系，定义跨域调用的方式、接口协议，避免跨域紧耦合；落地方法梳理所有跨上下文的业务交互场景（如 “订单上下文” 需要调用 “库存上下文” 扣减库存）；为每个交互场景匹配DDD 上下文映射模式，企业落地优先选择 3 种轻量化模式，复杂场景再用其他模式；核心映射模式（企业落地首选）映射模式适用场景落地方式电商示例客户 / 供应商（Customer/Supplier）一个上下文依赖另一个上下文的核心能力，双方为内部团队，可协同优化。
2026-01-29 02:21:23
907
原创 DDD 领域驱动设计（四）
聚合的唯一入口和管理者，是有唯一 ID、有生命周期、有状态的业务实体，负责聚合内所有对象的一致性校验和业务行为封装，聚合内其他对象（值对象 / 子实体）通过聚合根访问。无唯一 ID、无生命周期、属性不可变的业务对象，用于描述聚合根的属性或属性组合，仅关注 “是什么”，不关注 “是谁”，通过所有属性的值判断相等性。为领域层提供数据持久化和查询的抽象接口，屏蔽底层存储介质的细节（MySQL/Redis/ES/ 内存），让领域层无需关注数据如何存储、从哪读取，仅通过仓储操作领域对象。无状态、纯业务逻辑。
2026-01-29 02:17:28
769
原创 DDD 领域驱动设计（三）
可以把这两个模型理解为 “业务逻辑该放在哪里” 的两种设计思路，核心区别是领域对象是否包含业务行为模型类型核心特征形象比喻贫血模型领域对象（如 User、Order）仅包含属性（get/set 方法），无任何业务逻辑；业务逻辑全部放在 Service 层。只有 “数据” 的 “空壳对象”，所有 “行为” 都由外部的 “管家”（Service）完成充血模型领域对象不仅包含属性，还封装了与自身相关的所有核心业务逻辑（方法）；Service 层仅做协调、编排，不包含核心业务规则。
2026-01-29 01:57:24
663
原创 DDD 领域驱动设计（二）
DDD 不是 “银弹”，而是解决复杂业务问题的方法论对复杂业务、跨团队协作、长期维护的系统，DDD 能显著提升系统的可维护性和业务适配性，长期投入产出比极高；对简单业务、短期项目、小团队，DDD 的成本大于收益，不如选择更轻量的架构；很多人觉得 DDD “不好用”，本质不是方法论的问题，而是落地方式的问题（生搬硬套、建模脱离业务、过度设计）。业务复杂度决定是否用 DDD，团队认知决定能否用好 DDD。
2026-01-29 01:41:21
658
原创 DDD 领域驱动设计（一）
DDD（领域驱动设计）是一种软件开发方法，核心是让代码结构紧密贴合业务本质，特别适合处理复杂业务逻辑的系统。它通过（如实体、值对象）和（团队共享的业务术语）来实现这一点，强调业务逻辑应主导技术实现。
2026-01-29 01:19:44
193
原创 微服务架构下的服务治理难题（三）
核心链路（商品 / 订单 / 支付 / 库存）优先落地，基础层 0-3 个月闭环，进阶层 3-6 个月攻坚，高阶层 6-12 个月打磨，每个月聚焦 3-5 个核心任务，明确，适配电商大促节奏（建议第 6/12 个月对接大促，做全链路验证）。：按业务域划分 7 个全栈团队（商品 / 用户 / 购物车 / 订单 / 支付 / 库存 / 物流），各团队设 1 名服务负责人；单独设（统筹治理、技术选型、评审）、（负责中间件 / 集群 / 自动化）、（负责压测 / 用例 / 环境）。
2026-01-11 21:43:33
884
原创 微服务架构下的服务治理难题（二）
按DDD 领域驱动拆分核心域，仅拆分为商品、用户、购物车、订单、支付、库存、物流7 大核心服务，拒绝过度拆分（如不单独拆 “商品分类服务”“商品评价服务”）输出服务依赖关系图，明确核心服务间仅允许单向依赖（如订单→库存→商品，禁止库存→订单），杜绝任何循环依赖制定服务接口规范：RESTful 为主（开放平台用），核心链路内部用 gRPC（提升性能），所有接口必带版本号（如 /v1/order/create），主版本号变更需做兼容性评审验收标准。
2026-01-11 21:37:26
664
原创 微服务架构下的服务治理难题（一）
微服务架构下的服务治理，不是一个 “一次性的架构设计问题”，而是一个 **“持续迭代的系统工程”**—— 其难题随服务规模、业务复杂度、团队数量的变化而动态演变，不存在 “一劳永逸” 的解决方案。很多企业在微服务落地中陷入 “治理困境”，核心原因是过度关注技术拆分，而忽视了架构、流程、组织的协同改造：仅把单体应用拆分为多个微服务，却未建立统一的治理体系，未调整组织架构和协作流程，最终导致 “微服务的坑比单体还多”。
2026-01-11 21:26:22
618
原创 Redis锁与DB锁
场景特征推荐使用原因高并发、短事务、非核心数据Redis 锁性能高，能支撑高并发，少量异常可通过业务兜底解决低并发、长事务、核心数据DB 锁（SELECT FOR UPDATE）事务 ACID 保障数据安全，无锁过期风险，满足合规审计要求幂等性控制（如重复支付）DB 锁（唯一索引）无需锁等待，性能高于悲观锁，能有效防止重复写入分布式系统、跨服务并发Redis 锁天然支持分布式，跨服务 / 跨机器的锁控制更简单单服务、本地并发本地锁（synchronized）
2026-01-01 02:05:18
723
原创 组合索引（MySQL）
场景最左匹配作用索引下推作用回表次数无 ICP（仅最左匹配）筛选出 name 符合条件的索引无作用，不参与 age 过滤3 次有 ICP（两者结合）筛选出 name 符合条件的索引引擎层提前过滤 age 符合条件的索引2 次。
2025-12-21 03:39:17
705
原创 有关MyBatis几个功能的理解
MyBatis 的延迟加载（懒加载）是的优化机制，核心是，而非在查询主对象时一次性加载所有关联对象，以此减少无效的数据库交互、提升查询性能。延迟加载基于实现，当查询主对象（如User）时，MyBatis 会返回该对象的代理实例；只有当程序首次调用关联对象的 getter 方法（如）时，才会触发关联 SQL 的执行，加载关联数据。false。
2025-12-21 03:02:45
660
原创 Gateway 对比 Kong（二）
高并发、高流量的公网入口（如官网、APP 后端入口）。多语言微服务架构，需要统一网关策略。追求低运维成本，希望网关配置、扩展无需开发介入。重视稳定性和成熟度，需要生产级验证的网关方案。
2025-12-19 23:06:11
754
原创 自定义通讯协议
在设计协议前，需遵循以下原则，确保协议的稳定性、可扩展性、兼容性和性能简洁性：协议格式尽量简化，减少冗余数据，降低解析开销（尤其嵌入式 / 低带宽场景）。可扩展性：预留版本字段、扩展字段，支持协议升级（如 V1→V2 兼容）。可靠性：包含校验机制（如校验和、CRC），检测数据传输中的错误；支持重传、确认机制（如 TCP 的 ACK，UDP 场景需自定义）。安全性：可选加密（如 AES）、签名（如 RSA/SHA），防止数据篡改或窃取。跨平台。
2025-12-11 00:29:19
837
原创 ThreadLocal 强软弱虚
/ Thread 类中的成员变量// 每个线程独有// ThreadLocalMap 类（ThreadLocal的内部类）// Entry 数组：哈希表的核心// Entry 类：Key是ThreadLocal的弱引用，Value是强引用>> {// 业务数据（强引用）super(k);// 调用WeakReference的构造方法，将k作为弱引用存储value = v;// Value是强引用// ThreadLocal的set方法（简化版）if (map!= null) {
2025-12-11 00:22:06
1008
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人