号没留言功能，所以我建了个微信交流群来方便交流，现在需要你的加入，群里大佬贼多！目前入群满百发红包，给个一起吹比的机会把阿Sir，期待与你一起相互吹捧，共同进步。引言初版如果我们的线上服务不重要，一般来个单体的数据库DB来存储数据即可来。单体应用优点：简单，省事，方便。缺点：数据并发性，稳定性都有问题。进阶随着数据量的不断增大，一般我们要对数据进行水平切分，水平切分的规则你可以简单根据用户id或者用户IP对数据进行取模，实现路由功能。当然也可以增加Slave跟KeepAlived来实现高可用。主从+路由但问题是，如果随着业务发展，目前我们2个库的性能扛不住了，还要继续水平拆分，造出更多库咋办？你一般是如何实现丝滑扩容的呢？扩容第一版：停机扩容停机扩容简单直接暴力的方法。APP通知用户在某个时间段停机维护升级。新建若干个具有高可用的库。停止当前服务，然后写个数据迁移程序，实现把老库数据全部迁移到新库中。修改代码路由规则后重新对外提供服务。优点：简单缺点：中间停服务了，无法保证高可用。数据切换前跟切换过程中需确保无任何出错。第二版：在线双写在线双写建立好新到数据库，然后接下来用户在写原有数据库到同时也写一份数据到我们的新库中。写个数据迁移程序，实现旧库中的历史数据迁移到新库中。迁移过程中，每次插入数据时，需检测数据的更新情况。比如，如果新的表中没有当前的数据，则直接新增；如果新表有数据并没有我们要迁移的数据新的话，我们就更新为当前数据，只能允许新的数据覆盖旧的数据，推荐使用Canal这样到中间件。经过一段时间后需要校验新库跟旧库两边数据是否一样。如果检查到一样了，则直接切换即可。优点：高可用了。缺点：不够丝滑，来回挪动数据较大。第三版：丝滑般扩容目标：打算将原来到两个数据库扩容到4个。第一步：修改配置修改配置修改配置信息，注意旧库跟新库之间到映射关系。确保扩容后数据可以正确路由到服务器。Id

倍，哪些环节会遇到问题，然后你会怎么去应对？有实际场景，并且你又能给出方案选型的合理依据，效果远比空谈理论要好很多。2、对于项目中常用的各种中间件，比如缓存、消息队列、ElasticSearch

分布式锁使用Redis中的setnx操作，将幂等性的保证屏障设置在分布式锁中。如果setnx成功了说明这是第一次进行数据插入，继续执行SQL语句即可。如果setnx失败了，那说明已经执行过了。2.7

定义数据分布不平衡，某些地方特别多，某些地方又特别少，导致的在处理数据的时候，有些很快就处理完了，而有些又迟迟未能处理完，导致整体任务最终迟迟无法完成，这种现象就是数据倾斜。4.1.2

确保消息删除通过消息队列的确认消费机制来删除缓存。消息队列机制确保删除缺点也很明显：对业务线代码造成大量的侵入，引入了中间件。消息的延迟删除也会造成短暂的不一致。2.6

号没留言功能，所以我建了个微信交流群来方便交流，现在需要你的加入，群里大佬贼多！目前入群满百发红包，给个一起吹比的机会把阿Sir，期待与你一起相互吹捧，共同进步。对了，以后文章定时18:20~20:00见。1

因为申请较晚，本公众号没留言，想交流的欢迎添加私人微信，一起相互吹捧，共同进步。承接上文的操作系统，关于IO会涉及到阻塞、非阻塞、多路复用、同步、异步、BIO、NIO、AIO等几个知识点。知识点虽然不难但平常经常容易搞混，特此Mark下，与君共勉。1

访问速度访问耗时对比如上图所示，CPU访问速度是逐步变慢，所以CPU访问数据时需尽量在距离CPU近的高速缓存区访问，根据摩尔定律CPU访问速度每18个月就会翻倍，而内存的访问每18个月也就增长10%

连接，可以看到服务器结束TCP连接的时间要比客户端早一些。我们还以你跟妹子碰面交流为例，你俩彼此确认后交流几分钟后，你打算结束这个谈话，毕竟交流太久没老婆发现就凉了。你跟妹子挥手离别3.2.10

加密信息。服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。正常发送数据至此，双方已安全地协商出了同一份秘钥，

组成。组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。offset：消费者在具体消费某个

消息给你，你可以进行重试操作。发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。4.3.2

实现类简介MR任务输入文件个数各有不同，针对不同类型MR定义了一个接口跟若干实现类来读取不同的数据。input继承关系TextInputFormat默认使用类，按行读取每条数据，Key是该行数据的

对应的HLog文件中去。只有当WAL日志写入成功的时候，客户端才会被告诉提交数据成功。如果写WAL失败会告知客户端提交失败，这其实就是数据落地的过程。WAL是保存在HDFS上的持久化文件。数据到达

的地址。这样，在外界看来，这个包就是从10.10.101.105上发出来的，Docker容器对外是不可见的。外部访问容器创建容器并将容器的80端口映射到主机的80端口。当我们对主机

集群管理大数据体系下的大部分集群服务好像都通过ZooKeeper管理的，其实管理的时候主要关注的就是机器的动态上下线跟Leader选举。动态上下线：比如在zookeeper服务器端有一个znode叫

ExtensionLoader.getExtensionLoader(type.class).getExtension(name)来获取真正的实例来调用，看个官网样例。public

IOC跟AOP，这是Spring的两大核心知识点，初学者不要被IOC、AOP、Aspect、Pointcut、Advisor这些术语吓着了，这些术语都是无聊的人为了发论文硬造的。2.1

也就是ThreadLocal对象，而非整个Entry，所以线程变量中的值T对象还是在内存中存在的，所以内存泄漏的问题还没有完全解决。接着分析底层代码会发现在调用ThreadLocal.get()

signal当我们调用signal方法的时候，我们要将等待队列中的头节点移出来，让其去抢锁，如果是公平模式就要去排队了，流程如图：上面只是形象流程图，如果从代码级别看的话大致流程如下：6.2.3

值，任何比这个值大的对象都不会尝试在新生代分配，将在老年代分配内存。内存回收跟分配策略优先在Eden上分配对象，此区域垃圾回收频繁速度还快。大对象直接进入老生代。年长者(长期存活对象默认15次)跟

漏桶算法思路：把水比作是请求，漏桶比作是系统处理能力极限，水先进入到漏桶里，漏桶里的水按一定速率流出，当流出的速率小于流入的速率时，由于漏桶容量有限，后续进入的水直接溢出（拒绝请求），以此实现限流。

虽然MySQL支持表，页，行三级锁定，但MyISAM存储引擎只支持表锁。所以MyISAM的加锁相对比较开销低，但数据操作的并发性能相对就不高。但如果写操作都是尾插入，那还是可以支持一定程度的读写并发

test2表是UNION关键字之后的查询，所以被标记为UNION，test1是最主要的表，被标记为PRIMARY。而表示id=1和id=2的表union，其结果被标记为UNION

、LinkedTransferQueue、LinkedBlockingQueue等，它们的区别主要体现在存储结构上或对元素操作上的不同，但是对于take与put操作的原理，却是类似的。

在访问共享资源之前会对资源进行加锁操作，在访问完成之后进行解锁操作。加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。通俗来说就是共享资源某一时刻只能有一个线程访问，其余等待。

synchronized关键词作用在方法的前面，用来锁定方法，其实默认锁定的是this对象。

并发编程关键问题JDK天生就是多线程的，多线程大大提速了程序运行的速度，但是凡事有利就有弊，并发编程时经常会涉及到线程之间的通信跟同步问题，一般也说是可见性、原子性、有序性。线程通信线程的通信是指线程之间通过什么机制来交换信息，在编程中常用的通信机制有两个，共享内存跟消息传递。共享内存。在共享内存的并发模型中线程之间共享程序的公共数据状态，线程之前通过读写内存中的公共内存区域来进行信息的传递，典型的共享内存通信方式就是通过共享对象来进行通信。消息传递，比如在Linux系统中同步机制有管道、信号、消息队列、信号量、套接字这几种方式。在消息传递的并发模型中，线程之间是没有共享状态的，线程之间必须通过明确的发送消息来显式的进行通信，在Java中的典型通信方式就是wait()跟notify()。在C/C++中可以同时支持共享内存跟消息传递机制，Java中采用的是共享内存模型。线程同步同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。JMM现代计算机物理上的内存模型缓存了解JMM前我们先了解下现代计算机物理上的数据存储模型。随着CPU技术的发展，CPU的执行速度越来越快。而由于内存的技术并没有太大的变化，我执行一个任务一共耗时10秒，结果CPU获取数据耗时8秒，CPU计算耗时2秒，大部分时间都用来获取数据上了。怎么解决这个问题呢？就是在CPU和内存之间增加高速缓存。缓存的概念就是保存一份数据拷贝。他的特点是速度快，内存小，并且昂贵。以后程序运行获取数据就是如下的步骤了。并且随着CPU计算能力的不断提升，一层缓存就慢慢的无法满足要求了，就逐渐的衍生出多级缓存。按照数据读取顺序和与CPU结合的紧密程度，CPU缓存可以分为一级缓存（L1），二级缓存（L2），部分高端CPU还具有三级缓存（L3），每一级缓存中所储存的全部数据都是下一级缓存的一部分。这三种缓存的技术难度和制造成本是相对递减的，所以其容量也是相对递增的，性能对比如下：单核CPU只含有一套L1，L2，L3缓存；如果CPU含有多个核心，即多核CPU，则每个核心都含有一套L1（甚至和L2）缓存，而共享L3（或者和L2）缓存。缓存一致性随着计算机能力不断提升，开始支持多线程。那么问题就来了。我们分别来分析下单线程、多线程在单核CPU、多核CPU中的影响。单线程。cpu核心的缓存只被一个线程访问。缓存独占，不会出现访问冲突等问题。单核CPU多线程。进程中的多个线程会同时访问进程中的共享数据，CPU将某块内存加载到缓存后，不同线程在访问相同的物理地址的时候，都会映射到相同的缓存位置，这样即使发生线程的切换，缓存仍然不会失效。但由于任何时刻只能有一个线程在执行，因此不会出现缓存访问冲突。多核CPU，多线程。每个核都至少有一个L1

Simple队列中只能一一对应的生产消费，实际开发中生产者发消息很简单，而消费者要跟业务结合，消费者接受到消息后要处理从而会耗时。「可能会出现队列中出现消息积压」。所以如果多个消费者可以加速消费。

oldValue;}如果加锁失败了调用scanAndLockForPut，完成查找或新建节点的工作。当获取到锁后直接将该节点加入链表即可，「提升」了put操作的性能，这里涉及到自旋。大致过程：

当A进行属性注入时，会去创建B，同时B又依赖了A，所以创建B的同时又会去调用getBean(a)来获取需要的依赖，此时的getBean(a)会从缓存中获取：

文件被JVM加载到内存中，然后生成一个Class对象通过Class对象new出我们经常用到的对象。❞Java中文件获取*.class方式有三种：❝普通*.java文件编译成*class

直接干货AbstractApplicationContext的refresh()方法是spring的核心，在其中完成了容器的初始化。我们先简单看下业务Bean的声明流程：业务Bean的流程只是refresh函数中关于业务Bean创建的一个item，不过大致流程都是类似的。IOC

springcloud-consumer-dept-80和springcloud-provider-dept-8001的pom.xml和父工程下的依赖基本一样，直接看完整代码即可，不再添加重复笔记。

吾生也有涯，而知也无涯，一个IT从业人员的点滴分享。

大帆：过个锤子，三面的这个总监最后竟然问了我下我对volatile的底层原理。你妹的你么水，我就答了一些基本的可见性跟弱原子性，然后我感觉面试官不太满意啊！

，它实现原理也是内部维护了一个阻塞队列，它的核心功效就是让先执行的任务先放到结果集。当任务执行结束就把任务的执行结果加入到阻塞队列中，不同的是CompletionService是把任务执行结果的

由于user2已经声明不再接受小于3的提案，所以拒绝user1的提案。由于User3已经声明不再接受小于2的提案，所以同样拒绝User1的提案。User1提议被多数人拒绝，再次`进入阶段1**.

红黑树。HashMap的主干是一个Node数组。Node是HashMap的基本组成单元，每一个Node包含一个key-value键值对。HashMap的时间复杂读几乎可以接近O(1)(如果出现了

('values');当我们需要一个ID的时候，向表中插入一条记录返回主键ID，但这种方式有一个比较致命的缺点，访问量激增时MySQL本身就是系统的瓶颈，用它来实现分布式服务风险比较大，不推荐！

上述注意点在代码中的体现为service层获取连接开启事务的要跟dao层的连接一致，并且在当前线程只能操作自己的连接。寻常思路传参：将service层connection对象直接传递到dao层，加锁

对旧table数据重定位到新table的时候我们知道是会行程环的，环产生的核心函数transfer如下，其中重点关注部分以标出。