jakeswang的博客

本文深入探讨了缓存技术的核心原理与应用实践。从缓存基础概念到多级架构设计，详细解析了命中率、回收策略等关键指标，对比了Guava、Ehcache等主流框架特性。通过Cache-Aside、Read-Through等典型模式分析，结合NULL缓存、双删策略等高级技巧，提供了完整的缓存解决方案。文章还针对穿透、击穿、雪崩三大问题给出防护措施，并探讨了堆外缓存等性能优化方案，为构建高性能系统提供了实用指南。最后强调需根据业务场景选择合适策略，实现缓存效果最大化。

Kafka凭借分布式架构和极致优化实现亿级并发：1）分区化设计实现并行读写，集群动态扩容；2）顺序I/O+零拷贝技术突破磁盘瓶颈，吞吐接近内存速度；3）批处理与压缩提升有效传输效率；4）副本机制保障高可用。核心通过分区并行、高效I/O、批处理压缩三大技术协同，配合合理配置与硬件资源（SSD/大内存/高速网络），实现超高性能。其设计精髓在于将分布式架构优势与单机性能压榨完美结合。

举个例子，我入职的第一个月，就经历了一次比较严重的线上故障：当时另一个业务组突然上线了一个新功能，里面包含了大量的Redis大Key操作，导致我们共享的Redis集群响应变得非常慢，最终拖垮了我们的核心服务，造成了长时间的业务中断。最佳的面试策略，就是在自我介绍时就主动抛出引子，例如提到自己在“高可用微服务架构”方面的丰富经验，然后在介绍项目时，着重展示你在入职后，是如何大幅度提高了系统的可用性。当然，这里给出的整个话术和方案，是一个“框架”，面试的时候你需要根据你的实际项目经验，来填充血肉。

决策维度说明推荐实践任务紧迫度是否允许任务被延迟执行紧迫性任务建议使用专属线程池，非紧迫任务可使用共享线程池- 紧迫性任务对响应时间敏感，必须尽快执行如接口响应、同步业务主流程- 非紧迫性任务对时效要求不高，只需最终完成如日志上报、异步通知结果敏感度是否需要获取任务执行结果区分（敏感）与execute（不敏感）- 结果敏感性任务提交后需获取结果，结果影响主流程需精细化控制线程资源，防止结果超时- 结果不敏感任务只需执行，不关心结果可交由复用线程池或后台异步处理。

摘要：本文探讨了高并发场景下多级缓存架构的解决方案。以咖啡新品发布为例，分析了传统架构面临的瞬时高并发、热点数据集中和缓存失效风暴等痛点，提出本地缓存+Redis的多级缓存体系。详细介绍了Caffeine本地缓存配置、Redis集群优化、缓存穿透/击穿/雪崩防护策略，以及监控降级方案。实施效果显示，该架构将数据库请求削减99%以上，响应时间从秒级降至毫秒级，系统吞吐提升显著。关键成功要素包括精细缓存策略、充分预热和全面监控，未来可向智能预测、边缘计算等方向演进。

摘要：某电商平台在大促期间因网关限流导致订单服务异常，虽然CPU和内存使用率正常，但接口响应时间骤增。排查步骤包括：1）检查线程栈状态，识别阻塞/等待线程；2）分析依赖服务性能（数据库慢查询、下游RT）；3）监控JVM垃圾回收情况；4）诊断网络与连接池问题；5）分析日志链中的超时和重试记录。常见根因包括数据库锁竞争、连接池耗尽或GC频繁。建议采用线程池隔离、降级策略和全链路压测预防类似问题。

摘要：CPU飙升100%是Java应用中常见问题，可通过jstack和arthas工具快速定位。解决步骤：1）使用top命令找到高CPU进程；2）用jstack获取线程堆栈，将线程ID转换为16进制后匹配定位问题代码；3）分析RUNNABLE状态的线程调用栈，常见死循环、锁竞争等问题。arthas提供dashboard和thread命令简化排查。案例表明，死循环问题通常显示固定代码位置，锁竞争则呈现多线程BLOCKED状态。建议保存堆栈快照优先于重启，并建立监控预警机制。该方法能在15分钟内解决90%的CP

SQL语句中锁的使用与优化

摘要：Java后端开发中，单人维护代码量和月提交行数因经验级别而异：初级工程师（1-5年）维护5-15万行，月提交2000-3000行；高级（5-10年）维护20-50万行，提交1500-2500行；资深（10年+）维护50万+行，提交500-1500行，常通过删除冗余代码实现负增长。关键影响因素包括代码质量、项目阶段和团队规范。行业趋势强调避免唯行数论，建议采用删除冗余、统一规范、自动化工具等提升维护效率。核心原则是代码价值在于解决实际问题的效率而非数量。

幂等性处理：重试仅适用于GET/PUT等幂等操作，非幂等操作(POST)需谨慎重试策略基础场景：RestTemplate +@Retryable微服务间调用：OpenFeign + 自定义Retryer生产环境：Resilience4j + 熔断降级关键参数最大重试次数：通常3-5次退避策略：指数退避（如：首次500ms，第二次1000ms）超时设置：比重试间隔短监控：集成Micrometer + Prometheus监控重试指标异常处理。

在需要精确的小数计算时再使用BigDecimal，BigDecimal的性能比double和float差，在处理庞大，复杂的运算时尤为明显。故一般精度的计算没必要使用BigDecimal。尽量使用参数类型为String的构造函数。BigDecimal都是不可变的（immutable）的， 在进行每一次四则运算时，都会产生一个新的对象 ，所以在做加减乘除运算时要记得要保存操作后的值。构造方式优先使用String构造或比较操作始终使用而非equals()除法运算必须指定精度和舍入模式（精度控制。

Java 中实现 Excel 导入一些疑难杂症，Excel导入导出字段无法映射问题相关

在当今微服务架构盛行的时代，分布式系统已经成为企业级应用的标准模式。然而，随之而来的分布式事务问题也成为了开发人员的一大挑战。在复杂的供应链系统中，各个业务模块之间的数据一致性一直是一个重要且棘手的问题。物流、库存、订单等系统相互协作，如何在保证业务高效运转的同时，确保跨系统操作的数据一致性？今天，我们将深入探讨一个专为解决供应链分布式事务问题而设计的框架——「一致性框架」。二在分布式系统中，一致性框架是确保系统可靠性的重要工具。

代码层面避免大事务，拆分业务逻辑设置合理的事务超时移除事务中的远程调用配置层面优化连接池参数设置合理的连接泄露检测运维层面建立实时监控告警定期进行压力测试实施事务治理策略架构层面引入熔断降级机制采用异步处理模式实现最终一致性方案通过以上综合措施，可有效预防和解决大事务导致的数据库连接池耗尽问题，保障系统稳定运行。

数据库是否会因删除操作卡死，，而是受等多种因素影响。WHERE小表（<10 万条，有索引）5000-10000 条内存可缓存数据，索引加速查询，分批提交即可。中等表（100 万 - 500 万条）1000-5000 条需搭配索引 + 小事务（如每 1000 条提交一次），避免锁持有过久。大表（>1000 万条，HDD）500-1000 条机械硬盘 IO 受限，建议每次删除不超过 1000 条，配合 1 秒以上休眠。超大表（>1 亿条，无分区）100-500 条。

入口生成：在请求入口（Filter/Interceptor）生成 traceId全链路传递HTTP：通过 Header 传递（X-Trace-IdRPC：通过调用附件传递MQ：通过消息头传递存储位置同步请求：使用MDC异步线程：使用日志集成：在日志模板中添加异常处理：确保在 finally 块中清理上下文ID 生成规则// 示例：服务前缀 + 时间戳 + 随机数。

StarRocks 凭借其高性能、实时性和易用性，成为国内分析型数据库领域的重要选择，尤其适合需要兼顾实时数据处理和复杂查询的企业级场景。，专注于解决大规模数据分析和实时查询场景的需求。它基于 MPP（大规模并行处理）架构设计，具备高并发、低延迟、易扩展等特点，被广泛应用于数据分析、实时报表、用户行为分析、日志分析、金融风控等领域。强（原生支持星型 / 雪花模型）较强（支持宽表和部分关联）MPP + 向量化执行。MPP + 向量化执行。较好（需批量写入优化）兼容 MySQL 协议。兼容 MySQL 协议。

不同的群聊产品，采用的技术方案是不同的，为了理解接下来的技术选型，需要先了解下这群聊产品的特性。单群成员需要支撑百万人，同时在线百万级。功能、体验要接近纯客户端实现方案。用户端完全用H5承载。在本文中，笔者介绍了从零开始搭建一个生产级百万级群聊的一些关键要点和实践经验，包括通信方案选型、消息存储、消息顺序、消息可靠性、高并发等方面，但仍有许多技术设计未涉及，比如冷热群、高低消息通道会放在未来的规划里。

XSS全称为Cross Site Script，即跨站点脚本攻击，一般攻击者通过篡改网页 注入恶意HTML脚本，在用户浏览网页时就能执行恶意的操作，像html、css、img都有可能被攻击。

相同的明文数据经过相同的消息摘要算法会得到相同的密文结果值。数据经过消息摘要算法处理，得到的摘要结果值，是无法还原为处理前的数据的。数据摘要算法也被称为哈希（Hash）算法或散列算法。消息摘要算法一般用于签名验签。消息摘要算法主要分三类：MD（Message Digest，消息摘要算法）、SHA（Secure Hash Algorithm，安全散列算法）和MAC（Message Authentication Code，消息认证码算法）。

数据迁移与架构演进是系统升级的核心挑战，二者必须协同设计。实现新架构落地保障业务连续性新架构的技术栈、数据模型存量数据结构、数据量、一致性要求数据库选型、服务拆分策略迁移窗口期、数据校验机制新系统无法正常运行业务数据丢失/错乱共享数据库解耦按领域拆分数据库定义服务边界（Bounded Context）跨服务数据一致性采用Saga分布式事务事件驱动架构设计历史数据归属划分数据所有权映射表+数据路由中间件服务发现机制扩展load data📌。

需求介绍主要描述需求的背景、目标、范围等性能问题：当用户发布了一条微博后，微博发布子系统需要同步调用“统计子系统”“审核子系统”“奖励子系统”等共 8 个子系统，性能很低。耦合问题：当新增一个子系统时，例如如果要增加“广告子系统”，那么广告子系统需要开发新的接口给微博发布子系统调用。效率问题：每个子系统提供的接口参数和实现都有一些细微的差别，导致每次都需要重新设计接口和联调接口，开发团队和测试团队花费了许多重复工作量。基于以上背景，我们需要引入消息队列进行系统解耦，将目前的同步调用改为异步通知。

为什么画 > 画什么 > 怎么画 > 用什么画。永远从目的和受众出发。分层抽象是核心武器。用多张图从不同视角描述系统。一致性是清晰度的保障。符号、颜色、标注要规范统一。简洁明了胜过面面俱到。突出主干，合理省略。架构图是活的文档。及时更新，纳入版本管理。工具服务于目的。draw.io和Mermaid是强大且免费的起点。好的架构图像一份精准的地图：它能引导开发者穿越复杂系统的迷宫，让运维预见瓶颈所在，帮新人快速把握全局。开始动手吧，先明确目标，然后从最顶层的Context图开始，逐层深入。记得，

以上步骤展示了如何在Spring Boot中实现Excel文件的上传和解析。通过使用Spring的文件上传功能和Apache POI库，你可以轻松处理Excel文件，并将其内容解析成所需的数据结构。根据实际需求，你可以进一步扩展和优化这个示例。controller层代码事例：/*** 上传资源excel文件并进行解析* @return*/returnMap.put("message", "对不起，您设置的供应商无效！");

本文介绍了在Spring Boot中实现服务器发送事件(SSE)的三种方法：1)使用@RestController返回SseEmitter对象；2)原生Servlet异步处理；3)集中式管理多个客户端连接。核心要点包括遵循SSE数据格式规范（以data:开头，\n\n结尾）、异步处理机制、超时与重连控制。文章对比了SSE与WebSocket的特性差异，建议SSE适用于服务端单向推送场景，并提供了客户端监听示例、跨域配置方案以及性能优化建议。最后针对常见问题给出排查方向，如数据格式验证、连接稳定性处理和高并发

本文介绍了三种实现实时通信的技术：SSE（服务器推送事件）、WebSocket和长轮询。SSE适用于单向数据流场景（如股票行情、新闻推送），基于HTTP协议实现简单。WebSocket支持双向通信（如聊天应用），但实现较复杂。长轮询作为传统过渡方案，兼容性好但效率低下。文章通过具体场景对比了三种技术的优缺点：SSE轻量高效但仅支持单向；WebSocket功能全面但复杂度高；长轮询简单兼容但资源消耗大。最后针对股票交易、即时聊天等典型场景给出了技术选型建议，并特别总结了SSE在各种单向实时推送场景中的优势与应

本文详细介绍了Redisson在Spring Boot项目中的整合与使用方案。主要内容包括：1) 通过pom.xml引入Redisson依赖；2) 配置Redisson客户端，支持单节点、哨兵和集群模式；3) 分布式锁的实现与高级特性（自动续期、公平锁、联锁）；4) 异常处理与最佳实践；5) 高可用配置方案；6) 监控与调试方法。同时提供了完整的参数解释和性能优化建议，包括连接池配置、重试机制和订阅设置等，帮助开发者根据业务需求合理调整配置参数。通过订单处理服务示例，展示了分布式锁在实际业务中的应用场景。

查看基于时间序列的监控项的报表，是理解某个系统组件工作情况的好办法，可 以通过几个图表的相关性来初步进行问题根源的判定。这里的日志是广义的，它包括监控系统背后的各类观 测指标的时序数据，以及应用程序的程序日志。通过对关键服务进行定期的故障演练，我们可以在真正的业务故障发生之前识别潜在的弱点和风险点，并制定相应的应对措施。从理论上讲，将故障排查过程定义为反复采用假设 - 验证排除手段的过程：针对某系统的一些观察结果和对该系统运行机制的理论认知，不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除。

无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，依然能够保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是 12 小时。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。

通常，动态流控是分级别的，不同级别有不同的流控阈值，系统上线后会提供默认的流控阈值，不同留空因子的流控阈值不同，业务上线之后通常会根据现场的实际情况做阈值调优，因此流控阈值需要支持在线修改和动态生效。如果要保证当服务器宕机时不影响部署在上面运行的服务，需要采用分布式集群部署，而且要采用非亲和性安装:即服务实例需要部署到不同的物理机上，通常至少需要3台物理机，假如单台物理机的故障发生概率为0.1%，则3台同时发生故障的概率为0.001%，服务的可靠性将会达到 99.999%，完全可以满足大多数应用场景。

假如服务提供者出现故障，短时间内无法恢复时，无论是超时重试还是双发不但不能提高服务调用的成功率，反而会因为重试给服务提供者带来更大的压力，从而加剧故障。针对这种情况，就需要服务消费者能够探测到服务提供者发生故障，并短时间内停止请求，给服务提供者故障恢复的时间，待服务提供者恢复后，再继续请求。这就好比一条电路，电流负载过高的话，保险丝就会熔断，以防止火灾的发生，所以这种手段就被叫作“熔断”。简单来讲，熔断就是把客户端的每一次服务调用用断路器封装起来，通过断路器来监控每一次服务调用。

例如，最常见的数据库慢查询将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无法连接数据库、要么超时，最终用户看到的现象就是访问很慢，一会访问抛出异常，一会访问又是正常结果。假设这个请求的吞吐量为20qps，言下之意，很短的时间内，所有的100个工作线程都会被卡在这个第三方超时等待上，而其他N-1个原本没有问题的接口，也得不到工作线程处理。低优先级的服务通过启动不同的县城或者部署在不同的虚拟机进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。

在大多数情况下，这样的操作是经由一个外部系统来实现的，它会监控实例的健康，并在它们较长时间处于错误状态的情况下，重新启动应用程序。最常见的客户端滥发请求的行为，是配置更新间隔的设置问题。对于稳定性要求很好的关键系统，在成本可接受的情况下，同时维护一套保障主链路可用的备用系统和架构，在核心依赖服务出现问题能做一定时间周期的切换过渡（例如mysql故障，阶段性使用KV数据库等），例如钉钉IM消息核心系统就实现对数据库核心依赖实现一套一定周期的弱依赖备案，在核心依赖数据库故障后也能保障一段时间消息收发可用。

高可用的大前提：所有事物都不是100%可靠的从人的层面：人都是有可能犯错的。从软件层面：软件都是有可能有BUG的。从硬件层面：硬件都是有可能会坏的。不可抗力:地震，水灾，火灾FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等，专栏采用“故障模式与影响分析”，因为这个中文翻译更加符合可用性的语境。

负载均衡相关

系统是一个整体，如果只是节点级别的伸缩，可能要对多个节点分别进行操作，而且不同节点的资源配置会相互影响，这样对各个节点的调整就非常复杂，影响了系统 的可伸缩能力。系统处理请求不一定要实时同步，请求流量的高峰期时间往往很短，所以有些时候，可以延长系统的处理时间，只要在一个相对合理的时间内，系统能够处理完请求就可以了，这是一种异步化的处理方式。系统的可伸缩也有两种实现方式。：异步处理给系统的处理增加了弹性空间，可以利用更多的处理时间，来降低系统对资源 的实时需求，在保证系统处理能力的同时，降低系统的成本。

缓存提升性能的幅度，不只取决于存储介质的速度，还取决于缓存命中率。为了提高命中 率，缓存会基于时间、空间两个维度更新数据。在时间上可以采用 LRU、FIFO 等算法淘汰 数据，而在空间上则可以预读、合并连续的数据。如果只是简单地选择最流行的缓存管理 算法，就很容易忽略业务特性，从而导致缓存性能的下降。

(1)关系数据库存储的是行记录，无法存储数据结构以微博的关注关系为例，“我关注的人”是一个用户 ID 列表，使用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法直接存储一个列表。(2)关系数据库的 schema 扩展很不方便。

如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。单表行数超过1000万行或者单表容量超过4GB，才推荐分库分表。

读写分离：将访问压力分散到集群中的多个节点，没有分散存储压力分库分表：既可以分散访问压力，又可以分散存储压力。