- 博客(204)
- 收藏
- 关注
RSS订阅原创 分布式一致性算法
然后，领导者会通知其他节点该日志条目已提交，跟随者也会将已提交的日志条目应用到自己的状态机中。提案编号是一个全局唯一的、单调递增的数字。接受者收到准备请求后，如果提案编号大于它之前接受过的任何提案编号，它会承诺不再接受编号小于该提案编号的提案，并返回它之前接受过的最大编号的提案信息（如果有）。leader节点接收来自客户端的请求日志数据，然后同步到集群中其它节点进行复制，当日志已经同步到超过半数以上节点的时候，leader节点再通知集群中其它节点哪些日志已经被复制成功，可以提交到raft状态机中执行。
2025-07-30 16:36:28
1030
原创 [特殊字符]《动态分表路由实践：工具类 vs AOP 的权衡选择》
随着系统业务的发展，核心表的数据量不断膨胀，查询和写入性能逐步下降。为了支撑更多并发和更大的数据体量，我们在“XX”中对学生表、成绩表等关键业务表实施了水平分表策略。在做分表的过程中，我们遇到了一个选择题：👉路由逻辑是采用工具类封装，还是使用 AOP 自动拦截实现？最终我们选择了工具类方式，理由并非一言以蔽之，下面将详细展开分析和实践经验。在架构设计中，“没有银弹”，只有适合当前业务场景的选择。我们团队选择不用 AOP 的原因，不是它不好，而是：✅。
2025-07-30 11:24:00
839
原创 [特殊字符] Redis + Lua 实现令牌桶限流器实践经验分享
使用 Redis + Lua 实现的令牌桶限流器具备：✅ 高性能✅ 原子性操作✅ 跨服务共享限流状态✅ 易扩展、可观测性强。
2025-07-29 15:08:51
701
原创 Elastic-Job 分布式任务调度框架实践经验分享
Elastic-Job 作为一个成熟的分布式任务调度框架，在处理大规模定时任务时表现出色。通过合理的架构设计和实践，我们成功解决了任务重复执行、故障转移、弹性扩容等难题，大幅提升了系统稳定性和运维效率。未来计划结合云原生技术，探索 Elastic-Job-Cloud 和 Kubernetes 集成，实现更灵活的弹性调度。
2025-07-29 15:05:41
643
原创 MySQL 上亿大表，如何深度优化？
select arrival_record 慢查询语句都类似于如下所示，where语句中的参数字段是一样的，传入的参数值不一样 select count(*) from arrival_record where product_id=26 and receive_time between '2019-03-25 14:00:00' and '2019-03-25 15:00:00' and receive_spend_ms>=0\G。
2025-07-24 17:45:18
845
原创 腾讯面试拷打
传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，函数会一直阻塞，直到收到数据，返回读到的数据， 如果使用BIO要想要并发处理多个客户端的i/o，那么会使用多线程模式，一个线程专门处理一个客户端 io，这种模式随着客户端越来越多，所需要创建的线程也越来越多，会急剧消耗系统的性能。每次访问数据时，都会将对应的节点移动到链表头部，保证链表头部的节点是最近访问的数据，而链表尾部的节点是最久未访问的数据。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。
2025-07-23 19:09:12
1127
原创 [特殊字符] 浏览器输入 URL 到显示页面：全流程详解
1️⃣ DNS 解析浏览器先根据 URL 解析出域名（如查询本地缓存，如果没有则向 DNS 服务器查询对应 IP 地址。拿到 IP 地址，为后续 TCP 连接做准备。
2025-07-23 18:15:27
342
原创 [特殊字符]️ 《浏览器和服务器的安全约定：HTTPS 加密全过程》
为什么这么设计？非对称加密安全，但慢对称加密高效，但需要先协商出密钥摘要算法保证数据完整性所以 HTTPS 采用：用服务器的。
2025-07-23 18:12:58
251
原创 年薪百万又一步-----[特殊字符]《HTTPS 证书的自我介绍》
✅ 很棒的问题！是安全通信的核心，理解它对你掌握网络安全、系统架构都很有帮助。下面我整理一份完整、清晰、专业的讲解，方便你面试、复习或者写文档。
2025-07-23 17:36:28
910
原创 浅谈Zookeeper（粗浅的个人认识）
本文参考 <从Paxos到Zookeeper分布式一致性原理与实践 > <ZooKeeper分布式过程协同技术详解>为什么说ZK是一个CP系统?ZK适合用来做吗?ZK集群为什么推荐节点的个数为奇数?ZK有什么缺点?什么是脑裂?主从结构问题。
2025-07-22 17:46:07
816
原创 《锁得住你，也放得开你：Redis 分布式锁那些事儿》
具体场景，进程1在超时释放了锁之后，进程2获取到了锁，后来进程1又释放锁，如此以来就有可能导致进程2没有完成就被进程1释放了锁。会设置主从，主从服务器中的从服务器在检测到主服务器挂掉之后，就会重新选举一个作为主服务器，而redis锁是操作在主服务器上的。这个场景，是非常基本的场景，一旦锁被进程1获取之后，在释放锁之前，进程2是怎么知道何时才能够获取到锁呢？对于分布式锁的实现，除了redis锁之外，还有很多，像zookeeper，memcache，redis锁因为使用简单，所以被大家广泛使用。
2025-07-22 17:11:08
461
原创 《我的 Redis 不仅记忆力强，还天天写日记防失忆》
一些粉丝较少且不活跃的用户发表微博后，Vector 服务会首先查询 Vector Cache，如果 cache 中没有该用户的 Outbox 记录，则不写该用户的 cache 数据，直接更新 DB 后就返回，只有 cache 中存在才会通过 CAS 指令进行更新。MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。调用该命令，客户端可以清空事务队列，并放弃执行事务，且客户端会从事务状态中退出。
2025-07-22 17:08:22
885
原创 为什么单机 Redis 慢得像牛车，集群像火箭？
slave下线后，与其对应的master会将其标记为下线状态，同时通知集群中其他机器该slave下线；待其上线后，再与其进行。
2025-07-22 17:03:57
1288
原创 年薪百万第N步-----《SQL 慢得想下班，你忍得住吗？》
ON是最先执行， WHERE次之，HAVING最后，因为ON是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比HAVING快点的，因为它过滤数据后才进行SUM，在两个表联接时才用ON的，所以在一个表的时候，就剩下WHERE跟HAVING比较了。所以我的建议是，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。
2025-07-22 17:00:11
883
原创 年薪百万第N步-----《数据库撑不住了怎么办？先分！》
也就是说，数据增加，请求量增大，并发增大，单个数据库肯定不行。的解决方法有：缓存加速，读写分离，垂直拆分，分库分表，冷热数据分离，ES 辅助搜索，NoSQL 等方式，分库分表是海量数据存储与高并发系统的一个解决方案。分库， 经验来说，一个库对并发最多到 2000， 一定要扩容，一个健康的单库并发控制在1000 QPS 左右，如果超过，那么将一个库的数据拆分到多个库。如果单表数据达到 几千万了，数据量比较大，会极大影响 SQL 查询性能， 后面的SQL 执行会很慢，经验来说，单表数据几百万，就要考虑分表了。
2025-07-22 16:53:34
248
原创 年薪百万第N步-----《彻底搞懂布隆过滤器：高效去重与防穿透利器》
布隆过滤器本质上就是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的。
2025-07-22 16:47:38
601
原创 年薪百万第N步------《彻底搞懂BIO、NIO、AIO：原理、区别、最佳实践》
可以发现，AIO和NIO的使用方式基本一致，数据都是从Channel读入Buffer，或者从Buffer写入Channel中，不同的是AIO是实现了异步非阻塞。BIO适合连接数目较少且固定的架构，NIO适合连接数目多，但是并发读写操作相对较少的场景，AIO则适合连接数目多，且并发读写操作也多的场景。）， 通过上面代码和运行结果可以发现，在服务端和客户端进行通信时，我们并没有新建线程类进行通信，这也是NIO和BIO最大的区别之一。NIO适合一些复杂的、高频的、长连接的通信场景，例如聊天室、网络游戏等。
2025-07-22 16:45:31
661
原创 [特殊字符] 常见网络攻击原理与防范详解
DDoS（Distributed Denial of Service）分布式拒绝服务攻击，是指攻击者控制大量被入侵的设备（僵尸网络 botnet），向目标网站、服务器或网络发起海量流量或请求，耗尽目标带宽、连接数、CPU、内存等资源，使其无法正常服务。SQL注入：攻击者通过向 Web 表单、URL 参数、Header 等输入中注入恶意 SQL 语句，使数据库执行未授权操作，如窃取数据、篡改数据、删除表等。CSRF（Cross Site Request Forgery，跨站请求伪造）
2025-07-21 18:04:37
827
原创 [特殊字符] 前后端认证与会话管理全解：Cookie、Session、Token、JWT 区别、原理与实践
特性CookieSession状态无有无存储客户端服务器客户端扩展性差差好安全性依赖 HttpOnly高依赖实现推荐场景轻量状态小型应用分布式、微服务。
2025-07-21 16:32:12
876
原创 Redis 缓存淘汰与过期删除策略详解
策略触发条件优点缺点内存淘汰策略内存达到上限保证系统可用可能淘汰业务重要数据过期删除策略-惰性访问键时不耗费 CPU不访问的过期键不会被删过期删除策略-定期定时随机检查及时释放部分内存无法100%清理所有过期键🚀建议合理设置maxmemory和内存淘汰策略。按业务特点选择合适的过期时间和淘汰机制。监控 Redis 内存使用情况，及时扩容或优化数据结构。
2025-07-21 16:20:35
973
原创 Redis 如何保证原子性？事务和 Lua 的选择
单条命令天然原子性：Redis 基于单线程模型，所有命令逐个执行。多条命令保证原子性推荐使用 Lua 脚本，原子性强、支持复杂逻辑。也可以用事务（MULTI/EXEC），但事务中某条命令出错不会自动回滚，适合简单场景。🚀业务逻辑复杂、需要严格原子性：用 Lua 脚本。简单组合、命令本身可靠：用事务。
2025-07-21 15:26:44
590
原创 为什么 Redis 使用跳表而不是 B+ 树？
对比维度跳表B+ 树查询效率👍👍范围查询效率👍👍写入性能👍👎内存局部性👍👎实现复杂度👍👎内存占用👍👎Redis 不需要 B+ 树那种磁盘友好的特性，而需要内存访问更高效、实现更简单、写入更快的结构。因此选择了跳表作为有序集合的实现。📘跳表的实现简单、写入性能好、内存友好，完全胜任 Redis 中 Sorted Set 的场景需求。而 B+ 树则更适合磁盘数据库或需要极大规模范围查询的场景。
2025-07-21 15:23:04
711
原创 SSM 项目接入支付宝电脑网页沙箱支付全流程
支付和回调逻辑见上文 AliPayController 代码。核心逻辑：发起支付、接收异步通知。APPID、私钥、公钥都可以在。适配 SSM 使用注解读取。接入支付宝 SDK 并配置。后端异步回调更新订单状态。校验登录用户、收货地址。订单生成、校验、保存。
2025-07-21 15:19:31
498
原创 [特殊字符] 为什么数据库索引选择 B+ 树而不是跳表？
✅B+ 树层数低、每个节点存多个 key、减少了磁盘 I/O、顺序扫描高效、结构稳定，非常适合磁盘型数据库索引。✅跳表实现简单、随机性好，但节点稀疏、随机 I/O 多、磁盘局部性差，更适合内存场景。所以 MySQL/InnoDB 索引选择了 B+ 树，而不是跳表。
2025-07-21 13:58:32
452
原创 ✅ 理解容器化思想及容器与虚拟机的区别
容器并不是虚拟机的替代品，而是更适合现代云原生和微服务架构的选择。它以轻量、快速、资源隔离、高效管理的特点，成为 DevOps、CI/CD 和云计算时代的标配技术。理解它的思想和应用场景，有助于我们在项目架构设计、运维部署中做出更合理的决策。
2025-07-21 09:54:17
1235
原创 [特殊字符] MySQL EXPLAIN 执行计划详解
通过EXPLAIN，我们可以了解：表的读取顺序数据的访问方式哪些索引可以使用实际使用了哪些索引表之间的关联方式优化器估算的每张表扫描的行数。
2025-07-19 18:04:59
935
原创 RabbitMQ 消息重复消费、顺序性丢失和消息丢失全解析及最佳实践
问题原因解决方案重复消费RabbitMQ 至少一次投递业务幂等性 + 手动 ack顺序丢失并发消费/重投乱序单队列串行/顺序号消息丢失队列或消息未持久化✅ RabbitMQ 的核心设计哲学是 “可靠但不保证顺序、不排除重复”。✅ 我们必须在业务层做好幂等性设计顺序控制和可靠性保障，才能构建一个稳定的消息系统。
2025-07-19 17:52:40
687
原创 深度实战 | Spring Boot + ShardingSphere-JDBC 高级分库分表架构全流程
Slf4j@Override// 动态匹配或抛异常// 如果没有对应表，抛异常或者动态创建表（需要额外逻辑支持）throw new UnsupportedOperationException("没有对应的分表: " + suffix);问题解决方案SQL无分片键导致全库扫描必须WHERE条件包含分片键分片算法返回空，找不到目标表确认和算法逻辑对应读写分离主从延迟导致数据不一致设置合理的同步延迟，读写事务使用主库分布式事务异常。
2025-07-18 20:44:52
349
原创 [特殊字符] MySQL 分库分表详解 [特殊字符]（超详细，案例+原理+实践）
✅ 保证查询和写入的低延迟✅ 提高高并发下的吞吐能力✅ 减少单点风险✅ 提升备份/恢复效率✅ 支持业务增长的可扩展性🎁当你的数据库撑不起业务增长时，分库分表，是迈向高可用、高性能架构的第一步。🙂🙂 好的，我来帮你把「二、拆分的两种大方向」细化、扩展、配上背景逻辑、适用场景、优缺点、举例说明，写出一份更完整、更易懂的版本 🚀🏷️ 项目✂️ 垂直拆分✂️ 水平拆分拆分维度按业务、按字段按数据记录适合场景不同业务耦合严重单表数据量太大改造复杂度较低较高优点。
2025-07-18 15:10:30
1111
原创 持续拷打--------I/O
AIO（Asynchronous IO） ：是 Java 1.7 之后引入的包，是 NIO 的升级版本，提供了异步非堵塞的 IO 操作方式，所以人们叫它 AIO（Asynchronous IO），异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。非阻塞的核心就是通道和缓冲区，当IO事件就绪时，可以通过写到缓冲区，保证IO的成功，而无需线程阻塞式地等待。事件驱动机制，事件到来的时候触发操作，不需要阻塞的监视事件。
2025-07-18 14:59:22
861
原创 拷打不断---------小红书面经
可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其他的系统产生影响。这个过程会比较慢，因为是从硬盘上读取的。锁变量的值需要能区分来自不同客户端的加锁操作，以免在释放锁时，出现误释放操作，所以，我们使用 SET 命令设置锁变量值时，每个客户端设置的值是一个唯一值，用于标识客户端；
2025-07-18 10:34:29
926
原创 继续拷打--------百度面经
根 DNS 服务器收到递归查询后，它并不直接返回所需的 IP 地址，而是向本地 DNS 服务器提供对应顶级域（TLD）的 IP 地址，让本地 DNS 服务器继续查询。本地 DNS 服务器负责从根 DNS 服务器开始，依次向下进行查询，获取域名对应的 IP 地址。中间的 DNS 服务器协助完成查询过程，直到本地 DNS 服务器最终获取到目标域名对应的 IP 地址，然后将结果返回给客户端。相反，它会向发起查询的 DNS 服务器提供指向下一级 DNS 服务器的信息，让发起查询的 DNS 服务器继续查询。
2025-07-18 10:32:11
259
原创 拷打---------米哈游Java后端校招面经
通过将多个字段组合成一个索引，该索引就被称为联合索引。比如，将商品表中的 product_no 和 name 字段组合成联合索引联合索引的 B+Tree 示意图如下（图中叶子节点之间我画了单向链表，但是实际上是双向链表，原图我找不到了，修改不了，偷个懒我不重画了，大家脑补成双向链表就行）。图片可以看到，联合索引的非叶子节点用两个字段的值作为 B+Tree 的 key 值。当在联合索引查询数据时，先按 product_no 字段比较，在 product_no 相同的情况下再按 name 字段比较。
2025-07-18 10:29:42
625
原创 面试官：什么是回表，什么是索引下推？
使用 MySQL 时，我们经常会听到“回表”、“索引下推”这样的概念，今天就来聊一聊什么是回表，什么是索引下推。
2025-07-18 10:27:21
613
原创 年薪百万第N步-------大厂后端校招面经
当一个新任务交给线程池，如果此时线程池中有空闲的线程，就会直接执行，如果没有空闲的线程，就会将该任务加入到阻塞队列中，如果阻塞队列满了，就会创建一个新线程，从阻塞队列头部取出一个任务来执行，并将新任务加入到阻塞队列末尾。在「串行化」隔离级别下，事务 B 在执行将余额 100 万修改为 200 万时，由于此前事务 A 执行了读操作，这样就发生了读写冲突，于是就会被锁住，直到事务 A 提交后，事务 B 才可以继续执行，所以从 A 的角度看，余额 V1、V2 的值是 100 万，余额 V3 的值是 200万。
2025-07-18 10:26:06
877
原创 年薪百万第N步-----mysql 中的 mvcc 是怎么实现的？
对于「读提交」和「可重复读」隔离级别的事务来说，它们是通过 Read View 来实现的，它们的区别在于创建 Read View 的时机不同，大家可以把 Read View 理解成一个数据快照，就像相机拍照那样，定格某一时刻的风景。如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示这个版本的记录是在创建 Read View。如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值，表示这个版本的记录是在创建 Read View。
2025-07-18 10:22:23
686
原创 [特殊字符] CopyOnWriteArrayList 原理、源码剖析与优缺点分析
CopyOnWriteArrayList 是读多写少场景的利器，通过写时复制实现了高并发下的读性能保障。但需要注意写操作性能和内存占用。我们分别深度剖析了：✅阻塞队列：锁+条件变量+阻塞唤醒，解决生产消费问题✅ConcurrentHashMap：分段锁、CAS+红黑树，线程安全高性能 Map✅CopyOnWriteArrayList：写时复制，读多写少的列表神器。
2025-07-18 10:19:56
268
原创 [特殊字符] ConcurrentHashMap 源码剖析、原理与性能分析
ConcurrentHashMap 通过局部锁 + CAS 技术，有效提升了并发能力，是多线程环境下首选 Map 实现。但扩容仍有全表锁，需合理规划初始容量。
2025-07-18 10:18:58
247
原创 [特殊字符] 阻塞队列原理、源码剖析与实战应用
i++) {try {阻塞队列作为多线程开发中的重要武器，屏蔽了底层复杂的锁和条件变量逻辑，极大提升了开发效率。合理选择合适的实现类并配置合理的容量，是保障系统稳定高效的关键。
2025-07-18 10:17:05
762
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人