- 博客(73)
- 收藏
- 关注
RSS订阅原创 深入理解依赖反转原则(DIP)
依赖反转原则从定义上看是要依赖于抽象，不要依赖于细节， 这个听起来很简单，好像加个接口就完事了，大家的service都是一个接口配一个实现类，是不是依赖倒置呢？很显然不是，不然今天就不用讲了
2023-12-22 22:32:53
244
原创 你觉得ACID别扭吗？
不知道大家在看ACID定义时，有没有感觉疑惑或者别扭。一个疑惑是：AID的定义是很清晰的，看了就能明白是什么意思，但是C的定义似乎不太清晰；另一个疑惑是：难道原子性隔离性持久性不是为了满足一致性吗？他们好像并不是正交的，放在一起合适吗？
2022-11-06 08:22:29
505
1
原创 分布式系统原理-分布式事务方案那么多，到底该选哪一个
不存在完美的分布式事务方案，只有不断地trade off。而且不一定非要用分布式事务，对账也挺香的
2022-11-06 08:10:41
753
原创 分布式系统原理-BASE，可用性高于强一致性
BASE的核心思想是在分布式系统中，可用性的重要程度应该是普遍高于强一致性的，这其实也更符合分布式系统的初衷
2022-11-06 07:21:58
488
原创 分布式系统原理-CAP定理，说起来一句话，实际坑不少
CAP定理说起来就是一句话的事情哦，但是里面其实有不少值得注意的点。首先是CAP定理的讨论范围，范围很重要，脱离了这个范围再谈CAP那就是耍流氓了
2022-11-05 19:10:46
364
原创 分布式系统原理-世界上只有一种共识算法，那就是Paxos
很多中文资料把 共识Consensus翻译为一致性，也就是"分布式一致性算法"，听起来就很像是保证数据一致性的算法，就很让人迷惑。共识（Consensus）与一致性（Consistency）是有区别的：分布式一致性我们之前说过，指的是协调数据在不同副本之间的差异。而共识的重点是让多个节点达成一致，这和多副本数据差异完全不是一回事，大家以后看到分布式一致性算法就要知道它的重点是达成共识。本文重点介绍了分布式共识算法的起源于他要解决的问题
2022-11-05 19:02:48
1204
原创 分布式系统原理-为什么需要一个分布式共识算法
大家经常看到各种分布式工具的架构图中都有个zookeeper(比如hdfs、Hbase、kafka)，然后它们的架构说明里都会说zk承担保存元数据和协调工作。这里的协调工作中的一个核心任务就是指选举(就是在主从架构里，通过它选择Master，master挂了就再选一个，保证高可用)，那问题来了，为什么一定要是zk，换成关系数据库可不可以？比如要选举时大家都往数据库插入一条数据,谁成功谁当leader
2022-11-05 18:28:59
459
原创 分布式系统原理-副本与一致性
因为可靠性、吞吐量、低延时方面的需求，我们为数据设置了一些副本，即将一份数据的多个拷贝存放到不同地方。如果多个副本同时提供读服务，就引发了一致性问题。本文首先介绍了副本一致性的背景，随后对"一致性"的含义加以说明(ACID里的C、CAP里的C、以及本文的一致性他们分别是何含义)，最后引出一致性级别，并对各个一致性级别作出了详细解释。相信大家读完后会对一致性有更深的认识
2022-11-05 17:35:52
567
原创 分布式系统原理-分布式系统的麻烦
所谓分布式系统顾名思义就是利用多台计算机协同解决单台计算机所不能解决的计算、存储等问题，这个大家都明白 分布式系统解决了单机无法解决的问题，但是也引入了一些问题、或者说在建设分布式系统时，会有一些麻烦。在分布式系统里面我们得意识到这些问题的存在，否则它们可能会发生一些让你很迷惑的问题
2022-11-03 23:00:33
245
原创 从演化的角度看云原生，其实并不抽象
云原生其实是很具体的，只是由于宣传等原因，各种场合都往上蹭热点，以至于目前有点混乱，本文从架构演进的角度为你阐述云原生的真正含义
2022-02-16 23:10:47
1210
原创 微服务业务与技术特征
Microservices说起微服务，就不不提Martin Fowler 和 James Lewis 合写的文章“Microservices: a definition of this new architectural term”，这篇文章虽然不是最早提出“微服务”这个概念的，但却是真正丰富的、广为人知的和可操作的微服务指南。也就是说，这篇文章才是微服务的真正起源这篇文章里给出了微服务的定义，并列举了微服务的九个核心的业务与技术特征，我们可以以此作为微服务设计的指导性原则
2022-01-15 22:35:53
415
原创 泛型，好像没那么简单
泛型广泛用于各类框架中，日常开发、或是源码阅读时，泛型的的曝光率都很高，搞懂泛型很有必要。泛型的基础使用场景比较简单，但在复杂场景下往往并不容易理解本文首先介绍了java泛型基础概念，随后列举了泛型的一些复杂使用场景，最后介绍了spring中强大易用的泛型API，希望帮你更深入的理解泛型，也可以在日常开发工作时更好的利用泛型进行通用设计
2022-01-15 22:04:08
443
原创 撸一撸Spring Framework-IOC-实现通用功能的利器(PostProcessor机制)
撸一撸Spring Framework-IoC系列文章目录IoC概述BeanFactoryApplicationContextBeanDefinitionBeanWrapper资源管理利器(Resource与ResourceLoader)配置管理(Environment与PropertySource)不简单的泛型(ResolvableType)考虑下下面这个使用文件服务上传文件的简单程序，要把它正常运行起来，Spring要做哪些事情呢？public class Appli..
2022-01-07 22:04:36
34459
原创 撸一撸Spring Framework-IOC-配置管理(Environment与PropertySource)
Environment集成了两个关键特性，配置管理和profiles管理(本质上还是配置相关的东西)，profile：用于决定一个类是否会被装载到spring容器中，对应用来说，配置管理无疑是很重要的，包括配置的增、删、改、查，比如通过@PropertySources和@PropertySource引入properties，通过@Value将配置项注入到bean的属性中，通过environment.getPropertySources().replace方法mock系统环境变量，这都属于配置管理的范畴
2021-12-06 00:07:01
2299
原创 撸一撸Spring Framework-IoC-资源管理利器(Resource、ResourceLoader、ResourcePatternResolver)
我们经常需要读取外部资源到应用中，比如文本文件、properties文件、图片文件等。这些资源可能位于不同的位置，比如文件系统、classpath下的资源、或者远程服务器上的资源。通常，我们需要通过不同的API分别加载不同类型路径的资源，有诸多不便之处Spring提供了Resource、ResourceLoader、ResourcePatternResolver系列接口解决上述问题，API非常友好、强大
2021-12-03 23:26:23
20505
原创 撸一撸Spring Framework-IoC-ApplicationContext
从UML关系上看，ApplicationContext与BeanFactory既有继承关系、又有关联关系。很多ApplicationContext的实现中，都引用了一个DefaultListableBeanFactory对象，并将bean管理操作都委托给它。以下是从GenericApplicationContext及其父类中摘录的一段代码，主要是为了让你感受下它与DefaultListableBeanFactory的关系
2021-12-01 21:33:53
8904
原创 撸一撸Spring Framework-IoC-BeanFactory
BeanFactory是Spring IoC中最核心的接口，它承担IoC最基本的职责，即创建并管理各种类的对象。BeanFactory接口只定义了最基础的IOC容器功能，它的扩展接口众多，继承体系设计优雅，堪称经典
2021-12-01 21:28:42
9994
原创 撸一撸Spring Framework-IoC-概述
Spring Framework中最核心的模块就是IoC容器(Inversion of Control，控制反转)，其他模块如aop、aspectjs、Data Access等都在此基础上展开，我们就从IoC开始旅程IoC也称为依赖注入(DependeccyInjection,DI)，注意，这二者是替代关系，并不是网上广泛传播的、极具迷惑性的"思想和实现"的关系
2021-11-30 16:57:52
60889
原创 撸一撸Spring Framework-IoC-BeanWrapper
在BeanDefinition一文中我们说过，InstantiationStrategy实例化出的bean只是一个半成品，Spring将半成品的bean交给BeanWrapper，让其负责bean的属性填充工作通过xml定义bean时，不论bean的属性是什么类型，xml中只能使用字符串字面量来对属性赋值，BeanWrapper首先要将字符串字面量转换为bean属性实际对应的类型，然后通过反射的方式给bean赋值。BeanWrapper的继承结构如下：PropertyEditor：Pro.
2021-11-29 00:10:59
5519
原创 撸一撸Spring Framework-IoC-BeanDefinition
BeanFactory会从配置元信息中加载beanDefinition，并将其注册到BeanDefinitionRegistry中，之后创建、管理bean的工作，都要依赖于beanDefinition。容器启动过程中加载beanDefinition，注册beanDefinition，从容器获取bean时(getBean)，容器如何使用beanDefinition完成bean的创建工作
2021-11-26 21:53:58
9971
原创 gson自定义枚举类型序列化反序列化
基于gson，自定义枚举类型序列化反序列化，实际效果如下：实体类:OrderDO:{orderNo="202109050001",status=StatusEnum.PENDING}<-->json串:{"orderNo":"202109050001","status":{"value":2,"desc":"处理中"}}需求背景：将枚举元素序列化为带有值和说明(value/desc)的json串(json接收方就不需要自己翻译了)，反序列化则基于值(value)进行匹配问题：由于...
2021-10-26 23:56:49
1954
原创 netty常用channelOption说明
本文通过rocketMq源码说明netty中常见channelOption的含义和用法先看服务端SO_BACKLOG：用于指定服务端连接队列长度，当服务器连接处理线程全忙时，已完成三次握手的请求会被临时存放在连接队列中等待被accept，队列满后会拒绝新收到的连接请求如不设置，该值默认为200左右，对于连接数不太多的场景，默认值就够了，像常见RPC框架的服务端(如dubbo)就没有设置，RocketMq需要支持更高频的连接请求，所以使用了推荐值1024SO_REUSEADDR：TCP.
2021-02-19 11:55:16
2610
原创 如何在团队开展codeReview
主题：如何在团队开展codeReview背景说明团队规模在扩大，代码量在不断增长，对代码质量的控制势在必行，codeReview得搞起来，这道理大家都懂，只不过有人重视，有人无所谓，还有人开始的轰轰烈烈，最终却虎头蛇尾、流于形式这其中自然是有诸多难处，但本质上还是取决于你对codeReview的价值认知，只有大家真切的从codeReview中得到好处了，认识到这个东西真的香，才有可能搞得好，不然你试试？我们团队一直在搞codeReview，但是效果不太好，属于流于形式的那种(大家都厌倦了)，
2021-02-02 11:15:41
561
2
原创 2020java面试总结
先介绍下自己，博主渣本毕业，java岗，经验接近6年本文旨在将我最近的面试经历分享给大家，我会给出每家的面试题以及面试情况，如果你也在准备面试，希望对你有参考作用，我会尽量缩小面试题的范围，提高面试题命中率本次面试情况，三周多时间，面了12家，2家没过，1家意外，其他都通过面试...
2020-08-29 23:06:30
5371
3
原创 netty在rocketMq中怎么玩的
作为一款网络编程框架，很多时候，对netty的使用具有较高的相似性，参考一款成熟的框架如何使用netty进行网络通讯，无疑会加深我们对netty的理解，帮助我们更好的将netty应用于生产实践，本文就跟大家一起分析下RocketMq中是如何使用netty的；我将从以下几个部分进行分析：1.EventLoopGroup的构造技巧与注意事项，以及一个EventLoop的高频面试题2.rocketMq的客户端服务端，分别设置了哪些ChannelOption，各自代表什么含义3.通用的会话管理机制是
2020-06-15 17:23:39
1915
原创 netty源码分析_带你搞懂ChannelHandler事件传播顺序
明确关键点：要搞懂事件在多个ChannelHandler间的传播顺序，有两个关键点需要明确1.pipeline初始化时，会创建两个哨兵Handler，即HeadContext、TailContext，我们添加的Handler处于这两个哨兵Handler之间，HeadContext可以是入站事件传播的起点，一定是出站事件传播的终点TailContext可以是出站事件传播的起点(为啥分为"可以是"与"一定是"，下文会有说明)2.事件的传播起点、方向、目标：入站事件的起点为当前Handler
2020-06-08 16:18:19
1706
3
原创 谈谈java中的异常处理规范
java中的异常分为两大块，分别是error，checkedException，uncheckedException三者设计理念不一样，体现了java设计者对不同异常情况的分类error表示发生了意料之外的错误，大部分情况下，会使得程序处于不可恢复的状态，不需要也不应该被捕获，比如OutOfMemoryError StackOverFlowError NoClassDefFoundError；这种异常发生后，只能乖乖的查问题，该改配置改配置，该改代码改代码了checkedException，un
2020-06-04 22:24:06
416
原创 关于netty的@Sharable注解含义，你可bie瞎说了
@Sharable的真实含义1.当netty尝试往多个channel中添加同一个ChannelHandlerAdapter实例时，会判断该实例类是否添加了@Sharable，没有则抛出... is not a @Sharable handler, so can't be added or removed multiple times异常 如果你用的不是单例Handler，你加不加@Sharable没有任何区别 如果你添加的是单例Handler，只要它会被添加到多个channe...
2020-05-21 18:18:40
3294
5
原创 rocketMq存储模型_indexFile
index文件的作用我们在rocketMq存储模型_概述一文中已经说过，是为了满足根据msgId以及消息key查询消息的需求，每个Broker对应一组indexFile，最大大小为40+5000000*4+5000000 * 4*20byte(为啥要这样算，下文会说明)，写完后继续写下一个上一篇文章讲述了consumequeue这类索引文件的结构及读写过程，因为consumequeue以一个单调递增的int数字为索引，所以其结构非常简单，今天要讲的另一类索引文件index(下文简称indexFile
2020-05-20 16:45:20
2626
1
原创 rocketMq存储模型_consumeQueue
在前面的文章中，已经说过RocketMq中一个topic对应了多个queue，生产者发送的消息会默认以轮询的方式发到不同的queue中，对应到文件系统中，就是一个topic下的多组consumequeue文件通过上一篇文章，你应该已经知道了，消息正文存在commitLog中，consumequeue文件中存的是索引，索引的key为消费位点，内容为消息在commitLog中的位置信息。consumequeue文件的结构非常简单，就是由30万个固定大小为20byte的的数据块组成，数据块的内容如下：
2020-05-20 15:09:55
1133
1
原创 rocketMq存储模型_概述
现代的消息队列的主要责任就是存储消息和查询消息，本质上，它们都是分布式存储系统。一个存储系统的性能好坏，最主要的决定因素就是它的存储模型。所有的存储系统中，消息队列的存储可以算是很简单的了，因为消息没有修改的需求，这就使得通过简单的追加写就可以完成消息存储，而如果数据需求修改，就会导致随机读写，并且在随机写的过程中，可能会引起磁盘内容移动，产生磁盘碎片。相对来说，如果只需要追加写，在设计上要少去大量的工作，确实是很幸福的RocketMq在设计上也是遵循了消息文件+索引文件的方式，下面分别看看有哪些类型的
2020-05-20 13:21:01
1023
原创 简单明了，说说ThreadLocal内存泄漏
本文要讨论的话题是，ThreadLocal内存泄漏问题，首先，明确下我们的讨论范围，先看一个简单的使用ThreadLocal的例子：注意：存在内存泄漏风险的是我标红的new String("我是大对象")在调用完testSetGet()方法后后，内存中的引用关系如下图(实线表示强引用，虚线表示弱引用)其中new ThreadLocal对象被两个引用指向1.我们自己使用的threadLocal引用，是一个强引用2.Entry.key引用(Thread对应的ThreadLoc..
2020-05-14 10:55:58
270
原创 read write、mmap、directBuffer、sendfile傻傻分不清楚?
当讨论到文件数据、网络数据的读写时，我们可以看到有多种方案，read write、mmap、directBuffer、sendfile这些大家都多多少少看到过，本文旨在讲述但这几种方案的原理，并做出对比pageCache以及DMA名词解释：由于后续内容多次涉及到pageCache以及DMA，这里先做下名词解释pageCache: 操作系统会为每个文件单独维护一个pageCache，其本质是内核中的一段内存，用户进程对于文件的大多数读写操作会直接作用到pageCache上，相当于...
2020-05-11 12:50:37
1027
原创 RocketMq消费失败处理逻辑
rocketMq消费者消费一条消息后，需要回复broker消息的消费状态，consume_success表示消费成功，reconsume_later表示稍后重新消费，如果消费者消费失败，应该返回一个reconsume_later，本文只讨论返回reconsume_later的情况我们以topic=topic_1,groupId=CID_1为例，讲述该消费者消费一条消息，并返回reconsu...
2020-05-07 20:53:38
4355
原创 信号量与管程实现生产者消费者模型
生产者消费者模式是实际应用中常见的场景，一个或多个生产者线程往缓冲区添加数据，一个或多个消费者线程从缓冲区取数据，有这样几个正确性要求：1.缓冲区是共享变量，一般由数组或者链表实现，是线程不安全的，同一时刻，只能有一个线程操作缓冲区(要求互斥)；2.当发现缓冲区满后，生产者必须等待消费者(要求同步)；3.缓冲区空后，消费者必须等待生产者(要求同步)基于信号量解决这个模型，设计思路如...
2020-04-10 11:15:52
354
原创 光有lock可不够，信号量与管程原理
实际场景中，光有锁和互斥是不够的，还需要一些复杂的同步机制，比如读写锁(多个读操作可以同时进行)，比如生产者消费者模型(生产者消费者需要一定的同步机制)，在这种情况下，我们只使用锁机制就不够了，需要更高层的同步互斥的语义来实现两个名词解释，有助于接下来的理解：临界区(critical section)：一段需要读写共享资源的代码互斥(Mutual exclusion):一个线程进入临...
2020-04-10 09:41:22
226
原创 lock是如何实现的，凭啥你lock后我就得等
多线程并发访问共享资源的现象称为Race condition(竞态条件)，由于无法确定CPU调度指令的顺序，当出现竞态条件时，就会存在结果的不确定性(就是我们常说的并发安全问题)，以及不可重现性的情况(安全问题也是偶发的，往往不容易复现，所以出现问题时，很难排查原因)举个获取进程ID的例子:(如果你对并发问题如何发生的比较清楚,可以跳过这一段,不影响下面的理解)当前next_pid=10...
2020-04-08 16:33:47
363
原创 深入理解中断，异常，系统调用
应用程序的运行过程中，往往会需要外部设备的干预，比如键盘敲击输入文字、鼠标点击确认按钮，并且应用程序自己可能需要一些系统服务，比如文件读写、网络通讯，另外，在运行过程中，可能还会产生一些意料之外的异常，不论是主动调起还是被动触发，都会产生一个CPU信号，这些信号分为三类，中断/异常/系统调用，信号发出后，CPU都会交给操作系统进行处理。那么三者的区别是什么呢？下面从来源、触发时机与处理方式、处...
2020-04-07 18:05:55
4146
2
原创 进程与线程的比较真的有必要吗
在没有线程的时代，一个进程内的所有动作就只能依次执行，如果有并发执行需求，就得用多进程，既然多进程可以搞定，为啥操作系统又引入了线程呢？大家都知道，因为线程更轻量，那线程到底轻在哪里？我们前面说过，进程开启后，操作系统会为其维护一个进程控制块PCB，同样的，线程开启后，会为其维护一个线程控制块TCB，这两个控制块的大小决定了它们体积上的轻重进程/线程作为CPU调度单元，都包含操作系统对其进...
2020-04-06 10:05:22
328
原创 深入理解上下文切换
对于CPU来说，它只知道取指令，执行指令，然后执行下一条指令，他可不关心当前执行的指令是从哪个进程来的，这是上面的操作系统需要关心的。由于程序总归免不了读写内存，读写磁盘，或者网络交互，这些动作比CPU的速度慢了很多个数量级，为了不让cpu忙等这些操作，就得想办法让多个程序"同时"运行，a程序执行io读写时把cpu交给b程序，b程序发送网络包时再把cpu让给c程序，尽力提高CPU的使用率，操作系统...
2020-04-04 20:55:55
1023
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人