自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(310)
  • 收藏
  • 关注

原创 Spring源码解析(10)之Spring 是如何解决循环依赖的

之前有篇章有介绍过spring是如何解决循环依赖Spring源码解析(7)之循环依赖解决_jokeMqc的博客-CSDN博客的,但是我看了之后感觉说的比较的简单,这里再结合spring的源码,说明spring是如何解决循环依赖的。 一、什么是循环依赖所谓的循环依赖就是A依赖B,B依赖A,或者是A依赖B,B依赖C,C依赖A。 代码实例:getter/setter public class InstanceA { ...

2021-11-16 15:26:14 686

原创 x-requested-with的作用以及用法详解

x-requested-with 请求头 区分ajax请求还是普通请求在服务器端判断request来自Ajax请求(异步)还是传统请求(同步):   两种请求在请求的Header不同,Ajax 异步请求比传统的同步请求多了一个头参数   1、传统同步请求参数     accept text/html,application/xhtml+xml,application/xml;q=0.9,/;

2017-12-07 11:45:39 60680 5

原创 互联网全景消息(11)之Kafka深度剖析(下)

在前面讲过kafka每个主题可以有多个分区,每个分区在它所在的broker上创建一个文件夹每个分区又分为多个段,每个段两个文件,log文件存储顺序消息,index文件里存消息的索引,然后每一个段的命名直接以当前段的第一条消息的offset为名。需要注意的是偏移量,不是序号,然后偏移量是从下标0开始,第几条消息 = 偏移量 +1,类似于数组长度和下标。例如:0.log -> 该文件存储8条数据,offset为0-7;8.log -> 有两条,offset为 8-9;

2025-01-14 14:52:37 834

原创 互联网全景消息(10)之Kafka深度剖析(中)

kafka高级应用

2025-01-10 11:19:49 1044

原创 互联网全景消息(9)之Kafka深度剖析(上)

Kafka最初是LinkedIn公司采用Scala 语言开发,现在已经捐赠给了Apache基金会。目前Kafka已经定位为一个分布式流式处理平台,它以高吞吐、可持久化、可水平扩展、支持流处理等多种特性而被广泛应用。Apache Kafka能够支撑海量数据的数据传递,在离线和实时的消息处理业务系统中,Kafka都有广泛的应用。

2025-01-08 18:23:38 1116

原创 分布式专题(11)之Zookeeper特性与节点数据类型详解

Zookeeper数据模型与结构与Unix文件系统很类似,整体上可以看做是一棵树,每个节点称做一个ZNode。Zookeeper的数据模型是层次模型,层次模型常见于文件系统。Zookeeper的层次模型称做Data Tree,Data Tree的每个节点叫做ZNode。不同于文件系统,每个节点都可以保存数据,每个ZNode默认能够存储1MB的数据,每个ZNode都可以通过其路径的唯一标记,每个节点都有一个版本(Version),版本从0开始计数;

2025-01-03 11:03:48 1258

原创 互联网全景消息(8)之RabbitMQ进阶介绍

基于死信队列在队列消息已满的情况下,消息也不会丢失;实现延迟消费的效果。比如:下订单时,有15分钟的付款时间。

2024-12-30 15:49:57 1079

原创 分布式专题(10)之ShardingSphere分库分表实战指南

在之前的示例中就介绍了ShardingSphere提供的MOD、HASH-MOD这样的简单内置分片策略,standard、complex、hint三种典型的分片策略以及CLASS_BASED这种扩展分片策略的方法。为什么要有这么多的分片策略,其实就是以为分库分表面临的业务场景其实是很复杂的。即便是ShardingSphere,也无法真的像MySQL、Oracle这样的数据库产品一样,完美的兼容所有的SQL语句。

2024-12-24 11:39:31 1434

原创 分布式专题(9)之Mysql高可用方案

数据库,应该是一个应用当中最为核心的价值所在,也是开发过程中必须熟练掌握的工具。之前我们就学习过很多对MySQL的调优。但是随着现在互联网应用越来越大,数据库会频繁的成为整个应用的性能瓶颈。我们经常使用的MySQL数据库,也就不断面临数据量太大、数据访问太频繁、数据读写速度太快等一系列的问题。而传统的这些调优方式,在真正面对海量数据冲击时,往往就会显得很无力。因此,现在互联网对于数据库的使用也越来越小心谨慎。例如添加Redis缓存、增加MQ进行流量削峰等。

2024-12-23 20:26:29 1796

原创 分布式专题(8)之MongoDB存储原理&多文档事务详解

MongoDB从3.0开始引入可插拔存储引擎的概念,主要有MMAPV1、WiredTiger存储引擎可供选择。从MongoDB 3.2开始,WiredTiger存储引擎是默认的存储引擎。从4.2版开始,MongoDB删除了废弃的MMAPv1存储引擎。事务(transaction)是传统数据库所具备的一项基本能力,其根本目的是为数据的可靠性与一致性提供保障。而在通常的实现中,事务包含了一个系列的数据库读写操作,这些操作要么全部完成,要么全部撤销。

2024-12-19 16:33:10 1517

原创 分布式专题(7)之MongoDB分片集群&高级集群架构详解

chunk的意思是数据块,一个chunk代表了集合中的“一段数据”,例如,用户集合(db.users)在切分成多个chunk之后如图所示:chunk所描述的是范围区间,例如,db.users使用了userId作为分片键,那么chunk就是userId的各个值(或哈希值)的连续区间。chunk的切分方式,决定如何找到数据所在的chunkchunk的分布状态,决定如何找到chunk所在的分片。

2024-12-17 20:44:25 1409

原创 分布式专题(6)之MongoDB复制(副本)集实战及其原理分析

Mongodb复制集(Replication Set)由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点,Mongodb Driver(客户端)的所有数据都写入Primary,Secondary从Primary同步写入的数据,以保持复制集内所有成员存储相同的数据集,提供数据的高可用。复制集提供冗余和高可用性,是所有生产部署的基础。数据写入时将数据迅速复制到另一个独立节点上在接受写入的节点发生故障时自动选举出一个新的替代节点。

2024-12-17 15:56:29 1416

原创 分布式专题(5)之MongoDB聚合操作与索引使用详解

聚合操作允许用户处理多个文档并返回计算结果。聚合操作组值来自多个文档,可以对分组数据执行各种操作以返回单个结果。聚合操作包含三类:单一作用聚合、聚合管道、MapReduce。聚合管道是一个数据聚合的框架,模型基于数据处理流水线的概念。从MongoDB 5.0开始,map-reduce操作已被弃用。

2024-12-16 18:20:35 723

原创 分布式专题(4)之MongoDB快速实战与基本原理

MongoDB是一个文档数据库(以JSON为数据模型),由C++语言编写,旨在为WEB应用提供可扩展的高性能存储解决方案。MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的,它支持的数据结构非常松散,数据格式是BSON,一种类似JSON的二进制形式的存储格式,简称Binary JSON,和JSON一样支持内嵌的文档对象和数组对象,因此可以存储比较复杂的数据类型。

2024-12-12 20:38:54 1182

原创 分布式专题(3)之Redis缓存设计与性能优化

缓存穿透是指查询一个根本不存在的数据, 缓存层和存储层都不会命中, 通常出于容错的考虑, 如果从存储层查不到数据则不写入缓存层。缓存穿透将导致不存在的数据每次请求都要到存储层去查询, 失去了缓存保护后端存储的意义。造成缓存穿透的基本原因有两个:第一, 自身业务代码或者数据出现问题。第二, 一些恶意攻击、 爬虫等造成大量空命中。

2024-12-11 17:47:08 731

原创 分布式专题(2)之Redis缓存高可用集群

在redis3.0之前的版本有实现集群一般是借助哨兵sentinel工具来监控master节点的状态,如果master节点异常,则会做主从切换,将某一台slave作为master,哨兵的配置略微复杂,并且性能和高可用各方面表现一般,特别是在主从切换的瞬间访问中断的情况,而且哨兵模式只有一个主节点对外提供服务,没发支持很高的并发,且单个节点内存也不宜设置过大,否则会导致持久化文件过大,影响数据恢复或主从同步频率。

2024-12-10 14:20:03 972

原创 分布式专题(1)之Redis持久化、主从与哨兵架构详解

在默认的情况下,Redis将内存数据快照保存名字为:dump.rdb的二进制文件中,当然你在配置文件redis.conf中修改对应的二进制文件名。redis开启RDB快照,可以在redis中设置,如:让它在N秒内至少有多少个改动这一条件满足时,就自动保存一次快照数据。例如:比如说, 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时, 自动保存一次数据集:save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可。

2024-12-09 20:19:46 1258

原创 并发专题(10)之FutureTask源码剖析

Java创建线程的方式,一般常用的是Thread,Runnable,如果需要处理当前的任务有返回结果的话,需要使用Callable。Callable运行需要配合Future来使用。Future是一个接口,一般会使用FutureTask实现类去接收Callable任务的返回结果。FutureTask存在的问题就是同步非阻塞执行的任务,他不会主动通知你返回结果是什么。

2024-12-07 14:04:16 342

原创 并发专题(9)之JUC阻塞队列源码分析

DelayQueue是无界队列,延迟的操作,可以向延迟队列追加任务,这个任务需要指定延迟时间,只有延迟时间到了,才可以将任务从队列中获取出来。任务可以指定延迟时间,所以需要任务满足一定的需求,DelayQueue的任务需要实现Delayed接口,重写getDelay方法和compare方法。getDelay:任务什么时候可以出队列。。compareTo:存放任务到队列时,放在二叉堆的哪个位置。

2024-12-05 20:13:24 757

原创 并发专题(8)之JUC阻塞容器源码剖析

ArrayBlockingQueue底层是采用数组实现的一个队列。因为底层是数据,一般被成为有界队列、其阻塞模式是基于ReentrantLock来实现的。// 存数据操作 add(E),offer(E),put(E),offer(E,time,unit) // add(E):添加数据到队列,如果满了,扔异常。

2024-12-03 16:31:25 998

原创 并发专题(7)之JUC并发工具源码分析

CountDownLatch本身就好像一个计数器,可以让一个线程或多个线程等待其他线程完成后再执行。

2024-11-30 15:54:43 614

原创 并发专题(6)之ConcurrentHashMap源码剖析

HashMap和ConcurrentHashMap的存储结构是一致的。ConcurrentHashMap是线程安全的。

2024-11-29 18:44:59 393

原创 并发专题(5)之ThreadPoolExecutor源码剖析

为了避免频繁的创建和销毁线程造成不必要的开销,一般在使用线程时,会采用线程池的方式。。以上的数量只是常规的数量配置,但是实际设置数量要根据压测,以及对线程池的监控才能得出最适合的线程配置。

2024-11-27 14:45:48 518

原创 并发专题(4)之ReentrantReadWriteLock读写锁源码分析

因为ReentrantLock是互斥锁,如果有一个操作是读多写少,同时还需要保证线程安全,那么使用ReentrantLock会导致效率比较低。因为多个线程在对同一个数据进行读操作时,也不会造成线程安全问题。所以就出现了读写锁。读读操作是共享的。写写操作是互斥的。读写操作是互斥的。写读操作是互斥的。单个线程获取写锁后,再次获取读锁,可以拿到。(写读可重入)单个线程获取读锁后,再次获取写锁,拿不到。(读写不可重入。

2024-11-26 11:31:25 633

原创 并发专题(3)之同步并发工具使用场景

解决多线程竞争资源的问题,例如多个线程同时对同一个数据库进行写操作,可以使用ReentrantLock保证每次只有一个线程能够写入。实现多线程任务的顺序执行,例如在一个线程执行完某个任务后,再让另一个线程执行任务。实现多线程等待/通知机制,例如在某个线程执行完某个任务后,通知其他线程继续执行任务。限流:Semaphore可以用于限制对共享资源的并发访问数量,以控制系统的流量。资源池:Semaphore可以用于实现资源池,以维护一组有限的共享资源。

2024-11-24 14:54:48 762

原创 并发专题(2)之ThreadLocal详解

JVM 利用设置 ThreadLocalMap 的 Key 为弱引用,来避免内存泄露。JVM 利用调用 remove 、get 、set 方法的时候,回收弱引用。当 ThreadLocal 存储很多 Key 为 null 的 Entry 的时候,而不再去调用 remove、 get 、set 方法,那么将导致内存泄漏。使用线程池+ ThreadLocal 时要小心, 因为这种情况下, 线程是一直在不断的 重复运行的,从而也就造成了 value 可能造成累积的情况。

2024-11-20 19:59:40 1031

原创 并发专题(1)之深入理解并发、线程与等待通知机制

我们常听说的是应用程序, 也就是 app ,由指令和数据组成。但是当我们不 运行一个具体的 app 时,这些应用程序就是放在磁盘(也包括 U 盘、远程网络 存储等等)上的一些二进制的代码。一旦我们运行这些应用程序,指令要运行, 数据要读写,就必须将指令加载至 CPU,数据加载至内存。在指令运行过程中 还需要用到磁盘、网络等设备,从这种角度来说, 进程就是用来加载指令、管理 内存、管理 IO 的。进程就可以视为程序的一个实例。

2024-11-19 17:54:38 892

原创 性能调优专题(15)之JVM调优实战及常量池详解

Arthas 是 Alibaba 在 2018 年 9 月开源的 Java 诊断工具。支持 JDK6+, 采用命令行交互模式,可以方便的定位和诊断线上程序运行问题。

2024-11-18 15:31:07 524

原创 性能调优专题(14)之JVM调优工具 及调优实战

前置启动程序:事先启动一个web应用程序,用jps查看其进程id,接着用各种jdk自带命令优化应用。

2024-11-15 19:58:50 783

原创 性能调优专题(13)之G1垃圾收集器

G1(Garbage-First)是一款面向服务器的垃圾收集器,主要针对设备多颗处理器及大容量内存的机器,以极高概率满足GC停顿时间要求的同时,还具备高吞吐性能特征。G1将Java堆划分为多个大小相等的独立区域(Region),JVM目标是不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义),实际可以超过该值,但是不推荐。

2024-11-15 10:18:03 1049

原创 性能调优专题(12)之垃圾收集器ParNew&CMS与底层三色标记算法详解

当前虚拟机的垃圾收集器都采用分代收集理论,只是根据对象存活周期的不同将内存分为几块。一般Java将堆分为新生代和老年代,这样子我们就可以根据各个年代的特点选择合适的垃圾收集算法。比如在新生代中,每次收集都会有大量对的对象死去,所以可以选择复制算法,只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活机率高,而且没有额外的空间对它进行担保,所以我们必须选择“标记-清除”算法或者“标记-整理算法”进行垃圾收集。

2024-11-14 17:14:06 1117

原创 性能调优专题(11)之JVM对象创建与内存分配机制深度剖析

大量的对象被分配在eden区,eden区满了后会触发minor gc,可能会有99%以上的对象成为垃圾被回收掉,剩余存活的对象会被挪到为空的那块survivor区,下一次eden区满了后又会触发minor gc,把eden区和survivor区垃圾对象回收,把剩余存活的对象一次性挪动到另外一块为空的survivor区,因为新生代的对象都是朝生夕死的,存活时间很短,所以JVM默认的8:1:1的比例是很合适的,让eden区尽量的大,survivor区够用即可。而在JAVA中对象就是可以被进一步分解的聚合量。

2024-11-14 10:30:07 910

原创 性能调优专题(10)之JVM内存模型深度剖析与优化

在minor gc过程中对象挪动后,引用如何修改?对象在堆内部挪动的过程其实是复制,原有区域对象还在,一般不直接清理,JVM内部清理过程只是将对象分配指针移动到区域的头位置即可,比如扫描s0区域,扫到gcroot引用的非垃圾对象是将这些对象复制到s1或老年代,最后扫描完了将s0区域的对象分配指针移动到区域的起始位置即可,s0区域之前对象并不直接清理,当有新对象分配了,原有区域里的对象也就被清除了。

2024-11-12 18:57:02 752

原创 性能调优专题(9)之从JDK源码级别解析JVM类加载机制

自定义类加载器只需要继承 java.lang.ClassLoader 类,该类有两个核心方法,一个是loadClass(String, boolean),实现了双亲委派机制,还有一个方法是findClass,默认实现是空方法,所以我们自定义类加载器主要是重写findClass方法。try {//defineClass将一个字节数组转为Class对象,这个字节数组是class文件读取后最终的字节数组。

2024-11-11 19:22:11 895

原创 性能调优专题(8)之MYSQL全局优化与Mysql8.0新特性详解

从上图可以看出SQL及索引的优化效果是最好的,而且成本最低,所以工作中我们要在这块花更多时间。

2024-11-10 19:14:30 1414

原创 性能调优专题(7)之Innodb底层原理与Mysql日志机制深入剖析

大体来说,Mysql可以分为Server层和存储引擎层两部分。

2024-11-09 16:46:00 371

原创 性能调优专题(6)之MVCC多版本并发控制

Mysql在可重复读隔离级别下如果保证事务较高的隔离性,在上一个篇章有详细介绍,同样的sql语句在一个事务多次执行查询结果相同,就算其他事务对数据进行修改也不会影响到当前事务sql语句的查询结果。这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的,对一行数据的读和写操作默认是不会通过加锁互斥来保证隔离性,避免了频繁加锁互斥,而在串行化隔离级别为了保证较高的隔离性是通过所有操作加锁互斥来实现的。

2024-11-08 11:11:28 96

原创 性能调优专题(5)之深入理解Mysql事务隔离级别与锁机制

我们的数据库一般都会并发执行多个事务,多个事务可能会并发的对相同的一批数据进行增删改查操作,可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。这些问题的本质都是数据库的多并发事务问题,为了解决多事务并发问题,数据库设计了事务的,用一整套机制来解决多事务并发问题。接下来我们会深入讲解这些机制,让大家彻底理解数据库内部的执行原理。

2024-11-07 14:42:34 384

原创 性能调优专题(4)之Mysql索引优化实战二

关联字段加索引,让mysql做join操作时尽量选择NLJ算法,驱动表因为需要全部查询出来,所以过滤的条件也尽量要走索引,避免全表扫描,总之,能走索引的过滤条件尽量都走索引小表驱动大表,写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式,省去mysql优化器自己判断的时间。straight_join解释:straight_join功能同join类似,但能让左边的表来驱动右边的表,能改表优化器对于联表查询的执行顺序。

2024-11-06 14:18:55 74

原创 性能调优专题(3)之Mysql索引优化实战一

1、MySQL支持两种方式的排序filesort和index,Using index是指MySQL扫描索引本身完成排序。index效率高,filesort效率低。2、order by满足两种情况会使用Using index。1) order by语句使用索引最左前列。2) 使用where子句与order by子句条件列组合满足索引最左前列。3、尽量在索引列上完成排序,遵循索引建立(索引创建的顺序)时的最左前缀法则。4、如果order by的条件不在索引列上,就会产生Using filesort。

2024-11-05 17:54:48 74

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除