- 博客(153)
- 收藏
- 关注
RSS订阅原创 JUC并发集合-Java Fork/Join
在多核处理器时代，充分利用计算资源已成为提升应用性能的关键因素。然而，编写高效的并行程序一直是软件开发中的难题。开发者不仅需要考虑如何合理拆分任务，还要处理线程同步、负载均衡等复杂问题。Java作为企业级应用的主流语言，在并发编程领域不断演进，而Fork/Join框架的引入则是这一演进过程中的重要里程碑。Fork/Join框架是Java 7（2011年发布）中引入的一个并行执行框架，它是对Java并发工具集的重要扩展。在此之前，Java开发者主要依赖Thread类和Executor框架来实现并发，这些工具虽
2025-04-01 11:52:28
968
原创 JUC并发集合-ConcurrentHashMap
ConcurrentHashMap是Java并发包(java.util.concurrent)中提供的一个线程安全的哈希表实现，专门为并发环境设计。它允许多个线程同时进行读写操作，并且在设计上避免了全表锁定，提供了远高于Hashtable的并发性能。ConcurrentHashMap的核心设计目标是在保证线程安全的同时，提供尽可能高的并发性能。它通过精细的锁粒度和无锁技术，实现了高效的并发访问，是Java并发编程中最常用的线程安全集合之一。特性JDK 1.7JDK 1.8锁机制。
2025-03-31 11:34:55
591
原创 JUC并发集合-ConcurrentLinkedQueue
ConcurrentLinkedQueue是Java并发包(java.util.concurrent)中提供的一个线程安全的无界非阻塞队列，基于链表数据结构实现。它实现了Queue接口，遵循FIFO(先进先出)原则，专为高并发环境设计。作为一个非阻塞队列，ConcurrentLinkedQueue的操作永远不会导致线程阻塞。即使队列为空或者已满，相关操作也会立即返回，而不是等待条件满足。这种特性使其在高并发场景下表现出色，能够有效减少线程等待和上下文切换的开销。
2025-03-31 11:33:26
338
原创 JUC并发集合-ConcurrentSkipListMap
ConcurrentSkipListMap是Java并发包(java.util.concurrent)中提供的一个线程安全的有序映射表实现，基于跳表(Skip List)数据结构。它实现了ConcurrentNavigableMap接口，提供了丰富的有序操作和导航方法，同时保证了高并发环境下的线程安全性。ConcurrentSkipListMap的核心特点是结合了高效的并发访问能力和有序性，这在并发环境下是一个非常独特的组合。
2025-03-31 11:32:13
291
原创 JUC并发集合-CopyOnWriteArrayList
CopyOnWriteArrayList是Java并发包(java.util.concurrent)中提供的一个线程安全的ArrayList实现，它基于写时复制(Copy-On-Write)思想设计。CopyOnWriteArrayList专为并发环境设计，特别适合处理读多写少的并发场景。不变性带来线程安全。当多个线程需要并发访问同一个数据结构时，不是通过锁来协调访问，而是让每个线程都看到一个不变的数据视图。
2025-03-31 11:30:33
708
原创 JUC-锁体系
AQS的核心思想是"状态管理+等待队列"，它采用模板方法设计模式，将复杂的线程排队、阻塞和唤醒等操作封装起来，子类只需要实现少量方法定义自己的同步语义。LockSupport提供基础设施，AQS提供框架，Lock定义接口，具体锁实现提供不同的同步语义，Condition提供线程协作机制。通过组合这些组件，我们可以实现从简单的互斥锁到复杂的读写分离、从基本的线程同步到精细的条件等待，满足各种并发场景的需求。在我看来，Java并发锁机制是一个层次分明的体系，从底层到高层形成了一个完整的并发控制解决方案。
2025-03-13 09:37:30
697
原创 JUC-Condition
ondition接口本质上是Java并发编程中的一种线程等待-通知机制，它允许线程在某个条件不满足时暂时释放锁并等待，直到其他线程改变了条件并发出通知。从我的理解来看，Condition就像是一个"条件等待室"。可以想象一下，多个线程都想访问共享资源，但只有满足特定条件的线程才能继续执行。不满足条件的线程就会被引导到这个"等待室"里暂时休息，直到有人通知它们条件已经满足。在实际开发中，Condition解决了一个非常关键的问题：如何让线程在特定条件下进行精确协作。
2025-03-13 09:35:53
1118
原创 Redis- 秒杀场景
秒杀场景的本质是在极短时间内承受大量并发请求，同时保证有限商品的正确售卖。它具有三个核心特征：高并发（短时间内大量用户涌入）、资源有限（商品数量有限）和时效性强（活动在特定时间开始和结束）。这种场景对系统的性能、一致性和可用性提出了极高的挑战。从技术角度看，秒杀是一个典型的’多进程争抢有限资源’问题。以我们电商平台的一次手机秒杀为例，活动开始后的前30秒内，系统承受了超过50万QPS的峰值请求，而商品库存仅有1000台。
2025-03-08 17:47:49
1022
原创 Redis- 热key
热Key问题是指在分布式缓存或数据库系统中，某些特定的Key在短时间内接收到大量的访问请求，导致这些Key所在的节点负载过高，形成系统瓶颈，甚至引发雪崩效应。在理想情况下，请求应该均匀分布在所有节点上，但实际业务中，数据访问通常遵循二八定律，即20%的数据承担了80%的访问量。对于特别热的Key，还可以实现’副本漂移’，即为热Key创建更多的副本，提供更大的读取带宽。热Key分片是指将一个热Key的数据分散到多个子Key中，每个子Key负责一部分数据，从而将访问压力分散到多个节点。
2025-03-08 17:47:12
997
原创 Redis- 大key
大Key问题是指在Redis等内存数据库中，某个Key对应的value数据结构过大，通常是指单个Key的大小超过10KB甚至达到MB级别。这些大Key在读写操作时会消耗过多的内存和网络带宽，导致Redis性能下降，甚至引发系统稳定性问题。从本质上看，大Key问题是内存数据结构不合理使用的结果。Redis作为内存数据库，其主要优势在于高速的内存读写和原子操作，但这些优势建立在数据结构合理使用的基础上。当单个Key存储了过多数据时，会导致内存分配不均衡、网络传输效率降低，违背了Redis的设计初衷。
2025-03-08 17:46:29
799
原创 Redis-主从架构
Redis主从架构（Master-Slave Architecture）本质上是一种数据复制模型，它通过将数据从主节点复制到一个或多个从节点，实现数据冗余、负载分担和高可用性。“PSYNC2是Redis 4.0引入的增强版部分复制机制，主要解决了复杂拓扑结构下的复制效率和稳定性问题。“总之，PSYNC2是Redis复制机制的重要进步，为构建大规模、高可用的Redis集群提供了更坚实的基础。
2025-03-08 17:36:19
949
原创 Redis- 切片集群
Redis Cluster是Redis官方提供的分布式解决方案，它通过数据分片技术将数据自动分散存储到多个节点上，实现了水平扩展能力.Redis需要切片集群主要是为了解决单机Redis的几个关键限制：首先是内存容量限制。单个Redis实例受限于服务器物理内存，通常建议不超过25-30GB。而在大型应用中，数据量轻易就能超过这个限制。通过切片集群，我们可以将数据分散到多个节点，突破单机内存限制。其次是计算能力瓶颈。
2025-03-08 17:34:56
453
原创 Redis- 哨兵
Redis哨兵(Sentinel)是我认为Redis生态系统中最优雅的设计之一,它通过一种分布式监控和决策机制解决了Redis高可用性的核心问题。它主要提供四个核心功能:首先，它负责监控整个Redis主从集群的运行状态，实时检测主从节点是否正常工作。其次，当发现问题时，哨兵会通知系统管理员或其他应用程序，便于及时处理。第三，也是最关键的功能，哨兵提供自动故障转移。当主节点不可用时，哨兵会自动选择一个从节点升级为新的主节点，确保服务持续可用。
2025-03-08 17:33:14
594
原创 Redis - 经典业务场景
大Key问题是指在Redis等内存数据库中，某个Key对应的value数据结构过大，通常是指单个Key的大小超过10KB甚至达到MB级别。这些大Key在读写操作时会消耗过多的内存和网络带宽，导致Redis性能下降，甚至引发系统稳定性问题。从本质上看，大Key问题是内存数据结构不合理使用的结果。Redis作为内存数据库，其主要优势在于高速的内存读写和原子操作，但这些优势建立在数据结构合理使用的基础上。当单个Key存储了过多数据时，会导致内存分配不均衡、网络传输效率降低，违背了Redis的设计初衷。
2025-03-06 08:59:39
945
原创 Redis-分布式锁
单节点Redis的分布式锁在Redis节点故障时可能导致锁失效。为了提高可靠性Redis提出了Redlock算法，它使用多个独立的Redis节点来实现更可靠的分布式锁。
2025-03-06 08:57:26
1599
原创 缓存一致性问题
缓存系统之所以存在，是因为我们需要在速度较慢但容量大、持久的存储（数据库）之外，增加一层速度快但容量有限、易失的存储（缓存）。缓存一致性问题的本质是在分布式系统中，同一数据在不同存储介质（缓存和数据库）之间存在的状态差异，以及这种差异如何影响系统的正确性和可用性。支付系统和订单系统之间的状态同步，需要确保即使在系统部分失败的情况下，最终也能达到一致状态。在电商平台中，商品信息（如价格、库存）经常变动，需要确保数据库和缓存的一致性。用户资料可能在多个服务中被访问和修改，需要确保缓存中的数据是最新的。
2025-03-04 09:02:12
697
原创 读写分离架构下的一致性挑战
读写分离架构是一种常见的数据库架构，它将数据库分为读数据库和写数据库.读数据库用于读取数据，写数据库用于写入数据.通过将读操作和写操作分别路由到不同的数据库实例，以提高系统的整体性能和可扩展性。
2025-03-04 09:00:46
495
原创 并发更新导致的数据覆盖以及解决方案
列举了一些常见的数据覆盖现象,以及一些解决方案.大量代码,建议按需观看.问题描述多个客户端同时读取同一数据，各自修改后写回，后写入的数据会覆盖先写入的数据，导致先写入的修改丢失。// 用户A和用户B同时修改商品库存// 用户A的操作// 读取到库存为100// 减1后为99// 更新库存为99// 同时，用户B的操作// 也读取到库存为100// 减2后为98// 更新库存为98// 最终库存变为98，用户A的操作被覆盖，实际应该是97。
2025-03-03 14:34:03
694
原创 Base理论
BASE理论是对CAP理论的延伸和补充，特别适用于大型分布式系统，它提供了一种在保证系统可用性的同时，实现"最终一致性"的设计思路。BASE是三个英文单词的首字母缩写：Basically Available（基本可用）Soft state（软状态）Eventually consistent（最终一致性）
2025-03-03 14:05:49
747
原创 CAP理论
高可用性的定义定量定义: 通常用"几个9"表示，如"四个9"表示99.99%的时间系统是可用的，即每年最多允许52.56分钟的不可用时间。定性定义: 每个非故障节点都能在合理的时间内返回合理的响应，不会出现超时或错误。分区容错性是指系统在网络分区发生时，仍然能够继续运行。商品展示与搜索用户账户管理购物车功能订单处理库存管理支付系统集成该平台预计日订单量10万+，峰值期间（如促销活动）可能达到平时的10倍流量。
2025-03-03 14:04:55
1226
原创 Redis-列表结构实操
之前总结过-列表的数据结构,但是只是理论知识肯定是不行的,思来想去,总结了一些实操例子和实操场景,个人觉得还是很有用的,尤其是后面的场景,平时有我遇见的然后总结下来,例子都是我自己跑过的,没什么问题,有问题评论区见.本来还有一些,但是我写着写着感觉如果不介绍一些rua脚本的内容,现在意义也不大,如果只是练习指令,上面的应该已经足够了.关于业务场景的,后面我们单独出内容去聊.
2025-02-25 13:49:58
1244
原创 Redis - 哨兵
在发送 SLAVEOF no one 命令之后，哨兵 leader 会以每秒一次的频率向被升级的从节点发送 INFO 命令没进行故障转移之前，INFO 命令的频率是每十秒一次），并观察命令回复中的角色信息，当被升级节点的角色信息从原来的 slave 变为 master 时，哨兵 leader 就知道被选中的从节点已经顺利升级为主节点了。在已下线主节点属下的所有「从节点」中，挑选出一个状态良好、数据完整的从节点，然后向这个「从节点」发送 SLAVEOF no one 命令，将这个「从节点」转换为「主节点」。
2025-02-23 21:45:11
795
原创 Redis-主从复制如何实现
AOF 和 RDB，这两个持久化技术保证了即使在服务器重启的情况下也不会丢失数据（或少量损失）。如果服务器发生了宕机，由于数据恢复是需要点时间，那么这个期间是无法服务新的请求的；如果这台服务器的硬盘出现了故障，可能数据就都丢失了。避免这种单点故障，最好的办法是将数据备份到其他服务器上,让这些服务器也可以对外提供服务，这样即使有一台服务器出现了故障，其他服务器依然可以继续提供服务。多台服务器要保存同一份数据，这里问题就来了。这些服务器之间的数据如何保持一致性呢？
2025-02-23 14:30:00
738
原创 Redis-事务
所谓的事务，就是指对数据进行读写的一系列操作。事务在执行时，会提供专门的属性保证，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），也就是 ACID 属性。Redis 可以完全保证 ACID 属性吗？毕竟，如果有些属性在一些场景下不能保证的话，很可能会导致数据出错，所以，我们必须要掌握 Redis 对这些属性的支持情况，并且提前准备应对策略。
2025-02-23 12:03:03
1060
原创 Redis-AOF
RDB方式不能提供强一致性，如果Redis进程崩溃，那么两次RDB之间的数据也随之消失。那数据丢失的太多我们很难忍受,Redis推出的AOF很好的解决了数据持久化的实时性.AOF是一个日志文件，Redis的每个命令都将AOF以独立日志的方式记录每次写命令,AOF日志记录不同于MySQL先写入日志然后再执行操作（两阶段提交），AOF是执行成功的命令.AOF会先把命令追加在AOF缓冲区，然后根据对应策略写入硬盘（appendfsync）.
2025-02-21 17:26:30
1072
原创 Redis-RDB
因为Redis的数据都储存在内存中，当进程退出时，所有数据都将丢失。为了保证数据安全，Redis支持RDB持久化机制有效避免数据丢失问题。RDB可以看作在某一时刻Redis的快照（snapshot），非常适合灾难恢复.RDB就像是一台给Redis内存数据存储拍照的照相机，生成快照保存到磁盘的过程。Redis 的快照是全量快照，也就是说每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。所以可以认为，执行快照是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。
2025-02-21 16:23:36
827
原创 Redis-缓存过期和内存淘汰
LRU算法全称是最近最少使用算法（Least Recently Use），广泛的应用于缓存机制中。当缓存使用的空间达到上限后，就需要从已有的数据中淘汰一部分以维持缓存的可用性，而淘汰数据的选择就是通过LRU算法完成的。LRU算法的基本思想是基于局部性原理的时间局部性：如果一个信息项正在被访问，那么在近期它很可能还会被再次访问。所以顾名思义，LRU算法会选出最近最少使用的数据进行淘汰。
2025-02-20 16:54:41
1031
原创 Redis-线程模型
Redis 的线程模型其实是分两块的：Redis 6.0 之前的单线程模型。其实从 4.0 开始，Redis 并不是严格意义上的单线程模型，因为 Redis 除了主线程外，也有一些后台的线程或者子进程在处理任务（例如清理脏数据、生成快照、AOF 重写），这个时候大家所说的单线程应该是 Redis 的主线程模型。Redis 6.0 之后的多线程模型。Redis 在 6.0 之后引入了一种多线程模型，用于处理网络 I/O 的任务。所以，你的回答要涉及这两个方面。
2025-02-20 15:24:38
1006
原创 Redis数据结构总结-listPack
quicklist 虽然通过控制 quicklistNode 结构里的压缩列表的大小或者元素个数，来减少连锁更新带来的性能影响，但是并没有完全解决连锁更新的问题。因为 quicklistNode 还是用了压缩列表来保存元素，压缩列表连锁更新的问题，来源于它的结构设计，所以要想彻底解决这个问题，需要设计一个新的数据结构。
2025-02-20 10:47:17
1106
原创 Redis数据结构总结-quickList
为什么会出现ziplist？有两个原因促进它的出现：对于普通的双端列表(linked list)，它有指向前后的两个指针，对于存储数据小的情况下，通常指针占用的空间将超过数据占用空间；对于redis这种内存型结构，对于这种情况不能容忍Linked list，是一种链表结构，在内存中通常不是连续的，从而导致遍历效率低下ziplist的出现，解决了以上两个问题ziplist 的最大特点，是它被设计成一种内存紧凑型的数据结构，占用一块连续的内存空间，以达到节省内存的目的。
2025-02-20 10:20:46
1202
原创 Redis数据结构总结-跳表
普通链表的时间复杂度很有意思,增删改都是O(1),只有查是O(n).而且无论这个链表元素是否有序,查询时间复杂度都是O(n),这就很让人沮丧了.如果是数据的话,元素有序我们可以去用二分法,那就快很多了.但是链表的查询让人有点绝望.难道一点办法都没有吗?如果链表是有序的,还是有办法的,新的数据结构-跳表!链表在查找元素的时候，因为需要逐一查找，所以查询效率非常低，时间复杂度是O(N)，于是就出现了跳表。
2025-02-19 17:19:27
1631
原创 Redis数据结构总结-整数集合
整数集合是 Set 对象的底层实现之一。当一个 Set 对象只包含整数值元素，并且元素数量不大时，就会使用整数集这个数据结构作为底层实现。它的一个优点就是可以节省很多内存.虽然字典结构的效率很高，但是它的实现结构相对复杂并且会分配较多的内存空间。总结一下，整数集合(intset)使用了非常简洁的数据结构，可以更少的占用内存存储一些整数，但终究是基于数组的，也就避免不了不能存储大量数据的缺点。
2025-02-19 15:23:47
606
原创 Redis数据结构总结-哈希表
Hash 表是一种非常关键的数据结构。比如在数据库系统中，Hash 表被用来辅助 SQL 查询。而对于 Redis 键值数据库来说，Hash 表既是键值对中的一种值类型，同时，Redis 也使用一个全局 Hash 表来保存所有的键值对，从而既满足应用存取 Hash 结构数据需求，又能提供快速查询功能。Hash 表应用如此广泛的一个重要原因，就是从理论上来说，它能以 O(1) 的复杂度快速查询数据。
2025-02-19 14:46:32
868
原创 Redis数据结构总结-链表&&压缩列表
当我们的容器对象的元素个数小于一定条件时，redis 会使用 ziplist 的方式储存，来减少内存的使用。然后在 Redis 5.0 设计了新的数据结构 listpack，沿用了压缩列表紧凑型的内存布局，最终在最新的 Redis版本，将 Hash 对象和 Zset 对象的底层数据结构实现之一的压缩列表，替换成由 listpack 实现。因此，Redis 3.0 的 List 对象在数据量比较少的情况下，会采用「压缩列表」作为底层数据结构的实现，它的优势是节省内存空间，并且是内存紧凑型的数据结构。
2025-02-19 13:34:09
906
原创 并发编程-基础八股
进程是运行时程序的实例, 是系统进行资源分配和调度的基本单位,实现了操作系统的并发(指用户/cpu可以在多个应用程序间切换).资源独立性每个进程都有独立的内存空间和资源,进程间通信需要通过特定的机制,如管道,消息队列等状态管理进程可以处于不同的状态,如就绪,运行,阻塞等开销因为需要分配独立的内存空间和资源,所以创建和管理进程的开销较大.线程是进程的子任务,是CPU调度的基本单位,用于保证程序的实时性,实现进程内部的并发,是操作系统的最小执行和调度单位.共享资源。
2025-02-18 17:39:52
771
原创 Redis- 对象专辑
Redis中实际操作主要有6个对象,它们的底层会依赖一些数据结构(字符串,跳表,哈希表等),不同对象也有可能依赖相同数据结构,文章以对象为主,再介绍相关联的数据结构. 文章以实践为第一原理,结合《Redis的设计与实现》理论和n个博客构成Redis系列文章.
2025-02-18 17:38:26
1197
原创 图论- 经典最小生成树算法
在图中找一棵包含图中所有节点的树, 且权重和最小的那棵树就叫最小生成树.如下:右侧生成树的权重和显然比左侧生成树的权重和要小。(但是它并不是最小的,这里只是比较一下不同的树)
2025-02-15 18:51:33
1161
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人