- 博客(93)
- 收藏
- 关注
RSS订阅原创 学习日报 20251107｜服务染色”和“灰度发布
灰度发布是目标，服务染色是实现精准灰度的核心手段。通过“打标签 + 按标签路由”，你可以让特定请求像被“染色”一样，在整个微服务调用链中走专属路径，从而安全、可控地验证新版本。如果你用的是，可以结合Nacos 元数据 + 自定义负载均衡实现基础染色；更复杂场景建议引入Service Mesh（如 Istio）或APM 工具（如 SkyWalking）增强透传能力。
2025-11-07 22:03:17
640
原创 学习日报 20251107｜Nacos 注册同一服务多实例架构图
✅同一个服务名（user-service）对应多个实例✅自动注册 + 自动发现✅动态扩缩容：加实例自动加入，宕机自动剔除✅消费者无感知，代码只需写服务名。
2025-11-07 21:58:11
349
原创 学习日报 20251107｜Nacos 做注册中心到底有啥用？为什么微服务架构必须要有注册中心
因为微服务是动态的、分布式的、可能随时上下线的。注册中心就是那个实时掌握所有服务“行踪”的大脑，让服务之间能自动发现、安全通信、弹性伸缩。没有它，微服务架构就失去了“微”和“服务治理”的意义，退化成一堆互相依赖、脆弱不堪的单体应用。所以，注册中心不是“可有可无”，而是微服务架构的“基础设施”，而 Nacos 是目前最主流、功能最全的选择之一（尤其在 Spring Cloud Alibaba 生态中）。
2025-11-07 21:41:48
459
原创 学习日报 20251107｜Nacos基础认识
Nacos注册中心是微服务架构的核心组件，提供服务的注册与发现、健康检查、流量管理等功能。服务启动时向Nacos注册元数据，消费者通过它获取可用服务列表。Nacos持续监控实例健康状态，自动剔除异常节点，并支持权重调整、多环境隔离等治理能力。与Spring Cloud无缝集成，通过可视化控制台管理服务。作为微服务的"电话簿"和"健康管家"，Nacos实现了服务间的自动发现与可靠通信，是构建高可用微服务系统的关键基础设施。
2025-11-07 21:39:52
332
原创 学习日报 20251007｜基于 Redis Sorted Set 实现 “按领取时间分页” 并结合 Hash 存储详情的完整解决方案
摘要：本文提出了一种基于Redis SortedSet和Hash的双结构组合方案，实现高效按领取时间分页查询用户优惠券。SortedSet以时间戳为score存储优惠券ID实现排序，Hash存储优惠券详情，两者配合实现O(logN+K)时间复杂度的分页查询。方案包含缓存查询、数据库同步、缓存更新三大流程，支持降序排序和分页计算，并通过异步操作、批量查询优化性能。采用随机过期时间避免缓存雪崩，缓存空结果防止穿透，确保高并发场景下的稳定性和数据一致性。该方案显著降低数据库压力，适用于电商等需要时间排序展示用户优
2025-10-07 23:00:51
635
原创 学习日报 20251007｜深度解析：基于 Guava LoadingCache 的优惠券模板缓存设计与实现
本文详细解析了基于Guava LoadingCache的优惠券模板缓存设计方案。通过定义线程安全的缓存容器，配置初始容量、最大限制、过期策略等参数，实现了高性能缓存机制。关键设计包括：1）采用Optional包装对象避免空指针；2）支持单key和批量加载；3）通过弱引用防止内存泄漏；4）启用统计功能监控命中率等指标。该方案平衡了性能、可靠性和内存安全，适合高并发电商场景，通过参数调优可进一步提升缓存效率。
2025-10-07 20:32:20
1157
原创 学习日报 20250930｜优惠券事务处理模块
本文介绍了一个优惠券事务处理模块，包含自定义异常类、核心实体类和服务实现。模块通过@Transactional注解保证订单支付后优惠券核销的原子性操作，包含订单状态校验、优惠券合法性验证（用户匹配/状态/有效期）、金额计算等功能。自定义CheckUserCouponException处理校验失败场景，提供错误码便于前端展示。该模块结构清晰，注释完整，可直接集成到电商系统订单流程中，解决优惠券核销与订单状态同步的一致性问题，具有较好的扩展性和事务保障。
2025-09-30 23:16:11
195
原创 学习日报 20250930｜优惠券叠加必须做 “双向校验”
电商优惠券叠加规则需双向校验以确保业务安全。仅检查"A允许与B叠加"而忽略"B是否允许A"的反向校验，会导致规则矛盾、成本失控等问题。双向校验要求两张券必须达成叠加共识才能放行，避免单向授权引发的逻辑漏洞。实际业务中，缺少双向校验可能造成前端展示与支付校验脱节、优惠券违规叠加导致成本超支、以及单模板配置错误影响全链路等问题。代码实现需包含正反双向检查并记录详细日志，形成规则闭环。这一机制是保障优惠券体系安全运行的基础锁，确保平台在灵活满足用户需求的同时有效控制成本风险
2025-09-30 22:54:51
795
原创 学习日报 20250930｜多优惠券叠加核销及场景互斥逻辑
本文提出了一种基于优惠券模板配置的多优惠券叠加核销及场景互斥实现方案。核心思路是通过CouponTemplate定义优惠券的叠加规则（allowStackWith）和适用场景（sceneTags）。实现分为三步：1）扩展CouponTemplate配置叠加规则和场景标签；2）核销前校验多券叠加兼容性，确保每张券都允许与其他券类型叠加；3）校验优惠券场景与订单/商品场景匹配性。该方案通过模板化配置实现灵活控制，无需修改代码即可调整优惠券叠加和场景逻辑，具有强扩展性。
2025-09-30 22:42:21
259
原创 学习日报 20250930｜优惠券核销模块
本文介绍了一个优惠券核销系统的模块化设计方案。系统采用工厂模式+策略模式，通过CouponTypeEnum枚举定义优惠券类型，UserCoupon实体存储优惠券信息，ICouponWriteOffService接口规范核销行为，并由ManJianCouponWriteOffServiceImpl等实现类处理具体核销逻辑。CouponWriteOffFactory工厂类统一管理核销服务，CouponWriteOffService提供统一核销入口。这种设计提高了代码扩展性（符合开闭原则）、可读性（职责单一）和可
2025-09-30 22:36:16
186
原创 学习日报 20250929｜数据库与缓存一致性策略的选择
数据库与缓存的一致性是分布式系统的关键挑战。针对不同场景，可采取多种策略：高并发读场景采用"先更新数据库再删除缓存"；写密集型系统适合消息队列异步更新；金融等强一致性需求需结合加锁机制；最终一致性场景可采用定时任务对比。简单业务可先删缓存后更新数据库，复杂业务则需要读写分离等多策略组合。选择策略时要权衡并发量、一致性要求和业务复杂度，在性能与数据一致性间取得平衡。
2025-09-29 22:59:00
331
原创 学习日报 20250929｜缓存雪崩以及缓存穿透解决方案
本文介绍了Redis缓存问题的两种解决方案：1）缓存雪崩通过随机过期时间工具类避免集中失效，采用基础时间+随机偏移（5-30分钟）；2）缓存穿透采用参数校验拦截无效请求，对不存在数据设置短期"无效标记"（如"NOT_EXIST"或-1），避免重复查询DB。代码示例展示了优惠券和用户场景的实现，强调工具类复用和业务区分，有效提升系统性能和稳定性。
2025-09-29 22:51:48
350
原创 学习日报 20250929｜缓存击穿及其解决方案
缓存击穿是热点key失效时大量请求穿透到数据库的问题。解决方案包括：1)分布式锁控制单线程查询DB；2)热点数据永不过期+异步更新；3)熔断降级返回默认值。分布式锁适合高并发场景但性能有损耗，永不过期方案适合实时性要求低的数据，熔断降级则用于非核心流程。实践中可组合使用这些方案，如分布式锁+随机过期时间，兼顾防击穿和防雪崩。
2025-09-29 22:50:25
354
原创 学习日报 20250928｜Java日志规范：从基础规约到高级实践（含SkyWalking整合）
本文系统阐述了日志规范的核心要点与实践方案。在基础层面，强调统一使用SLF4J、合理分级日志级别、避免字符串拼接等关键规约，确保日志可用性与安全性。高级实践中，详细介绍了Trace级别日志的合理使用、多线程场景下的MDC上下文传递方案，以及自动化线程池封装技巧。最后，通过整合SkyWalking框架，实现日志与全链路追踪的无缝对接，自动关联TraceID，显著提升问题排查效率。整套方案兼顾规范性与实用性，既避免了日志泛滥风险，又能有效支撑系统监控与故障定位需求。
2025-09-28 23:42:34
729
原创 学习日报 20250928｜React 中实现 “实时检测”：useEffect 依赖项触发机制详解
用useEffect实现 “实时检测”，本质是遵循 “依赖项变化 → 方法重复执行定义目标状态：明确需要检测的值（如输入框内容inputValue、表单字段usernamepassword编写检测逻辑：在useEffect内部封装检测方法（同步校验、异步请求均可）；配置依赖项：将目标状态放入依赖项数组，让值变化时自动触发检测。掌握这一范式后，无论是简单的输入校验，还是复杂的多值联合检测、异步接口校验，都能高效落地，同时通过防抖、清理副作用、异常处理等优化，保障检测逻辑的性能与稳定性。
2025-09-28 23:27:57
881
原创 学习日报 20250928｜Java 异常处理：从理论到工作实践的全面指南
【摘要】本文系统梳理Java异常处理的核心方法论，重点解析Checked与Unchecked异常的本质区别及处理策略。强调绝不"吞异常"的原则，提出Checked异常必须捕获或抛出，Unchecked异常优先通过逻辑校验规避。文章结合实践场景，给出资源释放、日志记录、异常传递等进阶技巧，并推荐通过自定义异常和错误码体系提升业务可维护性。最后提炼出异常处理的"黄金法则"，指导开发者将异常转化为问题排查的助手，而非系统隐患。
2025-09-28 23:17:40
580
原创 学习日报 20250923｜MQ (Kafka)面试深度复盘
本文深入解析分布式系统中消息队列（MQ）的技术要点与面试重点。从实际应用场景剖析MQ的四大核心价值：异步通信、流量削峰、系统解耦和数据存储，并结合电商、秒杀等典型案例说明其业务价值。全面对比主流MQ产品特性，包括Kafka、RabbitMQ等开源方案和Solace等商业产品，提供选型方法论。重点分析消息积压、丢失、重复等生产问题的解决方案，强调消费端幂等性设计和有序性保障策略。最后以Kafka为原型，拆解MQ的架构设计要点，包括分区副本机制、高可用保障等核心设计思想，为技术选型和系统设计提供参考。
2025-09-23 23:30:25
834
原创 学习日报 20250923｜LoadingCache
摘要：Google Guava的LoadingCache接口提供自动缓存加载功能，适用于高并发读多写少场景。它通过CacheBuilder构建，当缓存未命中时自动调用加载函数，显著提升热点数据访问性能（响应时间可降低80%以上），减少数据库压力（请求量降低50-80%）。典型应用包括电商商品详情、新闻资讯等静态或低频更新数据，通过内存缓存优化系统性能，适合Java开发者在各类互联网和企业应用中实施。使用需引入Guava依赖并配置缓存加载策略。
2025-09-22 21:29:41
993
原创 学习日报 20250921｜NIO
NIO是Java提供的新I/O API，相比传统BIO具有非阻塞、基于缓冲区和多路复用的特点。核心组件包括Channel、Buffer和Selector，通过示例展示了NIO服务端和客户端的实现方式。服务端使用Selector监听多个通道事件，实现非阻塞通信；客户端通过Channel发送和接收数据。NIO适合高并发场景，是Netty等框架的基础。其优势在于单线程管理多连接，避免了传统BIO的线程资源浪费问题。
2025-09-21 23:19:43
403
原创 学习日报｜线程池 OOM
线程池任务堆积导致OOM的解决方案摘要 核心问题：任务到达速率远超处理能力时，队列堆积引发内存溢出。常见场景包括突发流量、消费阻塞、内存泄漏和隐式线程池。 解决方案： 线程池有界化：设置合理队列容量（maxPool×2~5） 组合策略： 拒绝策略快速失败+告警 入口限流+MQ削峰 超时熔断机制 非关键路径降级 参数建议：core≈CPU核数×(1+阻塞系数)，max=core×2~4 监控体系：线程池活跃数/队列/拒绝数+RT+JVM指标 关键原则：通过有界化、限流、熔断等多重手段，将不确定性控制在系统可承
2025-09-18 21:53:33
360
原创 学习日报｜Spring 全局异常与自定义异常拦截器执行顺序问题及解决
本文分析了Spring Web应用中全局异常拦截器与自定义异常拦截器的执行顺序问题。默认情况下，Spring基于类名ASCII码排序，导致全局拦截器优先执行，与期望的"地方法优先"逻辑不符。文章提出通过改造排序逻辑，优先执行带有包范围限制的拦截器（@ControllerAdvice(basePackages=...)），使精准拦截器优先处理，全局拦截器作为兜底，从而构建更合理的异常处理机制。这种"精准优先+全局兜底"的方案既保证了系统健壮性，又提供了处理灵活性。
2025-09-17 22:50:42
370
原创 学习日报｜梳理三类典型缓存问题：缓存穿透、缓存击穿、缓存雪崩
摘要：本文系统分析了缓存穿透、击穿和雪崩三种典型问题。穿透指请求不存在的数据导致直击数据库，可通过布隆过滤器、空值缓存解决；击穿是热点key失效引发的并发回源，采用互斥锁、逻辑过期等方式防护；雪崩源于大量key同时失效，需TTL随机抖动和多级缓存应对。文章提供了问题特征、治理方案、代码示例和监控指标，并给出不同场景的选型建议，形成了一套完整的缓存问题防护体系。
2025-09-15 23:06:08
875
原创 学习日报｜线程池专题学习总结
线程池是复用线程的容器，通过预先创建线程降低创建/销毁成本。核心参数包括线程数、队列、拒绝策略等。执行流程遵循"核心→队列→扩容→拒绝"四步，状态包含RUNNING至TERMINATED。关键优化点：使用有界队列、合理配置线程数、设置任务超时、监控活跃线程/拒绝数。常见OOM场景包括无界队列堆积、任务泄漏等。最佳实践为：有界队列+显式拒绝+分池隔离+监控告警。注意避免无界队列和无超时调用，通过限流、降级等机制保障系统稳定。
2025-09-14 22:54:56
927
原创 学习日报｜线程池 OOM 案例与优化思路
文章摘要： 线程池使用不当易引发OOM，主要风险场景包括突发流量导致队列堆积、任务执行阻塞、内存泄漏及框架隐式线程池。核心问题在于任务生产速度超过消费能力且缺乏约束。解决方案包括：采用有界队列+合理拒绝策略、接口限流、任务超时控制、实时监控队列及内存指标。优化心法可总结为"限产、有限、超时、可监控"四原则，通过流量管控和资源约束预防潜在风险。
2025-09-14 22:48:08
369
原创 01-手写线程池与模拟OOM
本文介绍了线程池的核心参数及实现原理。线程池主要包含corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）和handler（拒绝策略）等关键参数。通过一个手写线程池示例，详细演示了这些参数的工作机制：当任务数≤corePoolSize时创建核心线程；核心线程满后任务进入队列；队列满后创建非核心线程；所有资源满后触发拒绝策略。代码还展示了非核心线程的超时销毁机制。该实现完整模拟了线程池的创建、任务调度
2025-09-14 20:36:09
225
原创 线程池核心参数 — 5W1H1S 解析
线程池核心参数5W1H1S解析摘要（150字） 线程池核心参数包括corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）、threadFactory（线程工厂）和handler（拒绝策略）。其作用在于限制资源、提升性能、应对高峰和容错兜底。参数在任务提交、队列满载或线程空闲时动态生效，适用于高并发服务端场景。配置需结合业务类型：CPU密集型任务推荐核心线程数为CPU数+1，IO密集型为2倍CPU数；
2025-09-13 16:39:56
529
原创 随笔20250721 PostgreSQL实体类生成器
摘要：本文介绍了三层架构中异常处理的最佳实践，建议try-catch放在ViewModel层，Service层仅使用业务异常。同时讨论了DbHelper的单例模式实现及批量插入优化方案，强调异步调用链必须从DAO层贯穿到ViewModel层。最后提供了一个PostgreSQL实体类生成工具的实现，通过解析数据库元数据自动生成C#实体类，支持表名转换、数据类型映射和特性标注。工具采用Npgsql连接PostgreSQL，可自动处理表结构、字段类型、主键等元信息，生成符合规范的实体类代码。
2025-07-21 23:00:46
358
原创 隨筆20250519 Async+ThreadPoolTaskExecutor⾃定义线程池进阶实战
1.核心綫程數 查看核心綫程數目是否已經滿，未滿 創建一條綫程 執行任務，已滿負責執行第二部2.阻塞隊列 查看阻塞隊列是否已經滿，未滿將任務加入阻塞隊列， 已滿執行第三步3.綫程池 是否已經達到綫程池數，未滿，常見一條綫程執行任務，已滿 根據策略處理無法執行的任務。关键在于观察程序的瓶颈在哪里：是等待IO操作（例如网络请求、磁盘读写）的时间长，还是CPU计算的时间长。 IO 网络请求: 访问数据库、远程服务器等。 磁盘读写: 读取文件、写入日志等。 用户输入/输出: 等待用户输
2025-05-19 17:01:59
238
原创 随笔 20250413 Elasticsearch 的 term 查询
你的目的推荐查询方式查 "包含 world"✅match查询精确查 "World"（大小写）✅term.keyword（非分词字段）查部分词、模糊匹配✅match需要我帮你分析你 index 的 mapping 吗？你可以贴一下的结构，我可以告诉你字段类型是否支持.keyword，从根上解决 💡。
2025-04-13 22:52:52
544
原创 20250319 工作随笔 水晶报表的修改(.rpx)
Label和TextBox：用于静态文本和动态数据。Line和Shape：用于分割和装饰。Picture：用于插入图片。ReportInfo：用于显示页码、总页数和打印时间等报表信息。使用可以灵活定制ReportInfo的显示格式。
2025-03-19 09:25:51
1092
原创 20250307隨筆 使用 A5 SQL 打开 .a5er 文件以及生成建表語句
文件后，你可以查询某个表的名称以及生成数据表的 SQL 脚本。你可以用这个 SQL 在数据库中创建相同的表。如果你想获取某张表的。
2025-03-07 14:50:12
1025
原创 20250305随笔 HTML2Canvas 详解与使用指南
是一个用于将 HTML 页面或特定 DOM 元素转换为 Canvas 画布的 JavaScript 库。它通过解析 HTML 和 CSS，生成等效的 Canvas 图像，从而实现网页截图功能。
2025-03-05 21:42:02
1232
原创 20250226 工作隨筆 C#文件拷貝
並根據不同條件進行校驗與回滾。，並根據不同條件進行校驗與回滾。方面都有了明顯提升 🎯。方面都有了明顯提升 🎯。，表示操作是否成功。，表示操作是否成功。
2025-02-26 16:34:57
1105
原创 20250219 隨筆 [特殊字符] 查看短鏈的實現方式與解決方案優化
透過MQ（消息隊列）配合冗餘雙寫策略來解決分庫分表帶來的解析問題，並確保數據在多庫之間的最終一致性。為減少查詢複雜性並提升查詢效率，將數據按照業務角色分為賣家庫與買家庫。買家庫：賣家庫：目的：確保買家庫與賣家庫之間數據同步，支持多角度高效查詢。具體方案：在分庫分表與冗餘雙寫的場景下，分佈式事務是關鍵問題，尤其是確保數據在多庫間的一致性。問題：解決方案： ✅ 使用 MQ 實現最終一致性優勢：在 分庫分表架構 下，WebRelease 搭配 MQ + 冗餘雙寫 的策略，不僅能解決短鏈解析的庫表定位問題，同時通
2025-02-19 14:46:08
576
原创 20250219 隨筆 [特殊字符] 使用 Sharding-JDBC 時未配置分片規則的表如何通過默認數據源定位？
Sharding-JDBC 是一款來自 Apache ShardingSphere 的分布式數據庫中間件，主要用於支持 分庫分表、分布式事務 和 數據庫治理，且對應用層無侵入。在使用 Sharding-JDBC 時，通常需要為需要分庫分表的表進行分片規則（Sharding Rule）配置。但並不是所有表都需要分片，有些表（如參數表、字典表等）本身數據量較小或不適合分片。當 Sharding-JDBC 檢測到某個表在配置中未定義分片規則時，系統會自動將該表映射到配置文件中聲明的默認數據源。💡 解釋：
2025-02-19 14:36:52
773
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人