服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

SpringBoot + SpringCloud Gateway + Sentinel + Redis：API 网关层的接口限流、黑名单拦截与用户认证 今天和大家分享一个我们在生产环境中稳定运行的API网关解决方案——基于SpringBoot + SpringCloud Gateway + Sentinel + Redis的组合，实现接口限流、黑名单拦截和用户认证三大核心功能。 一、为什么需要API网关层的安全控制？ 在微服务架构盛行的今天，我们的系统被拆分成数十甚至上百个独立的服务。如果没有一个统一的入口来管理这些服务的访问，将会面临以下风险： 恶意请求泛滥：攻击者可能通过大量无效请求消耗服务器资源 非法用户访问：未授权用户可能访问敏感接口 黑名单用户绕过：被封禁的用户可能通过不同IP或设备继续访问 系统雪崩风险：突发流量可能导致整个系统瘫痪 这就需要我们在API网关层建立一道坚固的防线。 二、整体架构设计思路 我们的解决方案采用了四层防护体系： 客户端请求 → SpringCloud Gateway → Sentinel限流 → 黑名单拦截 → JWT认证 → 目标服务 每一.......

Kafka消息丢失的3种场景，生产环境千万要注意！老司机带你避坑 明明发送了重要消息，但消费者就是收不到？或者消息处理了一半，突然就消失了？这些问题很可能就是Kafka消息丢失造成的！今天就来聊聊Kafka消息丢失的3种典型场景，以及如何在生产环境中完美避免这些坑！ 一、Kafka消息丢失的根源分析 在深入讨论具体场景之前，我们先来了解一下Kafka的消息流转过程和可能导致消息丢失的关键环节。 1.1 Kafka消息流转过程 // Kafka消息流转过程简述 public class KafkaMessageFlow { public void flow() { System.out.println("=== Kafka消息流转过程 ==="); System.out.println("1. Producer发送消息到Broker"); System.out.println("2. Broker将消息写入磁盘并确认"); System.out.println("3. Consumer从Broker拉取消息"); System.out.println("4. Consumer处理消息并提....

别再用哈希碰撞了！百亿级短URL的正确打开方式 大家好，我是老司机。今天咱们来聊一个看似简单，实则藏着大学问的系统——短URL生成器。 你可能觉得：不就是把长链接变成短链接吗？有啥难的？但如果我说，要支撑每天10亿次点击，生成百亿级不重复的短URL，还要保证系统高可用、低延迟，这里面的技术挑战可就大了去了。 今天我就把短URL生成器的设计秘诀拆解给你看，从原理到实战，保证通俗易懂，就算是刚入行的同学也能get到核心要点。 一、先搞懂：短URL生成器的核心矛盾 短URL生成器的本质，是把一个可能很长的URL（比如https://www.example.com/path/to/a/very/long/article?param1=value1&param2=value2）转换成一个短字符串（比如https://t.cn/abc123）。 这里面有两个核心矛盾： 唯一性：必须确保每个长URL对应唯一的短URL，反之亦然 长度：短URL必须足够短（通常6-8个字符），但字符集有限（数字+大小写字母也就62个字符） 尤其是在百亿级规模下，如何保证短URL不冲突，成为了系统设计的关....

MQ消息堆积到系统崩溃？这5个排查技巧让你10秒定位问题！ 作为一名后端开发，经历过太多因为MQ消息堆积导致的"血案"： 某电商大促期间，订单消息堆积了500万条，用户下单后2小时还没收到确认短信，客服电话被打爆 某支付系统因为消息堆积，导致用户支付成功但订单状态一直未更新，老板差点把我祭天 某社交平台的消息通知系统，堆积了1000万条消息，用户私信延迟了整整一天才收到 消息堆积，可以说是分布式系统中最让人闻风丧胆的问题之一。今天就结合自己踩过的坑，跟大家聊聊如何快速排查和解决MQ消息堆积问题，让你的系统稳如老狗。 一、消息堆积到底是个啥？为啥这么可怕？ 简单来说，消息堆积就是生产者发送消息的速度远大于消费者处理消息的速度，导致消息在队列中越积越多。 堆积的恐怖后果： 内存暴涨：消息堆积会把MQ服务器的内存打满，最终导致OOM 磁盘爆满：持久化消息会把磁盘写满，影响整个服务器 系统雪崩：消息处理延迟越来越高，最终整个系统不可用 用户体验差：用户操作后迟迟得不到响应，直接投诉 二、消息堆积的3大元凶，你肯定遇到过 在讲排查技巧之前，我们先得搞清楚消息为什么会堆积。根据我多年的踩坑....

50万QPS未读消息系统设计：从崩溃到丝滑的实战之路 大家好，今天想跟大家聊一个看似简单，实则能让整个系统崩溃的问题——如何设计一个能扛住50万QPS的站内未读消息系统。 为什么说它重要？想想看，现在哪个App没有消息通知？用户登录后看到的小红点、未读数字，背后都是这个系统在支撑。如果设计不好，轻则消息延迟，重则整个服务雪崩。 一、未读消息系统的3大“坑王” 先别急着写代码，咱们得先搞清楚这个系统的核心挑战。我见过太多团队一开始觉得“不就是存个数字吗”，最后被现实狠狠教育。 1. 高并发读写：秒杀级别的写入压力 用户的每一次点击、每一条新消息，都会触发未读消息的更新。在大用户量的平台，这就是持续不断的秒杀场景。 比如某电商平台，大促期间每秒新增消息量能达到50万条。如果直接写数据库，分分钟把MySQL打趴下。 2. 数据一致性：不能多也不能少 未读消息的数字必须绝对准确。多了，用户会疑惑；少了，用户会错过重要信息。 我之前遇到过一个坑：用户明明读了消息，但未读数字没减。一查才发现，是缓存更新不及时，导致脏数据。 3. 实时性要求：用户盯着小红点呢 用户对未读消息的实时性要求极高。你想想....

线程池调优秘籍：核心线程数与队列大小的黄金比例，90%的人都不知道！ 公众号：服务端技术精选 嗨，各位后端大佬们！今天咱们来聊个面试常考、工作常用，但一不小心就踩坑的话题——线程池的参数优化。 你是不是也遇到过这种情况：系统平时跑得好好的，一到高峰期就卡成PPT？或者明明CPU利用率不高，任务却堆积如山？别怀疑，可能就是线程池的核心线程数和队列大小没配好！ 一、线程池是个啥？用餐厅来打个比方 咱们把线程池比作一家餐厅： 核心线程数 = 固定在岗的服务员（不管有没有顾客都在店里待命） 队列大小 = 等候区的座位（顾客太多时，先在这儿排队等着） 最大线程数 = 店里能容纳的最多服务员（固定服务员不够时，临时叫兼职） 如果配置不合理会咋样？ 服务员太少（核心线程数不足），顾客（任务）就得在等候区排长队 等候区太大（队列容量太大），顾客等太久可能直接走人（任务超时） 二、核心线程数怎么设？记住这两个公式 1. CPU密集型任务（比如大数据计算） 公式：核心线程数 = CPU核心数 + 1 举个栗子：4核CPU就设5个核心线程 为啥？因为CPU密集型任务主要吃计算资源，线程多了反而会导....

MySQL面试必问：存储用户密码，char还是varchar？答案出乎意料！ 作为一名资深后端开发，你有没有遇到过这样的场景：面试官微笑着问你："在MySQL中存储用户密码，应该用char还是varchar？"你心里想："这不就是个简单的数据类型选择问题吗？"但当你给出答案后，面试官却意味深长地说："你确定吗？" 今天就来聊聊这个看似简单却暗藏玄机的面试题，答案可能真的会出乎你的意料！ 一、看似简单的问题，实则暗藏玄机 在开始深入讨论之前，我们先来看看这个问题的背景。在实际开发中，存储用户密码是一个非常常见的需求，但如何选择合适的数据类型却让很多人犯难。 1.1 为什么会有这个问题？ 这个问题之所以成为面试官的"杀手锏"，主要有以下几个原因： 表面简单：看起来只是数据类型的选择，实际上涉及存储引擎、性能优化、安全性等多个方面 陷阱众多：不同的选择会带来不同的性能表现和存储效果 实际影响：错误的选择可能影响系统性能和存储效率 1.2 常见的错误答案 在面试中，很多人会给出以下答案： "用varchar，因为密码长度不固定" "用char，因为性能更好" "用varchar(255).......

Vue预览Excel文件的完整指南：从零开始实现 大家好，我是你们的前端老司机。今天我们来聊聊一个让无数前端开发者头疼的问题——Vue中如何预览Excel文件。 你是否也遇到过这些场景： 产品经理说："用户上传Excel文件后，要在页面上直接预览，不要下载" 用户抱怨："我上传的Excel文件怎么看不到内容？" 后端同事问："前端能不能直接展示Excel，我返回二进制流就行" 老板质疑："为什么别人家的系统能预览Excel，我们的不行？" 别急，今天我就把这套Vue预览Excel文件的完整实现方案全掏出来，手把手教你从零开始实现Excel文件预览功能！ 为什么Excel预览这么难搞？ 在开始正题之前，先聊聊为什么Excel预览这么复杂： 格式多样：.xls、.xlsx、.csv等多种格式 功能复杂：合并单元格、公式计算、样式渲染 兼容性差：不同版本的Excel文件格式差异大 性能要求高：大文件预览不能卡顿 浏览器限制：原生不支持Excel格式解析 实现方案对比 方案一：使用第三方库（推荐） 优点： 功能强大，支持多种Excel特性 社区活跃，文档完善 开箱即用，开发效率高 ....

5亿用户网约车系统又双叒叕崩了？这5个架构绝招让你秒变滴滴！ 大家好，今天来聊个能让所有后端程序员做噩梦的话题——如何设计一个支持5亿用户规模的网约车系统。 想象一下这个场景：周五晚高峰，北京突然下暴雨，几千万用户同时疯狂叫车。你的网约车系统如果扛不住，司机接不到单，乘客打不到车，整个城市交通瘫痪，你就等着上新闻头条吧... 别慌！作为一个曾经把网约车系统搞到日订单千万级的老司机，今天就把这套从0到5亿用户的网约车架构的压箱底绝活掏出来！ 一、网约车系统的5个地狱级难题 1. 实时位置计算 - 几百万司机在移动 每秒钟几百万司机位置更新，如何快速找到最近的司机？ 2. 供需匹配算法 - 1秒内完成最佳匹配 从几万个司机中找到最合适的那个，考虑距离、方向、车型、评分... 3. 动态定价 - 实时调整价格 雨天涨价、高峰期涨价，如何实时计算？涨多了用户跑，涨少了司机不干。 4. 分布式事务 - 一个订单跨越十几个系统 下单、支付、派单、计费、结算...任何环节出错都是灾难。 5. 海量数据存储 - 每天TB级数据 订单、轨迹、用户行为...怎么存？怎么查？ 二、5个架构绝招让网约车稳如老....

SpringBoot + Seata + Nacos：分布式事务落地实战，订单-库存一致性全解析 你是否曾在面对复杂的微服务架构时，为数据一致性问题而头疼不已？特别是在订单系统和库存系统分离的情况下，如何保证订单创建和库存扣减的原子性？今天我们就来深入探讨如何使用SpringBoot + Seata + Nacos这套黄金组合，完美解决分布式事务的一致性问题，让你的系统在高并发场景下依然保持数据的绝对一致！ 一、分布式事务的痛点 在传统的单体应用中，我们可以通过数据库事务轻松保证数据的一致性。但在微服务架构下，业务被拆分成多个独立的服务，每个服务都有自己的数据库。以电商场景为例： 用户下单（订单服务） 扣减库存（库存服务） 这两个操作必须同时成功或同时失败，否则就会出现数据不一致的情况。 二、Seata是什么？ Seata是阿里巴巴开源的一款分布式事务解决方案，提供了高性能和简单易用的分布式事务服务。它支持AT、TCC、Saga和XA事务模式，其中AT模式对业务代码侵入最小。 三、项目架构设计 我们的示例项目包含以下模块： order-service（订单服务） inventor.......