sqyaa.-优快云博客

原创业务数据增长应对法& 数据库索引核心知识

本文系统梳理了MySQL索引优化与数据增长应对方案。第一章重点讲解索引核心知识：索引类型（主键/辅助索引）、最左匹配原则、索引覆盖优化及EXPLAIN诊断工具使用。第二章针对大数据量场景，对比分析了分区表（RANGE/LIST/HASH分区）和分库分表（垂直/水平切分）两种方案，强调根据数据量级（如亿级数据需分库分表）和查询特点选择策略，并推荐使用Sharding-JDBC等中间件实现。全文贯穿"预防性设计+具体问题具体分析"的核心理念，为高并发系统数据存储提供实用解决方案。

2025-10-31 16:53:46 606

原创 timeline设计

微博时间线系统采用混合模式（读扩散+写扩散）应对高并发场景。普通用户采用写扩散，保证粉丝读取体验；大V用户区分活跃粉丝（异步写扩散）和非活跃粉丝（读扩散），通过二八定律优化性能。关键优化包括：数据分片、内容与ID分离、多级缓存、异步处理实现最终一致性。这种动态策略设计在保证系统高可用的同时，有效平衡了读写压力。

2025-10-20 14:02:50 1577

原创《设计模式》

简单工厂模式通过集中管理对象创建逻辑，有效解决了代码重复和配置分散问题；3）观察者模式实现了一对多的订阅通知机制，类比消息队列思想，但需注意通知顺序和内存泄漏问题。三种模式各具特点，都能通过解耦提升代码灵活性，但需要根据实际场景权衡利弊。

2025-10-14 17:29:01 671

原创 MySQL的悲观锁与乐观锁，面对读多写少MySQL如何优化

本文介绍了数据库乐观锁与悲观锁的实现方法及使用场景。乐观锁通过版本号、时间戳或业务字段实现，适用于低冲突场景；悲观锁通过SELECT...FOR UPDATE实现，确保数据强一致性但会降低并发性能。文章详细阐述了悲观锁的使用注意事项，包括索引使用、锁范围控制和超时处理，并分析了锁升级、死锁等典型问题。同时介绍了MySQL主从架构与读写分离方案，包括同步机制、实现方式和扩展限制，强调需要根据业务场景在数据一致性和系统性能间做出权衡。

2025-07-30 14:14:26 626

原创 binlog与Maxwell 与慢查询

MySQL的Binlog是记录数据库变更的二进制日志，默认不开启。它分为三种模式：Statement（记录SQL语句）、Row（记录行变更）和Mixed（混合模式）。安装Maxwell需配置专用数据库用户，并授予复制权限。Maxwell可将Binlog转换为JSON格式，通过Kafka实现数据实时同步，适用于主从复制、数据恢复等场景。典型应用架构为MySQL→Maxwell→Kafka→业务服务，实现变更数据的采集与分发。

2025-07-28 15:13:18 1022

原创优惠券模块系统理解高并发

本地缓存redis缓存使用，线程池优化，事务管理保证，缓存雪崩穿透解决，工厂+策略模式使用，数据一致性保证，切面使用，异步与多线程

2025-07-14 12:06:39 1070

原创 Guava LoadingCache

LoadingCache是Guava库提供的高性能本地缓存解决方案，具备自动加载机制（缓存未命中时自动加载数据）、线程安全、灵活的过期策略（基于写入/访问时间）和LRU淘汰机制。它支持丰富的统计功能，适用于高频读取场景如优惠券模板缓存，提供微秒级读取性能（10万+ QPS）。使用时需注意内存管理（设置maximumSize防OOM）和异常处理（建议使用Optional包装），但不适用于分布式环境。该缓存特别适合单机、数据量可控的高性能场景。

2025-07-12 00:04:14 343

原创 AQS源码整理(自用)

多线程如何抢锁？没抢到锁的线程如何处理？加入队列后，线程如何变化？当前线程如何释放锁？

2025-07-10 10:07:32 322

原创 AQS核心问题分析

AQS（AbstractQueuedSynchronizer）是Java并发编程的核心框架，其核心知识点包括：CLH队列变体的实现原理，通过双向链表管理等待线程，减少CPU缓存一致性流量；状态变量state的CAS操作，区分独占和共享模式；基于AQS的重要组件如ReentrantLock、CountDownLatch等。秋招高频考点包括AQS工作原理、线程阻塞与唤醒机制、公平锁与非公平锁实现差异等。面试准备建议从ReentrantLock源码入手，重点理解acquireQueued()和addWaiter(

2025-07-07 18:52:54 948

原创通过aqs分析ReentrantLock公平锁和非公平锁源码synchronized 实现的非公平锁

本文系统对比了Java中五种线程阻塞方法(sleep、wait、lock、park、自旋)的特性差异，重点分析了ReentrantLock公平锁与非公平锁的实现原理，以及synchronized内置锁的非公平特性。ReentrantLock通过双重CAS尝试实现非公平锁，而公平锁严格遵循FIFO；synchronized则通过偏向锁、轻量级锁和重量级锁三个阶段均体现非公平性。三种机制在锁获取策略上存在显著差异：非公平锁优先尝试插队获取，公平锁严格排队，synchronized则采用混合

2025-07-05 00:29:42 726

原创 ThreadLocalMap源码分析以及hash冲突解决

ThreadLocal通过ThreadLocalMap实现线程局部变量存储，核心机制包括：1)使用弱引用Entry防止内存泄漏；2)黄金分割哈希（HASH_INCREMENT=0x61c88647）配合位运算实现高效均匀分布；3)线性探测法解决哈希冲突，形成环形数组结构；4)自动清理无效Entry（key为null）并动态扩容（达到2/3容量阈值时rehash）。set方法流程包含查找覆盖、陈旧Entry替换、新Entry插入等步骤，确保线程安全和高性能。

2025-07-02 17:50:23 715

原创 ThreadLocal1

ThreadLocal是Java中实现线程封闭的机制，每个线程拥有独立的变量副本，避免多线程竞争。其核心通过ThreadLocalMap存储数据，key为弱引用的ThreadLocal实例，value为存储值。使用时需注意内存泄漏风险：1)ThreadLocalMap生命周期与线程相同；2)Key的弱引用可被GC回收，但Value仍可能泄漏。最佳实践是使用后调用remove()清理。与synchronized相比，ThreadLocal用空间换时间，实现无锁线程隔离。合理使用弱引用和及时清理能有效防止内存泄

2025-06-27 11:00:23 1044

原创 Kafka第六篇——存储数据

一个主题可以存在一个或者多个分区，每个分区存在一个或多个副本，分布在不同节点上面。一个节点只存储一个分区副本，每个分区会对应一个broker的物理文件目录。存储以数据的主题进行归类，leader副本收到文件不会立刻将数据写入磁盘文件（增强读取效率，保证磁盘文件存储的持久性）；将数据放在节点内存中，由专门组件周期性写入到文件，并且.log文件当文件大小超过1G可配置，或者数据停留时间，就会再生成一个log段；*专门组件（logmanager,也有配置参数值主要是时间和，flush值有的很大，就是。

2024-12-08 18:08:46 1077

原创 Kafka第五篇——生产数据异步同步发送ACKS 数据重复与乱序，幂等性操作

其中send发送数据和应答callback()没有必然的联系。每次callback后才能发送下一个数据。这里打印结果就是：可以回顾之前提到的 " 数据收集器是将数据按照主题分区纳入到ProducerBatch双端队列中，数据超过16k，就停止往队列中纳入数据，因为要保证数据的完整性，举个例子：当数据是20k,就立马停止接收数据，而不是因为20k>16k,就让他不被接受或者砍断！"，这里就可以看出为什么是先发送批数据后才进行callback反馈给producer说数据发送成功！

2024-12-08 18:08:13 777

原创 Kafka第四篇——生产数据总体概括，源码解析分区策略，数据收集器，Sender发送线程，key值

流程图以及总体概述拦截器分区器以及分区计算策略为啥进行分区计算？producer生产者怎么知道有哪些分区？分区计算如何自定义实现分区器？想说的在图里啦！宝宝！💡如果key值忘记传递了呢！？数据校验数据收集器注意Sender发送线程

2024-07-07 14:31:32 1226 3

原创 Kafka——消费者偏移量存储问题

一旦偏移量信息发生变化，Zookeeper 将通知订阅了该 Watch 的消费者，使得消费者能够及时更新自己的状态。：Zookeeper 将数据存储在磁盘上，即使发生服务器崩溃或重启，存储的偏移量信息也不会丢失。follower进行读操作，这意味着，Zookeeper 都只会接受并传播来自 Leader 节点的更新，从而确保所有节点的数据视图是一致的。确保了在多个操作同时发生时，每个操作都按照确定的顺序被处理和应用，避免了并发更新导致的数据不一致性问题。Zookeeper 能。

2024-06-22 11:09:29 1150 1

原创 kafka第二篇——主题创建，主题分区副本分配策略

主题包含一个或多个分区，每个分区在集群中有多个副本（Replica）分布在不同的 Broker 上。通过合理设计主题、分区和副本的布局，Kafka 可以实现高吞吐量、低延迟和可靠性的分布式消息传递系统。可以看文章kafka1中的架构推演发展历程标题下的内容。

2024-06-22 11:09:21 828

原创 Kafka第一篇——内部组件概念架构启动服务器zookeeper选举以及底层原理

引入 ——为什么分布式系统需要用第三方软件？JMS对比组件架构推演——备份实现安全可靠，Zookeepercontroller的选举controller和broker底层通信原理BROKER内部组件编辑topic创建

2024-06-21 17:34:01 1593 2

原创云主机选购指南：如何选择适合自己的云主机

移动云是中国移动提供的专业云服务品牌，基于移动云计算技术构建。它实现了云网一体化，确保客户享有安全可控的服务。通过充分利用移动云计算能力，打造了N+31+X资源布局，结合各省级数据中心，通过专线互联实现了业务跨区域的高速、低延迟、大带宽、高质量服务互通。：提供了云和网络一体化的服务，方便客户进行统一管理和配置。：注重安全性，为客户提供安全可控的云服务，保障数据和业务的安全。：拥有N+31+X的资源布局，结合全国各省的省级数据中心，为客户提供更广泛的资源覆盖。

2024-05-27 12:28:55 1122

原创 Baidu Comate智能编码助手快速入门与使用体验

Baidu Comate智能编码助手，基于百度强大的文心大模型技术，旨在为广大开发者提供高效、智能的编码辅助体验。它不仅具备代码智能推荐、生成、修改等功能，还支持100多种编程语言和多种IDE平台，能够深度解读企业与个人私域代码库，帮助开发者提升编码效率，释放软件生产力。下面博主将从Baidu Comate的优势，功能，基础使用等方面详细介绍Baidu Comate，欢迎各位伙伴共同学习使用，进行体验。

2024-05-08 08:31:34 920

原创 MySQL和redis特点以及超卖问题但是乐观锁会造成库存遗留问题还有连接超时用连接池解决

使用事务（Transaction）：在 Redis 中可以使用 MULTI组队、EXEC、WATCH 等命令来创建事务，确保多个命令的原子性执行，避免并发操作导致的超卖问题。乐观锁+版本号+事务三特性。总的来说，要解决 Redis 中的超卖问题，关键在于保证对资源的操作是原子性的，可以通过事务、分布式锁、Lua 脚本等方式来实现，确保在并发环境下数据的正确性和一致性。使用分布式锁：可以使用 Redis 的分布式锁来确保在对某个资源进行操作时只有一个客户端在操作，从而避免并发导致的超卖问题。

2024-03-21 08:52:37 554

原创索引。。。

对于单列索引，尽量选择针对当前query过滤性更好的字段进行索引在选择组合索引的时候，当前query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。在选择组合索引的时候，尽量选择能够包含当前query中的where子句中更多字段的索引。（区分度越高）在选择组合索引的时候，如果某个字段可能出现范围查询时，尽量把这个字段放在索引次序的最后面。==总之，写SQL时，尽量避免造成索引失效的情况。==理解方式一。

2024-03-10 22:20:24 1104

原创 redis——持久化之RDB&AOF

数据放在硬盘上即持久，内存上并不持久，当进程重启或者主机重启，根据数据是否仍然存在去判断持久性。redis是内存数据库，数据放在内存中，要想持久，就得把数据放在硬盘。但是redis的优势是快，快依赖于数据存储在内存。为了数据快，还是得存在内存，但是保证持久还是得存在硬盘中。于是redis内存也存，硬盘也存！来数据时，两边都存入（但是不一定完全一样）。内存负责查数据，硬盘负责每次重启的时候将数据恢复内存。优点是既保证高效又保证持久化，缺点就是开销空间。

2024-03-08 00:48:45 673

原创大文件上传

同时，为了提高上传和下载的效率，可以使用分块传输、断点续传等技术，减少因网络不稳定等原因导致的传输失败。后端接收到MD5值，在服务器中查找是否存在该md5对应的文件，如果服务器存在该文件，则直接返回已存在的文件路径，完成秒传。另外，为了提高效率，可以考虑使用分布式文件系统或对象存储服务来存储文件，以便实现文件的高可用和快速访问。如果所有块的哈希值都匹配，服务器将把块合并成完整的文件，并计算文件的 MD5 哈希值。在实际实现中，可以使用Java的MessageDigest类来计算文件的MD5值，使用。

2024-03-08 00:47:24 768

原创 java——2024-03-03

10.死锁是两个或者多个线程去争夺同一共享资源而导致的互相等待过程，在没有外部条件干预则会一直阻塞下去，每个线程都在等待另一个线程去释放锁。死锁有三个典型情况，第一个是。

2024-03-06 01:14:40 1166

原创 mq基础类设计

解耦合：就是在分布式系统中，A服务器调用B服务器，A给B发送请求，B给A返回响应，A和B之间耦合性很大。引入消息队列后，A把请求发给消息队列，B再从消息队列获取请求。削峰填谷：B接收，A传送过多，B会感受到峰值，而B的硬盘之类资源有限，有消息队列，B仍然可以按照原本速度进行接收数据。消息队列就是把阻塞队列这样的数据结构单独提取成一个程序独立进行部署。broker中间人负责转发和存储，mq和消费者的工作模式主要有两种，推：push，Broker把收到的消息主动。消息队列是在进程与进程之间进行实现的，

2024-03-05 12:01:19 521 1

原创 ReentrantLock &信号量&CountDownLatch&多线程环境使用集合类ArrayList和ConcurrentHashMap

ReentrantLock 也是一个可重入锁,使用了lock和unlock方式加锁解锁,使用效果上和 synchronized 是类似,1. ReentrantLock,在加锁的时候,有两种方式. lock, tryLock.给了更多的可操作空间lock(): 加锁, 如果获取不到锁就死等.trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁.

2024-02-21 11:58:54 1193

原创 synchronized原理&Callable接口

synchronized加锁的时候,并不是真正的加锁,而是先进入偏向锁状态,就相当于做一个标记,如果一直没有别的线程来获取这个锁,那么就不会升级,仅仅只做个标记,因为这个变量本来就只有这个线程要使用,过程也没有出现锁竞争,执行完synchronized{}代码块后,再取消掉标记(偏向锁)即可。但是,如果很快就释放锁了,自旋是值得的,可以立即获取被释放的锁,反之,迟迟不被释放,那么久迟迟拿不到锁,自旋就不划算了..这时候就需要再次升级了!相当于"懒汉模式"提到的懒加载一样,非必要,不加锁。

2024-02-21 11:58:15 1320

原创常见锁策略以及CAS

是典型的重量级锁，指当一个线程尝试获取锁时，如果锁已被其他线程占用，则该线程将会被挂起（即阻塞，阻塞的开销很大），直到锁可用为止。CAS 操作是原子性操作，它可以保证在多线程环境下对共享数据的操作是线程安全的。一个线程针对同一把锁连续加锁两次如果不会出现死锁就是可重入锁，sychronized就是可重入锁，其中引入计数器，并对锁的持有线程进行身份标识，当发现当前加锁的线程就是持有锁的线程就直接进行+1操作。是典型的轻量级锁，是一种忙等的锁，当一个线程尝试获取自旋锁时，如果锁已被其他线程占用，该线程会一直。

2024-02-21 11:57:23 1000 1

解码方法

空空如也