码农架构

在访问系统某个或者某类接口后进行一系列权限校验，但在后续接口中我们想让访问权限一直授权下去改如何处理呢？总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。

在针对文件处理当网络环境不好，出现上传失败的时候，可以对失败的 Part 进行独立的重试，而不需要重新上传其他的 Part；中途暂停之后，可以从上次上传完成的 Part 的位置继续上传。或者要上传到 OSS 的本地文件很大的时候，可以并行上传多个 Part 以加快上传；再或者面对一些文件比较大时，我们需要对大文件进行切割分批上传完后再合并处理。

当我们的文件特别大的时候，上传是不是需要很长的时间啊，这么长时间的长连接，如果网络波动了呢？中间网络断开了呢？在这么长时间的过程中如果出现不稳定的情况，本次上传的所有内容就全部失败了，又要重新上传。分片上传、断点续传，这两个名词对于做过或者熟悉文件上传的朋友来说应该不会陌生，总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。

跨域资源共享(cors)可以放宽浏览器的同源策略，可以通过浏览器让不同的网站和不同的服务器之间通信。同源策略同源策略在浏览器安全中是一种非常重要的概念，大量的客户端脚本支持同源策略，比如JavaScript。同源策略允许运行在页面的脚本可以无限制的访问同一个网站（同源）中其他脚本的任何方法和属性。当不同网站页面（非同源）的脚本试图去互相访问的时候，大多数的方法和属性都是被禁止的。这个机制对于现代web应用是非常重要的，因为他们广泛的依赖http cookie来维护用户权限，服务器端会根.

导读：在微服务的架构下，系统会根据业务拆分为多个服务，各自负责单一的职责，在这样的架构下，我们需要确保各api的安全性，也就是说服务不是开放的，而是需要授权才可访问的，避免接口被不合法的请求所访问。但是在在微服务集群中服务之间暴力的接口，或者对于第三方开放的接口如果不做及安全和认证，后果可想而知。阅读下文之前思考几个问题：如何在restTemplate远程调用请求增加添加统一认证？ 服务认证如何规范加密和解密？ 远程调用统一什么协议比较合适？如下图，三个服务注册到同一个注册中心.

记得最开始的时候在设计接口的时候规范还没有那么多，因为前后端还没分离。不管是前端还是后端都是一个人开发，为了追求"效率"。所谓的接口规范百花齐放，各有各自的一套。后来前后端分离，哪些为了追求"效率"而写的代码，重构起来的代码也是头疼。所以到了现在已经基本固定基本的机构体系，针对业务得不同还可以垂直拓展。如何构建这几个部分每个公司要求都不同，没有什么“一定是最好的”标准，但一个优秀的后端接口和一个糟糕的后端接口对比起来差异还是蛮大的，其中最重要的关键点就是看是否规范!在设计接口时，有很多因素要考虑

导读：对于异步方法调用，从Spring3开始提供了@Async注解，该注解可以被标在方法上，以便异步地调用该方法。调用者将在调用时立即返回，方法的实际执行将提交给Spring TaskExecutor的任务中，由指定的线程池中的线程执行。...

ConcurrentHashmap在jdk1.7中是采用Segment + HashEntry + ReentrantLock的方式进行实现的，而1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现 JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点） JDK1.8版本的数据结构变得更加简单，使得操作也更加清

消息在通过 send() 方法发往 broker 的过程中，有可能需要经过拦截（Interceptor）、序列化器（Serializer）和分区器（Partitioner）的一系列作用之后才能被真正地发往 broker。拦截器一般不是必需的，而序列化器是必需的。消息经过序列化之后就需要确定它发往的分区，如果消息 ProducerRecord 中指定了 partition 字段，那么就不需要分区器的作用，因为 partition 代表的就是所要发往的分区号。如果消息 ProducerRecord 中没有指

我们今天讲另外一种特殊的树，“堆”（Heap）。堆这种数据结构的应用场景非常多，最经典的莫过于堆排序了。堆排序是一种原地的、时间复杂度为 O(nlogn) 的排序算法。前面我们学过快速排序，平均情况下，它的时间复杂度为 O(nlogn)。尽管这两种排序算法的时间复杂度都是 O(nlogn)，甚至堆排序比快速排序的时间复杂度还要稳定，但是，在实际的软件开发中，快速排序的性能要比堆排序好，这是为什么呢？现在，你可能还无法回答，甚至对问题本身还有点疑惑。没关系，带着这个问题，我们来学习今天的内容。等你学完

我在之前两讲介绍了Java集合框架的典型容器类，它们绝大部分都不是线程安全的，仅有的线程安全实现，比如Vector、Stack，在性能方面也远不尽如人意。幸好Java语言提供了并发包(java.util.concurrent)，为高度并发需求提供了更加全面的工具支持。今天我要问你的问题是，如何保证容器是线程安全的？ConcurrentHashMap如何实现高效地线程安全？典型回答Java提供了不同层面的线程安全支持。在传统集合框架内部，除了Hashtable等同步容器，还提供了所谓的同步包装器(

编程语言通常有各种不同的分类角度，动态类型和静态类型就是其中一种分类角度，简单区分就是语言类型信息是在运行时检查，还是编译期检查。与其近似的还有一个对比，就是所谓强类型和弱类型，就是不同类型变量赋值时，是否需要显式地（强制）进行类型转换。那么，如何分类Java语言呢？通常认为，Java是静态的强类型语言，但是因为提供了类似反射等机制，也具备了部分动态类型语言的能力。言归正传，今天我要问你的问题是，谈谈Java反射机制，动态代理是基于什么原理；典型回答反射机制是Java语言提供的一种基础功

今天我要问你的问题是，强引用、软引用、弱引用、幻象引用有什么区别？具体使用场景是什么？典型回答不同的引用类型，主要体现的是对象不同的可达性(reachable)状态和对垃圾收集的影响。所谓强引用(“Strong” Reference)，就是我们最常见的普通对象引用，只要还有强引用指向一个对象，就能表明对象还''活着”，垃圾收集器不会碰这种对象。对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应(强)引用赋值为null，就是可以被垃圾收集的了，当然具体回收时机还是要

Java 语言有很多看起来很相似，但是用途却完全不同的语言要素，这些内容往往容易成为面试官考察你知识掌握程度的切入点。今天，我要问你的是一个经典的Java基础题目，谈谈final、finally、finalize有什么不同？典型回答final可以用来修饰类、方法、变量，分别有不同的意义，final修饰的class代表不可以继承扩展，final的变量是不可以修改的，而final的方法也是不可以重写的（override）。finally则是Java保证重点代码一定要被执行的一种机制。我们可以使用

世界上存在永远不会出错的程序吗？也许这只会出现在程序员的梦中。随着编程语言和软件的诞生，异常情况就如影随形地纠缠着我们，只有正确处理好意外情况，才能保证程序的可靠性。Java 语言在设计之初就提供了相对完善的异常处理机制，这也是 Java 得以大行其道的原因之一，因为这种机制大大降低了编写和维护可靠程序的门槛。如今，异常处理机制已经成为现代编程语言的标配。今天我要问你的问题是，请对比Exception和Error，另外，运行时异常与一般异常有什么区别？典型回答Exception 和 Erro

导读：当我们构建一个 Spring 应用的时候，有时我们想在满足指定条件的时候才将某个 bean 加载到应用上下文中， Spring 4提供了一个更通用的基于条件的Bean的创建方式，即使用@Conditional注解，我们可以通过 @Conditional 注解来实现这类操作。@Conditional 元注解源码Conditional 接口源码我们看到 @Conditional 注解接收的参数是 extends Condition 接口的泛型类，也就是说，我们要使用 @Condit.

前面提到过Bean的初始化方式，在Bean 的配置元信息时候我们知道Bean的元信息配置中有lazy-init 延迟初始化属性配置，延迟初始化Spring Bean 还有Java 注解API的方式实现案例分析这里已Java 注解方式案例讲解描述@Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR,ElementType.PARAMETER,ElementType.FIELD})@Retention...

对于Spring Bean 的初始化归纳了下，主要可以归纳一下三种方式 @PostConstruct 标注方法 自定义初始化方法 实现 initializingBean 接口的afterPropertiesSet()方法 对JDK比较敏感的朋友应该知道@PostConstruct这种标注方法。是从JDK1.6开始引入的@Documented@Retention(RUNTIME)@Target(METHOD)public@interfacePostConst...

Spring 是如何将BeanDefinition注册到容器，到底我们有多少种方法来操作？本篇主要围绕这两个议题通过不同的维度来进行讨论，下面是我主要罗列了几种不同的实现方案 XML 配置 Java 注解配置元信息 Java API 配置元信息 看过Spring 源码的朋友应该注意到这里还有一种配置方式就是关于Properties文件的一个配置方法，这里不做展开后续再做介绍简要说明第一种方式：我们可以看出一个特点是我们的Bean的名称是通过XML元素内属性...

上一篇文章中已介绍了Bean 的定义，什么是BeanDefinition？下面主要源码结合模式分析BeanDefinition元信息「Bean的配置元信息」BeanDefinition元信息配置上面一表格形式概括说明BeanDefinition元信息配置，不是所有的属性配置都是必须的，但是前面几个参数属性是必须的附加补充说明 Bean 的作用域 （比如：我们常用的singleton、prototype、request等）作用域类型如下图所示，后续会针对Scope做详细讲解 .

上一周主要是针对Spring IoC 容器的概述，包括Spring IoC 依赖查找、依赖注入、依赖来源、配置元信息、容器、应用上下文以及Spring IoC 容器生命周期进行主要分析与概述接下来的部分进入Spring Bean 的基础部分、我主要分析罗列了主要内容：定义Spring Bean、BeanDefinition 元信息、命名Spring Bean、Spring Bean 的别名、注册Spring Bean、实例化Spring Bean、初始化Spring Bean、延迟初始化 Spri.

Spring Framework专注于 Spring Framework 的核心部分，从特性简介入手，结合官方文档，在实战演练的基础上加深理解。每个章节中都会加入一些比较经典的面试题，帮助解决求职的燃眉之急。通过讲解编程模型、设计思想以及技术规范，站在哲学的高度，分析和猜想Spring 的实现可能，并结合具体源码实现，不断地进行思维和实战训练，最终达到掌握特性、理解原理，学会学习的终极目的Spring 核心编程思想- IoC 容器概述Spring 核心编程思想...

Spring 核心编程思想：使用Spring IoC容器：选BeanFactory还是ApplicationContext？

Spring IoC 中依赖注入、依赖查找以及依赖来源的管理，这些内容其实都逃不过一个话题，那就是注入和配置到底是从哪里来的？我们能不能通过配置的行为去影响容器的行为？上诉简要归纳以外Spring IoC 配置元信息的额外提醒 第一/ Bean 的定义其实还有一种方式这里没有罗列出来，那就是通过Groovy的方式进行DSL配置，感兴趣的码友可以了解下 第二/ 配置元信息一个是分为自己的Bean，这个Bean通常是业务需要感知的，IoC 容器主要对IoC容器做一个控制，这个通常说是非核

Spring 容器最基本最基本的接口就是BeanFactory。BeanFactory负责配置，创建、配置Bean，其中有一个子接口ApplicationContext，也被称为Spring上下文。容器同时还管理这Bean和Bean之间的依赖关系Spring IoC容器的实现，从根源上是BeanFactory，但是真正作为一个可以独立使用的IoC容器的还是DefaultListableBeanFactory因此可以说DefaultListableBeanFactory是整个Spring IoC的始祖

我们都知道IoC的实现大致分为两种主要实现，依赖查找和依赖注入，我们都知道Spring IoC 依赖查找可以通过名称或者ID查找，那么名称和ID在一个上下文里面必须是唯一的，那么这里涉及到一个问题-Spring应用里面是不是可以拥有多个上下文「答案是肯定的」后续会详细说明首先我们先看下BeanFactory提供的方法依赖查找可以罗列出下面的几种方式是下面主要对Spring IoC 的依赖查找简单案例源码地址：https://gitee.com/icloud-iot/thinking.

Spring为什么在不同版本会有不同的支持，其实就是为了寻求最大的公约数，比如说尽可能迎合更多的版本，所Spring的支持对Java的支持就是比较靠前的，但是对版本的要求是靠后的，那就是因为在升级版本的时候大家可能不会把JDK不断低往高版本升级，从稳定性或者说从易用性的角度来讲这是可取的这里简单介绍从Java 5到 Java 10的分布变迁，主要说明Java5之后的一些变化Java52004年 Java 5 也正是Spring Framework 发布年代，Spring 在支持的的时候只需.

Spring的模块化设计和Java 9 的模块化设计不是对等的，不过Spring 的模块化确实可以运用到Java 9 的模块化里面去 ，那是为什么呢，那是因为在Spring 的某个版本开始，它将它的模块划分为更细粒的Jar 包，这些Jar包可以按需应用分配的方式来依次依赖，比如它的核心模块Spring-core，或者Spring-JDBC或者Spring-context这些模块，按照完全统计目前已经有了大概有20多个模块Spring Framework 中这些模块也是各司其职，然后各取所需的状.

想必不少资深Java开发的码友都对Spring各个版本引入了哪些新特性都有所了解，本篇文章主要讲述Spring 版本与Java 版本之间的关系，问题的关键就是在我们任何一个软件实施中，我们会用到具体一个版本，所以你要搞清楚这个版本对Java支持的情况，尤其是对Java EE 支持情况，对Spring 的拓展以及深度的实践从Spring1. 到Spring5.x ，这里做下简单说为神马是1.x ，其实Spring的版本分为三个部分 第一部分就是主版本，就是我们看到的1～5 第二部分就是

针对Redis的话题估计有些读者已经开始反感了，昨天还是有一些读者困惑，这就具体讲述下Redis持久化方式-RDB的实现方式~触发时机手动触发: save: 阻塞当前 Redis 服务器, 直到 RDB 过程完成为止, 对于内存比较大的实例会造成长时间阻塞, 线上环境不建议使用 bgsave: Redis 进程执行 fork 操作创建子进程, RDB 持久化过程由子进程负责, 完成后自动结束。阻塞只发生在 fork 阶段, 一般时间很短 自动触发 RDB 的持久化机制, .

仅从设计优化、服务拆分、自动扩容等方面进行优化，有时候并不能完全解决问题。比如，有时流量增长过快，扩容流程还来不及完成，服务器可能就已经抗不住了既然突发流量我们没法预测，业务上也不可能不依赖任何外部服务和资源，那么有什么办法能尽量避免，或者降低出现这些问题时对核心业务的影响呢？流量控制01.流控常用的算法目前业内常用的流控方法有两种：漏桶算法和令牌桶算法 漏桶算法 “漏桶算法”的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。“漏桶算法”在实现上文如其名：它模拟的是一个漏

1.Redis 是一个基于内存的高性能key-value数据库。2.Redis相比memcached有哪些优势：memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型 redis的速度比memcached快很多 redis可以持久化其数据3.Redis是单线程redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销4.Reids常用5种数据类型string，list，set，sorted set，hash6.Reids6种淘

实际上，一旦多个实例组成了哨兵集群，即使有哨兵实例出现故障挂掉了，其他哨兵还能继续协作完成主从库切换的工作，包括判定主库是不是处于下线状态，选择新主库，以及通知从库和客户端。基于 pub/sub 机制的哨兵集群组成哨兵之间的相互发现哨兵实例之间可以相互发现，要归功于Redis提供的pub/sub机制，也就是发布/订阅机制。 哨兵将自己的连接信息 (ip, port) 发布到主库上, 其它哨兵订阅 自己编写的应用程序也可以通过 Redis 进行消息的发布和订阅 ...

你好，我是Redis，一个叫Antirez的男人把我带到了这个世界上。说起我的诞生，跟关系数据库MySQL还挺有渊源的。在我还没来到这个世界上的时候，MySQL过的很辛苦，互联网发展的越来越快，它容纳的数据也越来越多，用户请求也随之暴涨，而每一个用户请求都变成了对它的一个又一个读写操作，MySQL是苦不堪言。尤其是到“双11”、“618“这种全民购物狂欢的日子，都是MySQL受苦受难的日子。据后来MySQL告诉我说，其实有一大半的用户请求都是读操作，而且经常都是重复查询一个东西，浪费它很多时

Redis 是最常用的键值存储系统之一，常用作数据库、高速缓存和消息队列代理等。Redis 基于内存来存储数据，不过，为了保证在服务器异常时数据不丢失，很多情况下，我们要为它配置持久化，而这就可能会引发磁盘 I/O 的性能问题。今天，我就带你一起来分析一个利用 Redis 作为缓存的案例。这同样是一个基于 Python Flask 的应用程序，它提供了一个 查询缓存的接口，但接口的响应时间比较长，并不能满足线上系统的要求。案例准备本次案例还是基于 Ubuntu 18.04，同样适用于其他的 Linux

我曾遇到过这么一个需求：要用 Redis 保存 5000 万个键值对，每个键值对大约是 512B，为了能快速部署并对外提供服务，我们采用云主机来运行 Redis 实例，那么，该如何选择云主机的内存容量呢？我粗略地计算了一下，这些键值对所占的内存空间大约是 25GB（5000 万 *512B）。所以，当时，我想到的第一个方案就是：选择一台 32GB 内存的云主机来部署 Redis。因为 32GB 的内存能保存所有数据，而且还留有 7GB，可以保证系统的正常运行。同时，我还采用 RDB 对数据做持...

我们都了解Redis主从库集群模式。在这个模式下，如果从库发生故障了，客户端可以继续向主库或其他从库发送请求，进行相关的操作，但是如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。而且，如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，这在纯读的业务场景下还能被接受。但是，一旦有写操作请求了，按照主从库模式下的读写分离要求，需要由主库来完成写操作。此时，也没有实例可以来服务客户端的写操作请求了，如下图所示：无论是写服务中断，还是从库无法进行.

集群流控我们已经知道如何为应用接入限流了，但是到目前为止，这些还只是在单机应用中生效。也就是说，假如你的应用有多个实例，那么你设置了限流的规则之后，每一台应用的实例都会生效相同的流控规则，如下图所示：local-flow-in-each-server.png假设我们设置了一个流控规则，qps是10，那么就会出现如上图所示的情况，当qps大于10时，实例中的 sentinel 就开始生效了，就会将超过阈值的请求 block 掉。上图好像没什么问题，但是细想一下，我们可以发现还是会有这样的问

规则持久化的5种方式规则丢失无论是通过硬编码的方式来更新规则，还是通过接入 Sentinel Dashboard 后，在页面上操作来更新规则，都无法避免一个问题，那就是服务重新后，规则就丢失了，因为默认情况下规则是保存在内存中的。Dashboard 是通过 transport 模块来获取每个 Sentinel 客户端中的规则的，获取到的规则通过 RuleRepository 接口保存在 Dashboard 的内存中，如果在 Dashboard 页面中更改了某个规则，也会调用 transport

我们已经知道了 Sentinel 的三大功能：限流 降级 系统保护。现在让我们来了解下具体的使用方法，以限流来演示具体的步骤。引入依赖首先肯定是要先引入需要的依赖，如下所示：<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-core</artifactId> <version>x.y.z</versi.