1、死信、延迟、重试队列
DLQ(Deal Letter Queue)，死信队列。当一个消息在队列中变成死信之后，他能被重新发送到 DLQ 中，与 DLQ 绑定到队列就是死信队列。
什么情况下需要死信队列
- 消息被拒绝
- 消息过期
- 队列达到最大长度
生产者生产一条消息，存储到普通队列中；设置队列的过期时间为 10 秒，在 10 秒内没有消费者消费消息，那么判定消息过期；此时如果设置了死信队列，过期消息被丢给死信队列交换机，然后被存储在死信队列中。
延迟队列
顾名思义就是延迟执行消息，比如我们可以增加一个队列并设置其超时时间为 10 秒并且不设置任何消费者，等到消息超时，我们可以将消息放入死信队列，让消费者监听这个死信队列就达到了延迟队列的效果。
重试队列
重试的消息在延迟的某个时间点（业务可设置）后，再次投递给消费者。而如果一直这样重复消费都持续失败到一定次数，就会投递到死信队列，最后需要进行人工干预。
2、双亲委派模型
Java类加载器(ClassLoader)
双亲委派模式要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器，请注意双亲委派模式中的父子关系并非通常所说的类继承关系，而是采用组合关系来复用父类加载器的相关代码，类加载器间的关系如下：
双亲委派模式优势
- 采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
- 其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。
- 可能你会想，如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢？该类并不存在java.lang中，经过双亲委托模式，传递到启动类加载器中，由于父类加载器路径下并没有该类，所以不会加载，将反向委托给子类加载器加载，最终会通过系统类加载器加载该类。但是这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出如下异常
假死脑裂
在一个大的集群中往往会有一个master的存在，在长期运行过程中不可避免会出现宕机等等的问题导致master不可用，在出现这样的情况以后往往会对系统产生很大的影响，所以一般的分布式集群中的master都采用了高可用的解决方案来避免这样的情况发生。
master-slaver方式，存在一个master的节点，平时对外服务，同时有一个slaver节点来监控master，监控的同时有某种方式来进行数据同步。假如现在master挂掉了，slaver能很快获知并且迅速切换为新的master。但是在这种方式中，监控切换是一个很大的难题，但是现在Zookeeper的watch和分布式锁机制能比较好的解决这个问题。虽然Zookeeper很好的解决了这个问题，但是它的使用也存在其他的问题，比如脑裂。
导致脑裂的一个根源问题就是假死。
什么叫假死呢？
有一个很重要的问题，就是到底是根据一个什么样的情况来判断一个节点死亡down掉了。
在分布式系统中这些都是有监控者来判断的，但是监控者也很难判定其他的节点的状态，唯一一个可靠的途径就是心跳，包括Zookeeper也是使用心跳来判断客户端是否仍然活着。
使用ZooKeeper来做master HA基本都是同样的方式，每个节点都尝试注册一个象征master的临时节点其他没有注册成功的则成为slaver，并且通过watch机制监控着master所创建的临时节点，Zookeeper通过内部心跳机制来确定master的状态，一旦master出现意外Zookeeper能很快获悉并且通知其他的slaver，其他slaver在之后作出相关反应。这样就完成了一个切换。这种模式也是比较通用的模式，基本大部分都是这样实现的，但是这里面有个很严重的问题，如果注意不到会导致短暂的时间内系统出现脑裂，因为心跳出现超时可能是master挂了，但是也可能是master，zookeeper之间网络出现了问题，也同样可能导致。这种情况就是假死，master并未死掉，但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换，这样slaver中就有一个成为了master，但是原本的master并未死掉，这时候client也获得master切换的消息，但是仍然会有一些延时，zookeeper需要通讯需要一个一个通知，这时候整个系统就很混乱可能有一部分client已经通知到了连接到新的master上去了，有的client仍然连接在老的master上如果同时有两个client需要对master的同一个数据更新并且刚好这两个client此刻分别连接在新老的master上，就会出现很严重问题。
是什么原因导致这样情况的出现呢？
主要原因是Zookeeper集群和Zookeeper client判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于client发现那就会出现上面的情况。同时，在发现并切换后通知各个客户端也有先后快慢。一般出现这种情况的几率很小，需要master与Zookeeper集群网络断开但是与其他集群角色之间的网络没有问题，还要满足上面那些情况，但是一旦出现就会引起很严重的后果，数据不一致。
如何避免？
在slaver切换的时候不在检查到老的master出现问题后马上切换，而是在休眠一段足够的时间，确保老的master已经获知变更并且做了相关的shutdown清理工作了然后再注册成为master就能避免这类问题了，这个休眠时间一般定义为与Zookeeper定义的超时时间就够了，但是这段时间内系统不可用了。
4、MySQL 优化
- 表关联查询时务必遵循 小表驱动大表 原则；
- 使用查询语句 where 条件时，不允许出现 函数，否则索引会失效；
- 使用单表查询时，相同字段尽量不要用 OR，因为可能导致索引失效，可以使用 UNION 替代；
- LIKE 语句不允许使用 % 开头，否则索引会失效；
- 组合索引一定要遵循 从左到右 原则，否则索引会失效；
- 索引不宜过多，根据实际情况决定，尽量不要超过 10 个；
- 每张表都必须有 主键，达到加快查询效率的目的；
- 分表，可根据业务字段尾数中的个位或十位或百位（以此类推）做表名达到分表的目的；
- 分库，可根据业务字段尾数中的个位或十位或百位（以此类推）做库名达到分库的目的；
- 表分区，类似于硬盘分区，可以将某个时间段的数据放在分区里，加快查询速度，可以配合 分表 + 表分区 结合使用；
5、jdk8新特性
1.Lambda表达式
2.新的日期API
3.引入Optional
4.使用Base64
5.接口的默认方法和静态方法
6.新增方法引用格式
7.新增Stream类
8.注解相关的改变
9.支持并行（parallel）数组
10.对并发类（Concurrency）的扩展。
一、Lambda表达式
Lambda 表达式也可称为闭包，是推动 Java 8 发布的最重要新特性。lambda表达式本质上是一个匿名方法。Lambda允许把函数作为一个方法的参数（函数作为参数传递进方法中）或者把代码看成数据。使用 Lambda 表达式可以使代码变的更加简洁紧凑。在最简单的形式中，一个lambda可以由：用逗号分隔的参数列表、–>符号、函数体三部分表示，在某些情况下lambda的函数体会更加复杂，这时可以把函数体放到在一对花括号中，就像在Java中定义普通函数一样。Lambda可以引用类的成员变量与局部变量（如果这些变量不是final的话，它们会被隐含的转为final，这样效率更高）。Lambda可能会返回一个值。返回值的类型也是由编译器推测出来的。如果lambda的函数体只有一行的话，那么没有必要显式使用return语句。
如何使现有的函数友好地支持lambda。最终采取的方法是：增加函数式接口的概念。函数式接口就是接口里面必须有且只有一个抽象方法的普通接口，像这样的接口可以被隐式转换为lambda表达式成为函数式接口。 在可以使用lambda表达式的地方，方法声明时必须包含一个函数式的接口。 任何函数式接口都可以使用lambda表达式替换，例如：ActionListener、Comparator、Runnable。
函数式接口是容易出错的：如有某个人在接口定义中增加了另一个方法，这时，这个接口就不再是函数式的了，并且编译过程也会失败。为了克服函数式接口的这种脆弱性并且能够明确声明接口作为函数式接口的意图，Java 8增加了一种特殊的注解@FunctionalInterface，但是默认方法与静态方法并不影响函数式接口的契约，可以任意使用。
使用lambda表达式替换匿名类，而实现Runnable接口是匿名类的最好示例。通过() -> {}代码块替代了整个匿名类。
java 8之前：
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("Before Java8, too much code for too little to do");
}
}).start();
Java 8方式：
new Thread( () -> System.out.println("In Java8, Lambda expression rocks !!") ).start();
Lambda 表达式免去了使用匿名方法的麻烦，并且给予Java简单但是强大的函数化的编程能力。
二、新的日期API
Java 8通过发布新的Date-Time API (JSR 310)来进一步加强对日期与时间的处理。在旧版的 Java 中，日期时间 API 存在诸多问题，比如：
1.非线程安全 − java.util.Date 是非线程安全的，所有的日期类都是可变的，这是Java日期类最大的问题之一。
2.设计很差 − Java的日期/时间类的定义并不一致，在java.util和java.sql的包中都有日期类，此外用于格式化和解析的类在java.text包中定义。java.util.Date同时包含日期和时间，而java.sql.Date仅包含日期，将其纳入java.sql包并不合理。另外这两个类都有相同的名字，这本身就是一个非常糟糕的设计。
3.时区处理麻烦 − 日期类并不提供国际化，没有时区支持，因此Java引入了java.util.Calendar和java.util.TimeZone类，但他们同样存在上述所有的问题。
Java 8 在 java.time 包下提供了很多新的 API。以下为两个比较重要的 API：
1.Local(本地) − 简化了日期时间的处理，没有时区的问题。
2.Zoned(时区) − 通过制定的时区处理日期时间。
新的java.time包涵盖了所有处理日期，时间，日期/时间，时区，时刻（instants），过程（during）与时钟（clock）的操作。
三、Optional
Optional类实际上是个容器：它可以保存类型T的值，或者仅仅保存null。Optional 类的引入很好的解决空指针异常。Optional提供很多有用的方法，这样我们就不用显式进行空值检测。尽量避免在程序中直接调用Optional对象的get()和isPresent()方法，避免使用Optional类型声明实体类的属性。
（1）Optional.of(T t) : 创建一个 Optional 实例
（2）Optional.empty() : 创建一个空的 Optional 实例
（3）Optional.ofNullable(T t):若 t 不为 null,创建 Optional 实例,否则创建空实例
（4）isPresent() : 判断是否包含值 orElse(T t) : 如果调用对象包含值，返回该值，否则返回t
（5）orElseGet(Supplier s) :如果调用对象包含值，返回该值，否则返回 s 获取的值
（6）map(Function f): 如果有值对其处理，并返回处理后的Optional，否则返回Optional.empty()
（7）flatMap(Function mapper):与 map 类似，要求返回值必须是Optional
1.创建optional对象，一般用ofNullable()而不用of()：
（1）empty() ：用于创建一个没有值的Optional对象：Optional<String> emptyOpt = Optional.empty();
（2）of() ：使用一个非空的值创建Optional对象：Optional<String> notNullOpt = Optional.of(str);
（3）ofNullable() ：接收一个可以为null的值：Optional<String> nullableOpt = Optional.ofNullable(str);
2.判断Null：
（1）isPresent()：如果创建的对象实例为非空值的话，isPresent()返回true，调用get()方法会返回该对象，如果没有值，调用isPresent()方法会返回false，调用get()方法抛出NullPointerException异常。
3.获取对象：
（1）get()
4.使用map提取对象的值，如果我们要获取User对象中的roleId属性值，常见的方式是先判断是否为null然后直接获取，但使用Optional中提供的map()方法可以以更简单的方式实现
5.使用orElse方法设置默认值，Optional类还包含其他方法用于获取值，这些方法分别为：
（1）orElse()：如果有值就返回，否则返回一个给定的值作为默认值；
（2）orElseGet()：与orElse()方法作用类似，区别在于生成默认值的方式不同。该方法接受一个Supplier<? extends T>函数式接口参数，用于生成默认值；
（3）orElseThrow()：与前面介绍的get()方法类似，当值为null时调用这两个方法都会抛出NullPointerException异常，区别在于该方法可以指定抛出的异常类型。
6.使用filter()方法过滤，filter()方法可用于判断Optional对象是否满足给定条件，一般用于条件过滤，在代码中，如果filter()方法中的Lambda表达式成立，filter()方法会返回当前Optional对象值，否则，返回一个值为空的Optional对象。：
四、Base64
Base64编码的作用 ：
由于某些系统中只能使用ASCII字符。Base64就是用来将非ASCII字符的数据转换成ASCII字符的一种方法。 Base64其实不是安全领域下的加密解密算法，而是一种编码，也就是说，它是可以被翻译回原来的样子。它并不是一种加密过程。所以base64只能算是一个编码算法，对数据内容进行编码来适合传输。虽然base64编码过后原文也变成不能看到的字符格式，但是这种方式很初级，很简单。
使用Base64编码原因 ：
1.base64是网络上最常见的用于传输8bit字节代码的编码方式之一。有时我们需要把二进制数据编码为适合放在URL中的形式。这时采用base64编码具有不可读性，即所编码的数据不会被人直接看出。
2.用于在http环境下传递较长的标识信息。
在Java 8中，Base64编码已经成为Java类库的标准，并内置了 Base64 编码的编码器和解码器。Base64工具类提供了一套静态方法获取下面三种BASE64编解码器：
基本：输出被映射到一组字符A-Za-z0-9+/，编码不添加任何行标，输出的解码仅支持A-Za-z0-9+/。
URL：输出映射到一组字符A-Za-z0-9+_，输出是URL和文件。
MIME：输出隐射到MIME友好格式。输出每行不超过76字符，并且使用'\r'并跟随'\n'作为分割。编码输出最后没有行分割。
五、接口的默认方法和静态方法
Java 8用默认方法与静态方法这两个新概念来扩展接口的声明。默认方法与抽象方法不同之处在于抽象方法必须要求实现，但是默认方法则没有这个要求，就是接口可以有实现方法，而且不需要实现类去实现其方法。我们只需在方法名前面加个default关键字即可实现默认方法。为什么要有这个特性？以前当需要修改接口的时候，需要修改全部实现该接口的类。而引进的默认方法的目的是为了解决接口的修改与现有的实现不兼容的问题。
默认方法语法格式如下：
public interface Vehicle {
default void print(){
System.out.println("我是一辆车!");
}
}
当出现这样的情况，一个类实现了多个接口，且这些接口有相同的默认方法，这种情况的解决方法：
1.是创建自己的默认方法，来覆盖重写接口的默认方法
2.可以使用 super 来调用指定接口的默认方法
Java 8 的另一个特性是接口可以声明（并且可以提供实现）静态方法。在JVM中，默认方法的实现是非常高效的，并且通过字节码指令为方法调用提供了支持。默认方法允许继续使用现有的Java接口，而同时能够保障正常的编译过程。尽管默认方法非常强大，但是在使用默认方法时我们需要小心注意一个地方：在声明一个默认方法前，请仔细思考是不是真的有必要使用默认方法，因为默认方法会带给程序歧义，并且在复杂的继承体系中容易产生编译错误。
六、方法引用
方法引用提供了非常有用的语法，可以直接引用已有Java类或对象（实例）的方法或构造器。与lambda联合使用，方法引用可以使语言的构造更紧凑简洁，减少冗余代码。
定义了4个方法的Car这个类作为例子，区分Java中支持的4种不同的方法引用。
public static class Car {
public static Car create( final Supplier< Car > supplier ) {
return supplier.get();
}
public static void collide( final Car car ) {
System.out.println( "Collided " + car.toString() );
}
public void follow( final Car another ) {
System.out.println( "Following the " + another.toString() );
}
public void repair() {
System.out.println( "Repaired " + this.toString() );
}
}
第一种方法引用是构造器引用，它的语法是Class::new，或者更一般的Class< T >::new。请注意构造器没有参数。
final Car car = Car.create( Car::new );
final List< Car > cars = Arrays.asList( car );
第二种方法引用是静态方法引用，它的语法是Class::static_method。请注意这个方法接受一个Car类型的参数
cars.forEach( Car::collide );
第三种方法引用是特定类的任意对象的方法引用，它的语法是Class::method。请注意，这个方法没有参数。
cars.forEach( Car::repair );
第四种方法引用是特定对象的方法引用，它的语法是instance::method。请注意，这个方法接受一个Car类型的参数
final Car police = Car.create( Car::new );
cars.forEach( police::follow );
七、Stream
Java 8 API添加了一个新的抽象称为流Stream把真正的函数式编程风格引入到Java中，可以让你以一种声明的方式处理数据。Stream 使用一种类似用 SQL 语句从数据库查询数据的直观方式来提供一种对 Java 集合运算和表达的高阶抽象。Stream API极大简化了集合框架的处理，这种风格将要处理的元素集合看作一种流， 流在管道中传输， 并且可以在管道的节点上进行处理， 比如筛选， 排序，聚合等。
Stream流有一些特性：
1.Stream流不是一种数据结构，不保存数据，它只是在原数据集上定义了一组操作。
2.这些操作是惰性的，即每当访问到流中的一个元素，才会在此元素上执行这一系列操作。
3.Stream不保存数据，故每个Stream流只能使用一次。
所以这边有两个概念:流、管道。元素流在管道中经过中间操作的处理，最后由最终操作得到前面处理的结果。这里有2个操作：中间操作、最终操作。
中间操作：返回结果都是Stream，故可以多个中间操作叠加。
终止操作：用于返回我们最终需要的数据，只能有一个终止操作。
使用Stream流，可以清楚地知道我们要对一个数据集做何种操作，可读性强。而且可以很轻松地获取并行化Stream流，不用自己编写多线程代码，可以更加专注于业务逻辑。默认情况下，从有序集合、生成器、迭代器产生的流或者通过调用Stream.sorted产生的流都是有序流，有序流在并行处理时会在处理完成之后恢复原顺序。无限流的存在，侧面说明了流是惰性的，即每当用到一个元素时，才会在这个元素上执行这一系列操作。
使用Stream的基本步骤：
1.创建Stream
2.转换Stream，每次转换原有Stream对象不改变，返回一个新的Stream对象（可以有多次转换）
3.对Stream进行聚合操作，获取想要的结果
一、 流的生成方法
1.Collection接口的stream()或parallelStream()方法
2.静态的Stream.of()、Stream.empty()方法
3.Arrays.stream(array, from, to)
4.静态的Stream.generate()方法生成无限流，接受一个不包含引元的函数
5.静态的Stream.iterate()方法生成无限流，接受一个种子值以及一个迭代函数
6.Pattern接口的splitAsStream(input)方法
7.静态的Files.lines(path)、Files.lines(path, charSet)方法
8.静态的Stream.concat()方法将两个流连接起来
二、 流的Intermediate方法(中间操作)
1.filter(Predicate) ：将结果为false的元素过滤掉
2.map(fun) ：转换元素的值，可以用方法引元或者lambda表达式
3.flatMap(fun) ：若元素是流，将流摊平为正常元素，再进行元素转换
4.limit(n) ：保留前n个元素
5.skip(n) ：跳过前n个元素
6.distinct() ：剔除重复元素
7.sorted() ：将Comparable元素的流排序
8.sorted(Comparator) ：将流元素按Comparator排序
9.peek(fun) ：流不变，但会把每个元素传入fun执行，可以用作调试
三、 流的Terminal方法(终结操作)
（1）约简操作
1.reduce(fun) ：从流中计算某个值，接受一个二元函数作为累积器，从前两个元素开始持续应用它，累积器的中间结果作为第一个参数，流元素作为第二个参数
2.reduce(a, fun) ：a为幺元值，作为累积器的起点
3.reduce(a, fun1, fun2) ：与二元变形类似，并发操作中，当累积器的第一个参数与第二个参数都为流元素类型时，可以对各个中间结果也应用累积器进行合并，但是当累积器的第一个参数不是流元素类型而是类型T的时候，各个中间结果也为类型T，需要fun2来将各个中间结果进行合并
（2）收集操作
1.iterator()：
2.forEach(fun)：
3.forEachOrdered(fun) ：可以应用在并行流上以保持元素顺序
4.toArray()：
5.toArray(T[] :: new) ：返回正确的元素类型
6.collect(Collector)：
7.collect(fun1, fun2, fun3) ：fun1转换流元素；fun2为累积器，将fun1的转换结果累积起来；fun3为组合器，将并行处理过程中累积器的各个结果组合起来
（3）查找与收集操作
1.max(Comparator)：返回流中最大值
2.min(Comparator)：返回流中最小值
3.count()：返回流中元素个数
4.findFirst() ：返回第一个元素
5.findAny() ：返回任意元素
6.anyMatch(Predicate) ：任意元素匹配时返回true
7.allMatch(Predicate) ：所有元素匹配时返回true
8.noneMatch(Predicate) ：没有元素匹配时返回true
八、注解相关
（1）可以进行重复注解
自从Java 5引入了注解机制，这一特性就变得非常流行并且广为使用。然而，使用注解的一个限制是相同的注解在同一位置只能声明一次，不能声明多次。Java 8打破了这条规则，引入了重复注解机制，这样相同的注解可以在同一地方声明多次。
重复注解机制本身必须用@Repeatable注解。事实上，这并不是语言层面上的改变，更多的是编译器的技巧，底层的原理保持不变。
（2）扩展注解的支持
Java 8扩展了注解的上下文。现在几乎可以为任何东西添加注解：局部变量、泛型类、父类与接口的实现，就连方法的异常也能添加注解。
九、并行（parallel）数组
Java 8增加了大量的新方法来对数组进行并行处理。可以说，最重要的是parallelSort()方法，因为它可以在多核机器上极大提高数组排序的速度。下面的例子展示了新方法（parallelXxx）的使用。
上面的代码片段使用了parallelSetAll()方法来对一个有20000个元素的数组进行随机赋值。然后，调用parallelSort方法。这个程序首先打印出前10个元素的值，之后对整个数组排序。这个程序在控制台上的输出如下（请注意数组元素是随机生产的）：
十、并发（Concurrency）
在新增Stream机制与lambda的基础之上，在java.util.concurrent.ConcurrentHashMap中加入了一些新方法来支持聚集操作。同时也在java.util.concurrent.ForkJoinPool类中加入了一些新方法来支持共有资源池（common pool）（请查看我们关于Java 并发的免费课程）。
新增的java.util.concurrent.locks.StampedLock类提供一直基于容量的锁，这种锁有三个模型来控制读写操作（它被认为是不太有名的java.util.concurrent.locks.ReadWriteLock类的替代者）。
在java.util.concurrent.atomic包中还增加了下面这些类：
1.DoubleAccumulator
2.DoubleAdder
3.LongAccumulator
4.LongAdder
6.JavaScript this关键字
面向对象语言中 this 表示当前对象的一个引用。
但在 JavaScript 中 this 不是固定不变的，它会随着执行环境的改变而改变。
在方法中，this 表示该方法所属的对象。
如果单独使用，this 表示全局对象。
在函数中，this 表示全局对象。
在函数中，在严格模式下，this 是未定义的(undefined)。
在事件中，this 表示接收事件的元素。
类似 call() 和 apply() 方法可以将 this 引用到任何对象。
var person = {
firstName: "John",
lastName : "Doe",
id : 5566,
fullName : function() {
return this.firstName + " " + this.lastName;
}
};
方法中的 this
在对象方法中， this 指向调用它所在方法的对象。
在上面一个实例中，this 表示 person 对象。
fullName 方法所属的对象就是 person。
fullName : function() {
return this.firstName + " " + this.lastName;
}
单独使用 this
单独使用 this，则它指向全局(Global)对象。
在浏览器中，window 就是该全局对象为 [object Window]:
var x = this;
严格模式下，如果单独使用，this 也是指向全局(Global)对象。
"use strict";
var x = this;
函数中使用 this（默认）
在函数中，函数的所属者默认绑定到 this 上。
在浏览器中，window 就是该全局对象为 [object Window]:
function myFunction() {
return this;
}
函数中使用 this（严格模式）
严格模式下函数是没有绑定到 this 上，这时候 this 是 undefined。
"use strict";
function myFunction() {
return this;
}
事件中的 this
在 HTML 事件句柄中，this 指向了接收事件的 HTML 元素：
<button onclick="this.style.display='none'">
点我后我就消失了
</button>
对象方法中绑定
下面实例中，this 是 person 对象，person 对象是函数的所有者：
var person = {
firstName : "John",
lastName : "Doe",
id : 5566,
myFunction : function() {
return this;
}
};
var person = {
firstName: "John",
lastName : "Doe",
id : 5566,
fullName : function() {
return this.firstName + " " + this.lastName;
}
};
说明: this.firstName 表示 this (person) 对象的 firstName 属性。
显式函数绑定
在 JavaScript 中函数也是对象，对象则有方法，apply 和 call 就是函数对象的方法。这两个方法异常强大，他们允许切换函数执行的上下文环境（context），即 this 绑定的对象。
在下面实例中，当我们使用 person2 作为参数来调用 person1.fullName 方法时, this 将指向 person2, 即便它是 person1 的方法：
var person1 = {
fullName: function() {
return this.firstName + " " + this.lastName;
}
}
var person2 = {
firstName:"John",
lastName: "Doe",
}
person1.fullName.call(person2); // 返回 "John Doe"
this 的多种指向:
1、在对象方法中， this 指向调用它所在方法的对象。
2、单独使用 this，它指向全局(Global)对象。
3、函数使用中，this 指向函数的所属者。
4、严格模式下函数是没有绑定到 this 上，这时候 this 是 undefined。
5、在 HTML 事件句柄中，this 指向了接收事件的 HTML 元素。
6、apply 和 call 允许切换函数执行的上下文环境（context），即 this 绑定的对象，可以将 this 引用到任何对象。
7、token和session
1. 为什么要有session的出现？
答：是由于网络中http协议造成的，因为http本身是无状态协议，这样，无法确定你的本次请求和上次请求是不是你发送的。如果要进行类似论坛登陆相关的操作，就实现不了了。
2. session生成方式？
答：浏览器第一次访问服务器，服务器会创建一个session，然后同时为该session生成一个唯一的会话的key,也就是sessionid，然后，将sessionid及对应的session分别作为key和value保存到缓存中，也可以持久化到数据库中，然后服务器再把sessionid，以cookie的形式发送给客户端。这样浏览器下次再访问时，会直接带着cookie中的sessionid。然后服务器根据sessionid找到对应的session进行匹配；
还有一种是浏览器禁用了cookie或不支持cookie，这种可以通过URL重写的方式发到服务器；
简单来讲，用户访问的时候说他自己是张三，他骗你怎么办？ 那就在服务器端保存张三的信息，给他一个id，让他下次用id访问。
3. 为什么会有token的出现？
答：首先，session的存储是需要空间的，其次，session的传递一般都是通过cookie来传递的，或者url重写的方式；而token在服务器是可以不需要存储用户的信息的，而token的传递方式也不限于cookie传递，当然，token也是可以保存起来的；
4. token的生成方式？
答：浏览器第一次访问服务器，根据传过来的唯一标识userId，服务端会通过一些算法，如常用的HMAC-SHA256算法，然后加一个密钥，生成一个token，然后通过BASE64编码一下之后将这个token发送给客户端；客户端将token保存起来，下次请求时，带着token，服务器收到请求后，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过，返回不通过信息；
5. token和session的区别？
token和session其实都是为了身份验证，session一般翻译为会话，而token更多的时候是翻译为令牌；
session服务器会保存一份，可能保存到缓存，文件，数据库；同样，session和token都是有过期时间一说，都需要去管理过期时间；
其实token与session的问题是一种时间与空间的博弈问题，session是空间换时间，而token是时间换空间。两者的选择要看具体情况而定。
虽然确实都是“客户端记录，每次访问携带”，但 token 很容易设计为自包含的，也就是说，后端不需要记录什么东西，每次一个无状态请求，每次解密验证，每次当场得出合法 /非法的结论。这一切判断依据，除了固化在 CS 两端的一些逻辑之外，整个信息是自包含的。这才是真正的无状态。
而 sessionid ，一般都是一段随机字符串，需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢？万一 redis 服务器挂了呢？
方案 A ：我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。
方案 B ：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人。
就这么个差别。
8.微服务
1.API管理
原理
在SpringMVC中RequestMappingHandlerMapping是比较重要的一个角色，它决定了每个URL分发至哪个Controller。
Spring Boot加载过程如下，所以我们可以通过自定义WebMvcRegistrationsAdapter来改写RequestMappingHandlerMapping。
2. 服务熔断
Hystrix的熔断
Netflix’ Hystrix是第一个专门用于熔断的服务中间件。当它在2012年向公众发布，以提供“对延迟和失败有更大容忍度”的微服务架构时，Netflix已经在内部广泛使用了一年多的时间了。根据这个项目的描述，Hystrix一直是Netflix服务中间件的基本组成部分之一，直到2018年底进入维护模式，这标志着“[关注点]转向更适应应用程序实时性能的实现，而不是预先配置的设置。”
Hystrix是一个Java库，开发人员可以使用它用熔断逻辑封装服务调用。它基于阈值，可以立即判定调用失败并执行回滚逻辑，具体参考第一部分。除了提供超时和并发限制之外，它还可以向监视工具发布度量metrics。最后，当与Archaius库一起使用时，它还可以支持动态配置更改。
服务网格中的熔断
Istio
Istio是一个服务网格，它支持基于连接池、每个连接的请求和故障检测参数的熔断。它是在所谓的“目的地规则(destination rules)”的帮助下做到这一点的，该规则告诉每个Envoy代理应用于通信的策略是什么，以及如何应用。这个步骤发生在路由之后，然而这并不总是理想的。目标规则可以指定负载均衡的限制、连接池大小以及最终符合“异常值”条件的参数，以便可以从负载均衡池中删除不健康的实例。这种类型的熔断擅长于使客户端免受服务端故障的影响，但是由于目标规则总是在集群范围内应用，所以它缺乏一种方法来将断路器限制在客户端的一个子集内。为了实现断路器与服务质量模式(quality-of-service)的组合，必须创建多个客户机子集的路由规则，并且每个子集都有自己的目标规则。
3.微服服务跟踪
服务追踪系统实现
上面是服务追踪系统架构图，你可以看到一个服务追踪系统可以分为三层。
数据采集层，负责数据埋点并上报。
数据处理层，负责数据的存储与计算。
数据展示层，负责数据的图形化展示
服务追踪的作用
第一，优化系统瓶颈。
通过记录调用经过的每一条链路上的耗时，我们能快速定位整个系统的瓶颈点在哪里。比如你访问微博首页发现很慢，肯定是由于某种原因造成的，有可能是运营商网络延迟，有可能是网关系统异常，有可能是某个服务异常，还有可能是缓存或者数据库异常。通过服务追踪，可以从全局视角上去观察，找出整个系统的瓶颈点所在，然后做出针对性的优化。
第二，优化链路调用。
通过服务追踪可以分析调用所经过的路径，然后评估是否合理。比如一个服务调用下游依赖了多个服务，通过调用链分析，可以评估是否每个依赖都是必要的，是否可以通过业务优化来减少服务依赖。
此外，一般业务都会在多个数据中心都部署服务，以实现异地容灾，这个时候经常会出现一种状况就是服务 A 调用了另外一个数据中心的服务 B，而没有调用同处于一个数据中心的服务 B。跨数据中心的调用视距离远近都会有一定的网络延迟，像北京和广州这种几千公里距离的网络延迟可能达到 30ms 以上，这对于有些业务几乎是不可接受的。通过对调用链路进行分析，可以找出跨数据中心的服务调用，从而进行优化，尽量规避这种情况出现。
第三，生成网络拓扑。
通过服务追踪系统中记录的链路信息，可以生成一张系统的网络调用拓扑图，它可以反映系统都依赖了哪些服务，以及服务之间的调用关系是什么样的，可以一目了然。除此之外，在网络拓扑图上还可以把服务调用的详细信息也标出来，也能起到服务监控的作用。
第四，透明传输数据。
除了服务追踪，业务上经常有一种需求，期望能把一些用户数据，从调用的开始一直往下传递，以便系统中的各个服务都能获取到这个信息。比如业务想做一些 A/B 测试，这时候就想通过服务追踪系统，把 A/B 测试的开关逻辑一直往下传递，经过的每一层服务都能获取到这个开关值，就能够统一进行 A/B 测试。
服务追踪系统原理
它的核心理念就是调用链：通过一个全局唯一的 ID 将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。
可以说后面的诞生各种服务追踪系统都是基于 Dapper 衍生出来的，比较有名的有 Twitter 的Zipkin、阿里的鹰眼、美团的MTrace等。(服务追踪系统的鼻祖：Google 发布的一篇的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，里面详细讲解了服务追踪系统的实现原理。)
要理解服务追踪的原理，首先必须搞懂一些基本概念：traceId、spanId、annonation 等。Dapper 这篇论文讲得比较清楚，但对初学者来说理解起来可能有点困难，美团的 MTrace 的原理介绍理解起来相对容易一些，下面我就以 MTrace 为例，给你详细讲述服务追踪系统的实现原理。虽然原理有些晦涩，但却是你必须掌握的，只有理解了服务追踪的基本概念，才能更好地将其实现出来。
4.配置中心地方
配置实时生效：
传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。
配置管理流程：
配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。
开源配置中心基本介绍
目前市面上用的比较多的配置中心有：（按开源时间排序）
Disconf
2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经不维护了，最近的一次提交是两年前了。
Spring Cloud Config
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
Apollo
2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。
Nacos
2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
配置中心核心概念的对比
由于Disconf不再维护，下面对比一下Spring Cloud Config、Apollo和Nacos。
Spring Cloud Config、Apollo和Nacos在配置管理领域的概念基本相同，但是也存在一些不同的点，使用配置的过程中会涉及到一些比较重要的概念。
应用
应用是客户端系统的基本单位，Spring Cloud Config 将应用名称和对应Git中的文件名称关联起来了，这样可以起到多个应用配置相互隔离的作用。Apollo的配置都是在某个应用下面的（除了公共配置），也起到了多个应用配置相互隔离的作用。Nacos的应用概念比较弱，只有一个用于区分配置的额外属性，不过可以使用 Group 来做应用字段，可以起到隔离作用。
集群
不同的环境可以搭建不同的集群，这样可以起到物理隔离的作用，Spring Cloud Config、Apollo、Nacos都支持多个集群。
Label Profile & 环境 & 命名空间
Spring Cloud Config可以使用Label和Profile来做逻辑隔离，Label指远程仓库的分支，Profile类似Maven Profile可以区分环境，比如{application}-{profile}.properties。
Nacos的命名空间和Apollo的环境一样，是一个逻辑概念，可以作为环境逻辑隔离。Apollo中的命名空间指配置的名称，具体的配置项指配置文件中的一个Property。
配置管理功能的对比
作为配置中心，配置的整个管理流程应该具备流程化能力。
灰度发布
配置的灰度发布是配置中心比较重要的功能，当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例。
Spring Cloud Config支持通过/bus/refresh端点的destination参数来指定要更新配置的机器，不过整个流程不够自动化和体系化。
Apollo可以直接在控制台上点灰度发布指定发布机器的IP，接着再全量发布，做得比较体系化。
Nacos目前发布到0.9版本，还不支持灰度发布。
权限管理
配置的变更和代码变更都是对应用运行逻辑的改变，重要的配置变更常常会带来核弹的效果，对于配置变更的权限管控和审计能力同样是配置中心重要的功能。
Spring Cloud Config依赖Git的权限管理能力，开源的GitHub权限控制可以分为Admin、Write和Read权限，权限管理比较完善。
Apollo通过项目的维度来对配置进行权限管理，一个项目的owner可以授权给其他用户配置的修改发布权限。
Nacos目前看还不具备权限管理能力。
版本管理&回滚
当配置变更不符合预期的时候，需要根据配置的发布版本进行回滚。Spring Cloud Config、Apollo和Nacos都具备配置的版本管理和回滚能力，可以在控制台上查看配置的变更情况或进行回滚操作。Spring Cloud Config通过Git来做版本管理，更方便些。
配置格式校验
应用的配置数据存储在配置中心一般都会以一种配置格式存储，比如Properties、Json、Yaml等，如果配置格式错误，会导致客户端解析配置失败引起生产故障，配置中心对配置的格式校验能够有效防止人为错误操作的发生，是配置中心核心功能中的刚需。
Spring Cloud Config使用Git，目前还不支持格式检验，格式的正确性依赖研发人员自己。
Apollo和Nacos都会对配置格式的正确性进行检验，可以有效防止人为错误。
监听查询
当排查问题或者进行统计的时候，需要知道一个配置被哪些应用实例使用到，以及一个实例使用到了哪些配置。
Spring Cloud Config使用Spring Cloud Bus推送配置变更，Spring Cloud Bus兼容 RabbitMQ、Kafka等，支持查询订阅Topic和Consumer的订阅关系。
Apollo可以通过灰度实例列表查看监听配置的实例列表，但实例监听的配置(Apollo称为命名空间)目前还没有展示出来。
Nacos可以查看监听配置的实例，也可以查看实例监听的配置情况。
基本上，这三个产品都具备监听查询能力，在我们自己的使用过程中，Nacos使用起来相对简单，易用性相对更好些。
多环境
在实际生产中，配置中心常常需要涉及多环境或者多集群，业务在开发的时候可以将开发环境和生产环境分开，或者根据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比较小（开发环境影响到生产环境稳定性），配置中心可以通过逻辑隔离的方式支持多环境。
Spring Cloud Config支持Profile的方式隔离多个环境，通过在Git上配置多个Profile的配置文件，客户端启动时指定Profile就可以访问对应的配置文件。
Apollo也支持多环境，在控制台创建配置的时候就要指定配置所在的环境，客户端在启动的时候指定JVM参数ENV来访问对应环境的配置文件。
Nacos通过命名空间来支持多环境，每个命名空间的配置相互隔离，客户端指定想要访问的命名空间就可以达到逻辑隔离的作用。
多集群
当对稳定性要求比较高，不允许各个环境相互影响的时候，需要将多个环境通过多集群的方式进行物理隔离。
Spring Cloud Config可以通过搭建多套Config Server，Git使用同一个Git的多个仓库，来实现物理隔离。
Apollo可以搭建多套集群，Apollo的控制台和数据更新推送服务分开部署，控制台部署一套就可以管控多个集群。
Nacos控制台和后端配置服务是部署在一起的，可以通过不同的域名切换来支持多集群。
配置实时推送的对比
当配置变更的时候，配置中心需要将配置实时推送到应用客户端。
Nacos和Apollo配置推送都是基于HTTP长轮询，客户端和配置中心建立HTTP长联接，当配置变更的的时候，配置中心把配置推送到客户端。
Spring Cloud Config原生不支持配置的实时推送，需要依赖Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点:
基于Git的WebHook，配置变更触发server端refresh
Server端接收到请求并发送给Spring Cloud Bus
Spring Cloud Bus接到消息并通知给客户端
客户端接收到通知，请求Server端获取最新配置
5.API网关
1、API网关介绍
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
2、融入架构
API网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过API网关，然后由它将请求路由到合适的微服务。API网管经常会通过调用多个微服务并合并结果来处理一个请求。它可以在Web协议（如HTTP与WebSocket）与内部使用的非Web友好协议之间转换。
API网关还能为每个客户端提供一个定制的API。通常，它会向移动客户端暴露一个粗粒度的API。例如，考虑下产品详情的场景。API网关可以提供一个端点（/productdetails?productid=xxx），使移动客户端可以通过一个请求获取所有的产品详情。API网关通过调用各个服务（产品信息、推荐、评论等等）并合并结果来处理请求。
6.服务注册发现
客户端服务发现模式
当使用客户端服务发现的时候，客户端负责决定可用的服务实例的网络地址，以及围绕他们的负载均衡。客户端向服务注册表（service registry）发送一个请求，服务注册表是一个可用服务实例的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求，下图展示了这种模式的架构：
服务实例的网络地址是动态分配的。而且，由于自动扩展，失败和更新，服务实例的配置也经常变化。这样一来，你的客户端代码需要一套更精细的服务发现机制。
有两种主要的服务发现模式：客户端服务发现（client-side discovery）和服务器端服务发现（server-side discovery）。我们首先来看下客户端服务发现。
客户端服务发现模式
当使用客户端服务发现的时候，客户端负责决定可用的服务实例的网络地址，以及围绕他们的负载均衡。客户端向服务注册表（service registry）发送一个请求，服务注册表是一个可用服务实例的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求，下图展示了这种模式的架构：
一个服务实例被启动时，它的网络地址会被写到注册表上；当服务实例终止时，再从注册表中删除。这个服务实例的注册表通过心跳机制动态刷新。
Netflix OSS提供了一个客户端服务发现的好例子。Netflix Eureka是一个服务注册表，提供了REST API用来管理服务实例的注册和查询可用的实例。Netflix Ribbon是一个IPC客户端，和Eureka一起处理可用服务实例的负载均衡。下面会深入讨论Eureka。
客户端的服务发现模式有优势也有缺点。这种模式相对直接，但是除了服务注册表，没有其它动态的部分了。而且，由于客户端知道可用的服务实例，可以做到智能的，应用明确的负载均衡决策，比如一直用hash算法。这种模式的一个重大缺陷在于，客户端和服务注册表是一一对应的，必须为服务客户端用到的每一种编程语言和框架实现客户端服务发现逻辑。
服务器端服务发现模式
下图展示了这种模式的架构
客户端通过负载均衡器向一个服务发送请求，这个负载均衡器会查询服务注册表，并将请求路由到可用的服务实例上。通过客户端的服务发现，服务实例在服务注册表上被注册和注销。
AWS的ELB（Elastic Load Blancer）就是一个服务器端服务发现路由器。一个ELB通常被用来均衡来自互联网的外部流量，也可以用ELB去均衡流向VPC（Virtual Private Cloud）的流量。一个客户端通过ELB发送请求（HTTP或TCP）时，使用的是DNS，ELB会均衡这些注册的EC2实例或ECS（EC2 Container Service）容器的流量。没有另外的服务注册表，EC2实例和ECS容器也只会在ELB上注册。
HTTP服务器和类似Nginx、Nginx Plus的负载均衡器也可以被用做服务器端服务发现负载均衡器。例如，Consul Template可以用来动态配置Nginx的反向代理。
Consul Template定期从存储在Consul服务注册表的数据中，生成任意的配置文件。每当文件变化时，会运行一个shell命令。比如，Consul Template可以生成一个配置反向代理的nginx.conf文件，然后运行一个命令告诉Nginx去重新加载配置。还有一个更复杂的实现，通过HTTP API或DNS去动态地重新配置Nginx Plus。
有些部署环境，比如Kubernetes和Marathon会在集群中的每个host上运行一个代理。这个代理承担了服务器端服务发现负载均衡器的角色。为了向一个服务发送一个请求，一个客户端使用host的IP地址和服务分配的端口，通过代理路由这个请求。这个代理会直接将请求发送到集群上可用的服务实例。
服务器端服务发现模式也是优势和缺陷并存。最大的好处在于服务发现的细节被从客户端中抽象出来，客户端只需要向负载均衡器发送请求，不需要为服务客户端使用的每一种语言和框架，实现服务发现逻辑；另外，这种模式也有一些问题，除非这个负载均衡器是由部署环境提供的，又是另一个高需要启动和管理的可用的系统组件。
服务注册表（Service Registry）
服务注册表是服务发现的关键部分，是一个包含了服务实例的网络地址的数据库，必须是高可用和最新的。客户端可以缓存从服务注册表处获得的网络地址。但是，这些信息最终会失效，客户端会找不到服务实例。所以，服务注册表由一个服务器集群组成，通过应用协议来保持一致性。
正如上面提到的，Netflix Eureka是一个服务注册表的好例子。它提供了一个REST API用来注册和查询服务实例。一个服务实例通过POST请求来注册自己的网络位置，每隔30秒要通过一个PUT请求重新注册。注册表中的一个条目会因为一个HTTP DELETE请求或实例注册超时而被删除，客户端通过一个HTTP GET请求来检索注册的服务实例。
Netflix通过在每个EC2的可用区中，运行一个或多个Eureka服务器实现高可用。每个运行在EC2实例上的Eureka服务器都有一个弹性的IP地址。DNS TEXT records用来存储Eureka集群配置，实际上是从可用区到Eureka服务器网络地址的列表的映射。当一个Eureka服务器启动时，会向DNS发送请求，检索Eureka集群的配置，定位节点，并为自己分配一个未占用的弹性IP地址。
Eureka客户端（服务和服务客户端）查询DNS去寻找Eureka服务器的网络地址。客户端更想使用这个可用区内的Eureka服务器，如果没有可用的Eureka服务器，客户端会用另一个可用区内的Eureka服务器。
其它服务注册的例子包括：
- Etcd：一个高可用，分布式，一致的key-value存储，用来共享配置和服务发现。Kubernetes和Cloudfoundry都使用了etcd；
- Consul：一个发现和配置服务的工具。客户端可以利用它提供的API，注册和发现服务。Consul可以执行监控检测来实现服务的高可用；
- Apache Zookeeper：一个常用的，为分布式应用设计的高可用协调服务，最开始Zookeeper是Hadoop的子项目，现在已经顶级项目了。
一些系统，比如Kubernetes，Marathon和AWS没有一个明确的服务注册组件，这项功能是内置在基础设置中的。
下面我们来看看服务实例如何在注册表中注册。
服务注册（Service Registration）
前面提到了，服务实例必须要从注册表中注册和注销，有很多种方式来处理注册和注销的过程。一个选择是服务实例自己注册，即self-registration模式。另一种选择是其它的系统组件管理服务实例的注册，即第third-party registration模式。
自注册模式（The Self-Registration Pattern）
在self-registration模式中，服务实例负责从服务注册表中注册和注销。如果需要的话，一个服务实例发送心跳请求防止注册过期。下图展示了这种模式的架构：
Netflix OSS Eureka客户端是这种方式的一个好例子。Eureka客户端处理服务实例注册和注销的所有问题。Spring Cloud实现包括服务发现在内的多种模式，简化了Eureka的服务实例自动注册。仅仅通过@EnableEurekaClient注释就可以注释Java的配置类
self-registration模式同样也是优劣并存。优势之一在于简单，不需要其它组件。缺点是服务实例和服务注册表相对应，必须要为服务中用到的每种编程语言和框架实现注册代码。
第三方注册模式（The Third-Party Registration Pattern）
在third-party registration模式中，服务实例不会自己在服务注册表中注册，由另一个系统组件service registrar负责。service registrar通过轮询部署环境或订阅事件去跟踪运行中的实例的变化。当它注意到一个新的可用的服务实例时，就会到注册表中去注册。service registrar也会将停止的服务实例注销，下图展示了这种模式的架构。
service registrar的一个例子是开源的Registrator项目。它会自动注册和注销像Docker容器一样部署的服务。Registrator支持etcd和Consul等服务注册。
另一个service registrar的例子是NetflixOSS Prana。主要用于非JVM语言编写的服务，它是一个和服务实例配合的『双轮』应用。Prana会在Netflix Eureka上注册和注销实例。
service registrar是一个部署环境的内置组件，由Autoscaling Group创建的EC2实例可以被ELB自动注册。Kubernetes服务也可以自动注册。
third-party registration模式主要的优势在于解耦了服务和服务注册表。不需要为每个语言和框架都实现服务注册逻辑。服务实例注册由一个专用的服务集中实现。缺点是除了被内置到部署环境中，它本身也是一个高可用的系统组件，需要被启动和管理。
Nginx应该是现在最火的web和反向代理服务器，没有之一。她是一款诞生于俄罗斯的高性能web服务器，尤其在高并发情况下，相较Apache，有优异的表现。
那除了负载均衡，她还有什么其他的用途呢，下面我们来看下。
一、静态代理
Nginx擅长处理静态文件，是非常好的图片、文件服务器。把所有的静态资源的放到nginx上，可以使应用动静分离，性能更好。
二、负载均衡
Nginx通过反向代理可以实现服务的负载均衡，避免了服务器单节点故障，把请求按照一定的策略转发到不同的服务器上，达到负载的效果。
常用的负载均衡策略有：
1、轮询
将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
2、加权轮询
不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。
给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。
3、ip_hash（源地址哈希法）
根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客户端要访问服务器的序号。
采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
4、随机
通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。
5、least_conn（最小连接数法）
由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。
三、限流
Nginx的限流模块，是基于漏桶算法实现的，在高并发的场景下非常实用，如下图：
1、配置参数
1）limit_req_zone定义在http块中，$binary_remote_addr 表示保存客户端IP地址的二进制形式。
2）Zone定义IP状态及URL访问频率的共享内存区域。
zone=keyword标识区域的名字，以及冒号后面跟区域大小。16000个IP地址的状态信息约1MB，所以示例中区域可以存储160000个IP地址。
3）Rate定义最大请求速率。示例中速率不能超过每秒100个请求。
2、设置限流
burst排队大小，nodelay不限制单个请求间的时间。
四、缓存
1、浏览器缓存，静态资源缓存用expire。
2、代理层缓存
五、黑白名单
1、不限流白名单
2、黑名单
大致来说，zookeeper 的使用场景如下，我就举几个简单的，大家能说几个就好了：
- 分布式协调
- 分布式锁
- 元数据/配置信息管理
- HA高可用性
分布式协调
这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统
如何知道 B 系统的处理结果？用 zookeeper 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper 上对某个节点
的值注册个监听器，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 系统立马就可以收到通知，完美解决。
分布式锁
举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就
可以使用 zookeeper 分布式锁，一个机器接收到了请求之后先获取 zookeeper 上的一把分布式锁，就是可以去创建一个 znode，接着执行
操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。
元数据/配置信息管理
zookeeper 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、
配置信息的管理，包括 dubbo 注册中心不也支持 zookeeper 么？
HA高可用性
这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zookeeper 来开发 HA 高可用机制，就是一个
重要进程一般会做主备两个，主进程挂了立马通过 zookeeper 感知到切换到备用进程。
1.什么是ABA问题
ABA并不是一个缩写，更像是一个形象的描述。ABA问题出现在多线程或多进程计算环境中。
首先描述ABA。假设两个线程T1和T2访问同一个变量V，当T1访问变量V时，读取到V的值为A；此时线程T1被抢占了，T2开始执行，T2先将变量V的值从A变成了B，然后又将变量V从B变回了A；此时T1又抢占了主动权，继续执行，它发现变量V的值还是A，以为没有发生变化，所以就继续执行了。这个过程中，变量V从A变为B，再由B变为A就被形象地称为ABA问题了。
上面的描述看上去并不会导致什么问题。T1中的判断V的值是A就不应该有问题的，无论是开始的A，还是ABA后面的A，判断的结果应该是一样的才对。
不容易看出问题的主要还是因为：“值是一样的”等同于“没有发生变化”（就算被改回去了，那也是变化）的认知。毕竟在大多数程序代码中，我们只需要知道值是不是一样的，并不关心它在之前的过程中有没有发生变化；所以，当我需要知道之前的过程中“有没有发生变化”的时候，ABA就是问题了
1、基本的ABA问题
在CAS算法中，需要取出内存中某时刻的数据(由用户完成)，在下一时刻比较并交换(CPU保证原子操作)，这个时间差会导致数据的变化。
假设有以下顺序事件：
1、线程1从内存位置V中取出A
2、线程2从内存位置V中取出A
3、线程2进行了写操作，将B写入内存位置V
4、线程2将A再次写入内存位置V
5、线程1进行CAS操作，发现V中仍然是A，交换成功
尽管线程1的CAS操作成功，但线程1并不知道内存位置V的数据发生过改变
2、ABA问题示例
public class ABADemo {
private static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100);
public static void main(String[] args) {
new Thread(() -> {
atomicReference.compareAndSet(100, 101);
atomicReference.compareAndSet(101, 100);
},"t1").start();
new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(atomicReference.compareAndSet(100, 2019) + "\t修改后的值:" + atomicReference.get());
},"t2").start();
}
}
- 初始值为100，线程t1将100改成101，然后又将101改回100
- 线程t2先睡眠1秒，等待t1操作完成，然后t2线程将值改成2019
- 可以看到，线程2修改成功
输出结果：
true 修改后的值:2019
3、ABA问题解决
要解决ABA问题，可以增加一个版本号，当内存位置V的值每次被修改后，版本号都加1
AtomicStampedReference
AtomicStampedReference内部维护了对象值和版本号，在创建AtomicStampedReference对象时，需要传入初始值和初始版本号，
当AtomicStampedReference设置对象值时，对象值以及状态戳都必须满足期望值，写入才会成功
示例
public class ABADemo {
private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<Integer>(100,1);
public static void main(String[] args) {
new Thread(() -> {
System.out.println("t1拿到的初始版本号:" + atomicStampedReference.getStamp());
//睡眠1秒，是为了让t2线程也拿到同样的初始版本号
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicStampedReference.compareAndSet(100, 101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
atomicStampedReference.compareAndSet(101, 100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
},"t1").start();
new Thread(() -> {
int stamp = atomicStampedReference.getStamp();
System.out.println("t2拿到的初始版本号:" + stamp);
//睡眠3秒，是为了让t1线程完成ABA操作
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("最新版本号:" + atomicStampedReference.getStamp());
System.out.println(atomicStampedReference.compareAndSet(100, 2019,stamp,atomicStampedReference.getStamp() + 1) + "\t当前 值:" + atomicStampedReference.getReference());
},"t2").start();
}
}
1、初始值100，初始版本号1
2、线程t1和t2拿到一样的初始版本号
3、线程t1完成ABA操作，版本号递增到3
4、线程t2完成CAS操作，最新版本号已经变成3，跟线程t2之前拿到的版本号1不相等，操作失败
输出结果：
t1拿到的初始版本号:1
t2拿到的初始版本号:1
最新版本号:3 false
当前 值:100
AtomicMarkableReference
AtomicStampedReference可以给引用加上版本号，追踪引用的整个变化过程，如：A -> B -> C -> D - > A，通过AtomicStampedReference，我们可以知道，引用变量中途被更改了3次
但是，有时候，我们并不关心引用变量更改了几次，只是单纯的关心是否更改过，所以就有了AtomicMarkableReference
AtomicMarkableReference的唯一区别就是不再用int标识引用，而是使用boolean变量——表示引用变量是否被更改过
示例
public class ABADemo {
private static AtomicMarkableReference<Integer> atomicMarkableReference = new AtomicMarkableReference<Integer>(100,false);
public static void main(String[] args) {
new Thread(() -> {
System.out.println("t1版本号是否被更改:" + atomicMarkableReference.isMarked());
//睡眠1秒，是为了让t2线程也拿到同样的初始版本号
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicMarkableReference.compareAndSet(100, 101,atomicMarkableReference.isMarked(),true);
atomicMarkableReference.compareAndSet(101, 100,atomicMarkableReference.isMarked(),true);
},"t1").start();
new Thread(() -> {
boolean isMarked = atomicMarkableReference.isMarked();
System.out.println("t2版本号是否被更改:" + isMarked);
//睡眠3秒，是为了让t1线程完成ABA操作
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("是否更改过:" + atomicMarkableReference.isMarked());
System.out.println(atomicMarkableReference.compareAndSet(100, 2019,isMarked,true) + "\t当前 值:" + atomicMarkableReference.getReference());
},"t2").start();
}
}
1、初始值100，初始版本号未被修改 false
2、线程t1和t2拿到一样的初始版本号都未被修改 false
3、线程t1完成ABA操作，版本号被修改 true
4、线程t2完成CAS操作，版本号已经变成true，跟线程t2之前拿到的版本号false不相等，操作失败
输出结果：
t1版本号是否被更改:false
t2版本号是否被更改:false
是否更改过:truefalse
当前 值:100
Java乐观锁实现之CAS操作
介绍CAS操作前，我们先简单看一下乐观锁 与 悲观锁这两个常见的锁概念。
悲观锁：
从Java多线程角度，存在着“可见性、原子性、有序性”三个问题，悲观锁就是假设在实际情况中存在着多线程对同一共享的竞争，所以在操作前先占有共享资源（悲观态度）。因此，悲观锁是阻塞，独占的，存在着频繁的线程上下文切换，对资源消耗较大。synchronized就是悲观锁的一种实现。
乐观锁：
如名一样，每次操作都认为不会发生冲突，尝试执行，并检测结果是否正确。如果正确则执行成功，否则说明发生了冲突，回退再重新尝试。乐观锁的过程可以分为两步：冲突检测 和 数据更新。在Java多线程中乐观锁一个常见实现即：CAS操作。
在数据库中，悲观锁的流程如下：
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
MySQL InnoDB中使用悲观锁：
要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0;
//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;
上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。
上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。
优点与不足
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。
使用版本号实现乐观锁
使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。
1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};
优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
synchronized和Lock的异同
JAVA语言使用两种机制来实现堆某种共享资源的同步，synchronized和Lock。其中，synchronized使用Object对象本身的notify、wait、notifyAll调度机制，而lock可以使用Condition进行线程之间的调度，完成synchronized实现所有功能。
具体而言，两者的主要区别主要表现在以下几个方面：
1）用法不一样。在需要同步的对象中加入synchronized控制，synchronized既可以加在方法上，也可以加在特定代码中，括号中表示需要锁的对象。而Lock需要显示的指定起始位置和终点位置。synchronized是托管给JVM执行的，而Lock的锁定是通过代码实现的，它有比synchronized更精确的线程定义
2）性能不一样。在JDK 5中增加的ReentrantLock。它不仅拥有和synchronized相同的并发性和内存语义，还增加了锁投票，定时锁，等候和中断锁等。它们的性能在不同情况下会不同：在资源竞争不是很激励的情况下，synchronized的性能要优于ReentrantLock，带在资源紧张很激烈的情况下，synchronized的性能会下降的很快，而ReentrantLock的性能基本保持不变。
3）锁机制不一样。synchronized获得锁和释放锁的机制都在代码块结构中，当获得锁时，必须以相反的机制去释放，并且自动解锁，不会因为异常导致没有被释放而导致死锁。而Lock需要开发人员手动去释放，并且写在finally代码块中，否则会可能引起死锁问题的发生。此外，Lock还提供的更强大的功能，可以通过tryLock的方式采用非阻塞的方式取获得锁。
虽然synchronized和Lock都可以用来实现线程同步，但最好不要同时使用两种放式，因为synchronized和ReentrantLock所使用的机制不同，但是他们是独立运行的，相当于两种类型的锁，在使用时不会影响。示例如下：
|
import java.util.concurrent.locks.Lock;import java.util.concurrent.locks.ReentrantLock; public class SyncTest { private int value; Lock lock = new ReentrantLock(); public synchronized void addValueSync(){ this.value++; System.out.println(Thread.currentThread().getName()+":"+value); } public void addValueLock(){ try { lock.lock(); value++; System.out.println(Thread.currentThread().getName()+":"+value); }finally { lock.unlock(); } } }
|
|
public class Main { public static void main(String[] args){ final SyncTest st = new SyncTest(); Thread t1 = new Thread( new Runnable(){
@Override public void run() { // TODO Auto-generated method stub for(int i = 0;i<5;i++){ st.addValueSync(); try { Thread.sleep(20); } catch (InterruptedException e) { // TODO: handle exception e.printStackTrace(); } } }} ); Thread t2 = new Thread( new Runnable() {
@Override public void run() { // TODO Auto-generated method stub for(int i = 0;i <5 ;i++){ st.addValueLock(); try { Thread.sleep(20); } catch (InterruptedException e) { // TODO: handle exception e.printStackTrace(); } } } } ); t1.start(); t2.start(); } } |
线程安全是多线程领域的问题，线程安全可以简单理解为一个方法或者一个实例可以在多线程环境中使用而不会出现问题。
在 Java 多线程编程当中，提供了多种实现 Java 线程安全的方式：
最简单的方式，使用 Synchronization 关键字
使用 java.util.concurrent.atomic 包中的原子类，例如 AtomicInteger
使用 java.util.concurrent.locks 包中的锁
使用线程安全的集合 ConcurrentHashMap
使用 volatile 关键字，保证变量可见性（直接从内存读，而不是从线程 cache 读）
8.微服务
1.API管理
原理
在SpringMVC中RequestMappingHandlerMapping是比较重要的一个角色，它决定了每个URL分发至哪个Controller。
Spring Boot加载过程如下，所以我们可以通过自定义WebMvcRegistrationsAdapter来改写RequestMappingHandlerMapping。
3. 服务熔断
Hystrix的熔断
Netflix’ Hystrix是第一个专门用于熔断的服务中间件。当它在2012年向公众发布，以提供“对延迟和失败有更大容忍度”的微服务架构时，Netflix已经在内部广泛使用了一年多的时间了。根据这个项目的描述，Hystrix一直是Netflix服务中间件的基本组成部分之一，直到2018年底进入维护模式，这标志着“[关注点]转向更适应应用程序实时性能的实现，而不是预先配置的设置。”
Hystrix是一个Java库，开发人员可以使用它用熔断逻辑封装服务调用。它基于阈值，可以立即判定调用失败并执行回滚逻辑，具体参考第一部分。除了提供超时和并发限制之外，它还可以向监视工具发布度量metrics。最后，当与Archaius库一起使用时，它还可以支持动态配置更改。
服务网格中的熔断
Istio
Istio是一个服务网格，它支持基于连接池、每个连接的请求和故障检测参数的熔断。它是在所谓的“目的地规则(destination rules)”的帮助下做到这一点的，该规则告诉每个Envoy代理应用于通信的策略是什么，以及如何应用。这个步骤发生在路由之后，然而这并不总是理想的。目标规则可以指定负载均衡的限制、连接池大小以及最终符合“异常值”条件的参数，以便可以从负载均衡池中删除不健康的实例。这种类型的熔断擅长于使客户端免受服务端故障的影响，但是由于目标规则总是在集群范围内应用，所以它缺乏一种方法来将断路器限制在客户端的一个子集内。为了实现断路器与服务质量模式(quality-of-service)的组合，必须创建多个客户机子集的路由规则，并且每个子集都有自己的目标规则。
3.微服服务跟踪
服务追踪系统实现
上面是服务追踪系统架构图，你可以看到一个服务追踪系统可以分为三层。
数据采集层，负责数据埋点并上报。
数据处理层，负责数据的存储与计算。
数据展示层，负责数据的图形化展示
服务追踪的作用
第一，优化系统瓶颈。
通过记录调用经过的每一条链路上的耗时，我们能快速定位整个系统的瓶颈点在哪里。比如你访问微博首页发现很慢，肯定是由于某种原因造成的，有可能是运营商网络延迟，有可能是网关系统异常，有可能是某个服务异常，还有可能是缓存或者数据库异常。通过服务追踪，可以从全局视角上去观察，找出整个系统的瓶颈点所在，然后做出针对性的优化。
第二，优化链路调用。
通过服务追踪可以分析调用所经过的路径，然后评估是否合理。比如一个服务调用下游依赖了多个服务，通过调用链分析，可以评估是否每个依赖都是必要的，是否可以通过业务优化来减少服务依赖。
此外，一般业务都会在多个数据中心都部署服务，以实现异地容灾，这个时候经常会出现一种状况就是服务 A 调用了另外一个数据中心的服务 B，而没有调用同处于一个数据中心的服务 B。跨数据中心的调用视距离远近都会有一定的网络延迟，像北京和广州这种几千公里距离的网络延迟可能达到 30ms 以上，这对于有些业务几乎是不可接受的。通过对调用链路进行分析，可以找出跨数据中心的服务调用，从而进行优化，尽量规避这种情况出现。
第三，生成网络拓扑。
通过服务追踪系统中记录的链路信息，可以生成一张系统的网络调用拓扑图，它可以反映系统都依赖了哪些服务，以及服务之间的调用关系是什么样的，可以一目了然。除此之外，在网络拓扑图上还可以把服务调用的详细信息也标出来，也能起到服务监控的作用。
第四，透明传输数据。
除了服务追踪，业务上经常有一种需求，期望能把一些用户数据，从调用的开始一直往下传递，以便系统中的各个服务都能获取到这个信息。比如业务想做一些 A/B 测试，这时候就想通过服务追踪系统，把 A/B 测试的开关逻辑一直往下传递，经过的每一层服务都能获取到这个开关值，就能够统一进行 A/B 测试。
服务追踪系统原理
它的核心理念就是调用链：通过一个全局唯一的 ID 将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。
可以说后面的诞生各种服务追踪系统都是基于 Dapper 衍生出来的，比较有名的有 Twitter 的Zipkin、阿里的鹰眼、美团的MTrace等。(服务追踪系统的鼻祖：Google 发布的一篇的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，里面详细讲解了服务追踪系统的实现原理。)
要理解服务追踪的原理，首先必须搞懂一些基本概念：traceId、spanId、annonation 等。Dapper 这篇论文讲得比较清楚，但对初学者来说理解起来可能有点困难，美团的 MTrace 的原理介绍理解起来相对容易一些，下面我就以 MTrace 为例，给你详细讲述服务追踪系统的实现原理。虽然原理有些晦涩，但却是你必须掌握的，只有理解了服务追踪的基本概念，才能更好地将其实现出来。
4.配置中心地方
配置实时生效：
传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。
配置管理流程：
配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。
开源配置中心基本介绍
目前市面上用的比较多的配置中心有：（按开源时间排序）
Disconf
2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经不维护了，最近的一次提交是两年前了。
Spring Cloud Config
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
Apollo
2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。
Nacos
2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
配置中心核心概念的对比
由于Disconf不再维护，下面对比一下Spring Cloud Config、Apollo和Nacos。
Spring Cloud Config、Apollo和Nacos在配置管理领域的概念基本相同，但是也存在一些不同的点，使用配置的过程中会涉及到一些比较重要的概念。
应用
应用是客户端系统的基本单位，Spring Cloud Config 将应用名称和对应Git中的文件名称关联起来了，这样可以起到多个应用配置相互隔离的作用。Apollo的配置都是在某个应用下面的（除了公共配置），也起到了多个应用配置相互隔离的作用。Nacos的应用概念比较弱，只有一个用于区分配置的额外属性，不过可以使用 Group 来做应用字段，可以起到隔离作用。
集群
不同的环境可以搭建不同的集群，这样可以起到物理隔离的作用，Spring Cloud Config、Apollo、Nacos都支持多个集群。
Label Profile & 环境 & 命名空间
Spring Cloud Config可以使用Label和Profile来做逻辑隔离，Label指远程仓库的分支，Profile类似Maven Profile可以区分环境，比如{application}-{profile}.properties。
Nacos的命名空间和Apollo的环境一样，是一个逻辑概念，可以作为环境逻辑隔离。Apollo中的命名空间指配置的名称，具体的配置项指配置文件中的一个Property。
配置管理功能的对比
作为配置中心，配置的整个管理流程应该具备流程化能力。
灰度发布
配置的灰度发布是配置中心比较重要的功能，当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例。
Spring Cloud Config支持通过/bus/refresh端点的destination参数来指定要更新配置的机器，不过整个流程不够自动化和体系化。
Apollo可以直接在控制台上点灰度发布指定发布机器的IP，接着再全量发布，做得比较体系化。
Nacos目前发布到0.9版本，还不支持灰度发布。
权限管理
配置的变更和代码变更都是对应用运行逻辑的改变，重要的配置变更常常会带来核弹的效果，对于配置变更的权限管控和审计能力同样是配置中心重要的功能。
Spring Cloud Config依赖Git的权限管理能力，开源的GitHub权限控制可以分为Admin、Write和Read权限，权限管理比较完善。
Apollo通过项目的维度来对配置进行权限管理，一个项目的owner可以授权给其他用户配置的修改发布权限。
Nacos目前看还不具备权限管理能力。
版本管理&回滚
当配置变更不符合预期的时候，需要根据配置的发布版本进行回滚。Spring Cloud Config、Apollo和Nacos都具备配置的版本管理和回滚能力，可以在控制台上查看配置的变更情况或进行回滚操作。Spring Cloud Config通过Git来做版本管理，更方便些。
配置格式校验
应用的配置数据存储在配置中心一般都会以一种配置格式存储，比如Properties、Json、Yaml等，如果配置格式错误，会导致客户端解析配置失败引起生产故障，配置中心对配置的格式校验能够有效防止人为错误操作的发生，是配置中心核心功能中的刚需。
Spring Cloud Config使用Git，目前还不支持格式检验，格式的正确性依赖研发人员自己。
Apollo和Nacos都会对配置格式的正确性进行检验，可以有效防止人为错误。
监听查询
当排查问题或者进行统计的时候，需要知道一个配置被哪些应用实例使用到，以及一个实例使用到了哪些配置。
Spring Cloud Config使用Spring Cloud Bus推送配置变更，Spring Cloud Bus兼容 RabbitMQ、Kafka等，支持查询订阅Topic和Consumer的订阅关系。
Apollo可以通过灰度实例列表查看监听配置的实例列表，但实例监听的配置(Apollo称为命名空间)目前还没有展示出来。
Nacos可以查看监听配置的实例，也可以查看实例监听的配置情况。
基本上，这三个产品都具备监听查询能力，在我们自己的使用过程中，Nacos使用起来相对简单，易用性相对更好些。
多环境
在实际生产中，配置中心常常需要涉及多环境或者多集群，业务在开发的时候可以将开发环境和生产环境分开，或者根据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比较小（开发环境影响到生产环境稳定性），配置中心可以通过逻辑隔离的方式支持多环境。
Spring Cloud Config支持Profile的方式隔离多个环境，通过在Git上配置多个Profile的配置文件，客户端启动时指定Profile就可以访问对应的配置文件。
Apollo也支持多环境，在控制台创建配置的时候就要指定配置所在的环境，客户端在启动的时候指定JVM参数ENV来访问对应环境的配置文件。
Nacos通过命名空间来支持多环境，每个命名空间的配置相互隔离，客户端指定想要访问的命名空间就可以达到逻辑隔离的作用。
多集群
当对稳定性要求比较高，不允许各个环境相互影响的时候，需要将多个环境通过多集群的方式进行物理隔离。
Spring Cloud Config可以通过搭建多套Config Server，Git使用同一个Git的多个仓库，来实现物理隔离。
Apollo可以搭建多套集群，Apollo的控制台和数据更新推送服务分开部署，控制台部署一套就可以管控多个集群。
Nacos控制台和后端配置服务是部署在一起的，可以通过不同的域名切换来支持多集群。
配置实时推送的对比
当配置变更的时候，配置中心需要将配置实时推送到应用客户端。
Nacos和Apollo配置推送都是基于HTTP长轮询，客户端和配置中心建立HTTP长联接，当配置变更的的时候，配置中心把配置推送到客户端。
Spring Cloud Config原生不支持配置的实时推送，需要依赖Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点:
基于Git的WebHook，配置变更触发server端refresh
Server端接收到请求并发送给Spring Cloud Bus
Spring Cloud Bus接到消息并通知给客户端
客户端接收到通知，请求Server端获取最新配置
5.API网关
1、API网关介绍
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
2、融入架构
API网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过API网关，然后由它将请求路由到合适的微服务。API网管经常会通过调用多个微服务并合并结果来处理一个请求。它可以在Web协议（如HTTP与WebSocket）与内部使用的非Web友好协议之间转换。
API网关还能为每个客户端提供一个定制的API。通常，它会向移动客户端暴露一个粗粒度的API。例如，考虑下产品详情的场景。API网关可以提供一个端点（/productdetails?productid=xxx），使移动客户端可以通过一个请求获取所有的产品详情。API网关通过调用各个服务（产品信息、推荐、评论等等）并合并结果来处理请求。
6.服务注册发现
客户端服务发现模式
当使用客户端服务发现的时候，客户端负责决定可用的服务实例的网络地址，以及围绕他们的负载均衡。客户端向服务注册表（service registry）发送一个请求，服务注册表是一个可用服务实例的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求，下图展示了这种模式的架构：
服务实例的网络地址是动态分配的。而且，由于自动扩展，失败和更新，服务实例的配置也经常变化。这样一来，你的客户端代码需要一套更精细的服务发现机制。
有两种主要的服务发现模式：客户端服务发现（client-side discovery）和服务器端服务发现（server-side discovery）。我们首先来看下客户端服务发现。
客户端服务发现模式
当使用客户端服务发现的时候，客户端负责决定可用的服务实例的网络地址，以及围绕他们的负载均衡。客户端向服务注册表（service registry）发送一个请求，服务注册表是一个可用服务实例的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求，下图展示了这种模式的架构：
一个服务实例被启动时，它的网络地址会被写到注册表上；当服务实例终止时，再从注册表中删除。这个服务实例的注册表通过心跳机制动态刷新。
Netflix OSS提供了一个客户端服务发现的好例子。Netflix Eureka是一个服务注册表，提供了REST API用来管理服务实例的注册和查询可用的实例。Netflix Ribbon是一个IPC客户端，和Eureka一起处理可用服务实例的负载均衡。下面会深入讨论Eureka。
客户端的服务发现模式有优势也有缺点。这种模式相对直接，但是除了服务注册表，没有其它动态的部分了。而且，由于客户端知道可用的服务实例，可以做到智能的，应用明确的负载均衡决策，比如一直用hash算法。这种模式的一个重大缺陷在于，客户端和服务注册表是一一对应的，必须为服务客户端用到的每一种编程语言和框架实现客户端服务发现逻辑。
服务器端服务发现模式
下图展示了这种模式的架构
客户端通过负载均衡器向一个服务发送请求，这个负载均衡器会查询服务注册表，并将请求路由到可用的服务实例上。通过客户端的服务发现，服务实例在服务注册表上被注册和注销。
AWS的ELB（Elastic Load Blancer）就是一个服务器端服务发现路由器。一个ELB通常被用来均衡来自互联网的外部流量，也可以用ELB去均衡流向VPC（Virtual Private Cloud）的流量。一个客户端通过ELB发送请求（HTTP或TCP）时，使用的是DNS，ELB会均衡这些注册的EC2实例或ECS（EC2 Container Service）容器的流量。没有另外的服务注册表，EC2实例和ECS容器也只会在ELB上注册。
HTTP服务器和类似Nginx、Nginx Plus的负载均衡器也可以被用做服务器端服务发现负载均衡器。例如，Consul Template可以用来动态配置Nginx的反向代理。
Consul Template定期从存储在Consul服务注册表的数据中，生成任意的配置文件。每当文件变化时，会运行一个shell命令。比如，Consul Template可以生成一个配置反向代理的nginx.conf文件，然后运行一个命令告诉Nginx去重新加载配置。还有一个更复杂的实现，通过HTTP API或DNS去动态地重新配置Nginx Plus。
有些部署环境，比如Kubernetes和Marathon会在集群中的每个host上运行一个代理。这个代理承担了服务器端服务发现负载均衡器的角色。为了向一个服务发送一个请求，一个客户端使用host的IP地址和服务分配的端口，通过代理路由这个请求。这个代理会直接将请求发送到集群上可用的服务实例。
服务器端服务发现模式也是优势和缺陷并存。最大的好处在于服务发现的细节被从客户端中抽象出来，客户端只需要向负载均衡器发送请求，不需要为服务客户端使用的每一种语言和框架，实现服务发现逻辑；另外，这种模式也有一些问题，除非这个负载均衡器是由部署环境提供的，又是另一个高需要启动和管理的可用的系统组件。
服务注册表（Service Registry）
服务注册表是服务发现的关键部分，是一个包含了服务实例的网络地址的数据库，必须是高可用和最新的。客户端可以缓存从服务注册表处获得的网络地址。但是，这些信息最终会失效，客户端会找不到服务实例。所以，服务注册表由一个服务器集群组成，通过应用协议来保持一致性。
正如上面提到的，Netflix Eureka是一个服务注册表的好例子。它提供了一个REST API用来注册和查询服务实例。一个服务实例通过POST请求来注册自己的网络位置，每隔30秒要通过一个PUT请求重新注册。注册表中的一个条目会因为一个HTTP DELETE请求或实例注册超时而被删除，客户端通过一个HTTP GET请求来检索注册的服务实例。
Netflix通过在每个EC2的可用区中，运行一个或多个Eureka服务器实现高可用。每个运行在EC2实例上的Eureka服务器都有一个弹性的IP地址。DNS TEXT records用来存储Eureka集群配置，实际上是从可用区到Eureka服务器网络地址的列表的映射。当一个Eureka服务器启动时，会向DNS发送请求，检索Eureka集群的配置，定位节点，并为自己分配一个未占用的弹性IP地址。
Eureka客户端（服务和服务客户端）查询DNS去寻找Eureka服务器的网络地址。客户端更想使用这个可用区内的Eureka服务器，如果没有可用的Eureka服务器，客户端会用另一个可用区内的Eureka服务器。
其它服务注册的例子包括：
- Etcd：一个高可用，分布式，一致的key-value存储，用来共享配置和服务发现。Kubernetes和Cloudfoundry都使用了etcd；
- Consul：一个发现和配置服务的工具。客户端可以利用它提供的API，注册和发现服务。Consul可以执行监控检测来实现服务的高可用；
- Apache Zookeeper：一个常用的，为分布式应用设计的高可用协调服务，最开始Zookeeper是Hadoop的子项目，现在已经顶级项目了。
一些系统，比如Kubernetes，Marathon和AWS没有一个明确的服务注册组件，这项功能是内置在基础设置中的。
下面我们来看看服务实例如何在注册表中注册。
服务注册（Service Registration）
前面提到了，服务实例必须要从注册表中注册和注销，有很多种方式来处理注册和注销的过程。一个选择是服务实例自己注册，即self-registration模式。另一种选择是其它的系统组件管理服务实例的注册，即第third-party registration模式。
自注册模式（The Self-Registration Pattern）
在self-registration模式中，服务实例负责从服务注册表中注册和注销。如果需要的话，一个服务实例发送心跳请求防止注册过期。下图展示了这种模式的架构：
Netflix OSS Eureka客户端是这种方式的一个好例子。Eureka客户端处理服务实例注册和注销的所有问题。Spring Cloud实现包括服务发现在内的多种模式，简化了Eureka的服务实例自动注册。仅仅通过@EnableEurekaClient注释就可以注释Java的配置类
self-registration模式同样也是优劣并存。优势之一在于简单，不需要其它组件。缺点是服务实例和服务注册表相对应，必须要为服务中用到的每种编程语言和框架实现注册代码。
第三方注册模式（The Third-Party Registration Pattern）
在third-party registration模式中，服务实例不会自己在服务注册表中注册，由另一个系统组件service registrar负责。service registrar通过轮询部署环境或订阅事件去跟踪运行中的实例的变化。当它注意到一个新的可用的服务实例时，就会到注册表中去注册。service registrar也会将停止的服务实例注销，下图展示了这种模式的架构。
service registrar的一个例子是开源的Registrator项目。它会自动注册和注销像Docker容器一样部署的服务。Registrator支持etcd和Consul等服务注册。
另一个service registrar的例子是NetflixOSS Prana。主要用于非JVM语言编写的服务，它是一个和服务实例配合的『双轮』应用。Prana会在Netflix Eureka上注册和注销实例。
service registrar是一个部署环境的内置组件，由Autoscaling Group创建的EC2实例可以被ELB自动注册。Kubernetes服务也可以自动注册。
third-party registration模式主要的优势在于解耦了服务和服务注册表。不需要为每个语言和框架都实现服务注册逻辑。服务实例注册由一个专用的服务集中实现。缺点是除了被内置到部署环境中，它本身也是一个高可用的系统组件，需要被启动和管理。
Nginx应该是现在最火的web和反向代理服务器，没有之一。她是一款诞生于俄罗斯的高性能web服务器，尤其在高并发情况下，相较Apache，有优异的表现。
那除了负载均衡，她还有什么其他的用途呢，下面我们来看下。
一、静态代理
Nginx擅长处理静态文件，是非常好的图片、文件服务器。把所有的静态资源的放到nginx上，可以使应用动静分离，性能更好。
二、负载均衡
Nginx通过反向代理可以实现服务的负载均衡，避免了服务器单节点故障，把请求按照一定的策略转发到不同的服务器上，达到负载的效果。
常用的负载均衡策略有：
1、轮询
将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
2、加权轮询
不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。
给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。
3、ip_hash（源地址哈希法）
根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客户端要访问服务器的序号。
采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
4、随机
通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。
5、least_conn（最小连接数法）
由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。
三、限流
Nginx的限流模块，是基于漏桶算法实现的，在高并发的场景下非常实用，如下图：
1、配置参数
1）limit_req_zone定义在http块中，$binary_remote_addr 表示保存客户端IP地址的二进制形式。
2）Zone定义IP状态及URL访问频率的共享内存区域。
zone=keyword标识区域的名字，以及冒号后面跟区域大小。16000个IP地址的状态信息约1MB，所以示例中区域可以存储160000个IP地址。
3）Rate定义最大请求速率。示例中速率不能超过每秒100个请求。
2、设置限流
burst排队大小，nodelay不限制单个请求间的时间。
四、缓存
1、浏览器缓存，静态资源缓存用expire。
2、代理层缓存
五、黑白名单
1、不限流白名单
2、黑名单
大致来说，zookeeper 的使用场景如下，我就举几个简单的，大家能说几个就好了：
- 分布式协调
- 分布式锁
- 元数据/配置信息管理
- HA高可用性
分布式协调
这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统
如何知道 B 系统的处理结果？用 zookeeper 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper 上对某个节点
的值注册个监听器，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 系统立马就可以收到通知，完美解决。
分布式锁
举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就
可以使用 zookeeper 分布式锁，一个机器接收到了请求之后先获取 zookeeper 上的一把分布式锁，就是可以去创建一个 znode，接着执行
操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。
元数据/配置信息管理
zookeeper 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、
配置信息的管理，包括 dubbo 注册中心不也支持 zookeeper 么？
HA高可用性
这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zookeeper 来开发 HA 高可用机制，就是一个
重要进程一般会做主备两个，主进程挂了立马通过 zookeeper 感知到切换到备用进程。
1.什么是ABA问题
ABA并不是一个缩写，更像是一个形象的描述。ABA问题出现在多线程或多进程计算环境中。
首先描述ABA。假设两个线程T1和T2访问同一个变量V，当T1访问变量V时，读取到V的值为A；此时线程T1被抢占了，T2开始执行，T2先将变量V的值从A变成了B，然后又将变量V从B变回了A；此时T1又抢占了主动权，继续执行，它发现变量V的值还是A，以为没有发生变化，所以就继续执行了。这个过程中，变量V从A变为B，再由B变为A就被形象地称为ABA问题了。
上面的描述看上去并不会导致什么问题。T1中的判断V的值是A就不应该有问题的，无论是开始的A，还是ABA后面的A，判断的结果应该是一样的才对。
不容易看出问题的主要还是因为：“值是一样的”等同于“没有发生变化”（就算被改回去了，那也是变化）的认知。毕竟在大多数程序代码中，我们只需要知道值是不是一样的，并不关心它在之前的过程中有没有发生变化；所以，当我需要知道之前的过程中“有没有发生变化”的时候，ABA就是问题了
1、基本的ABA问题
在CAS算法中，需要取出内存中某时刻的数据(由用户完成)，在下一时刻比较并交换(CPU保证原子操作)，这个时间差会导致数据的变化。
假设有以下顺序事件：
1、线程1从内存位置V中取出A
2、线程2从内存位置V中取出A
3、线程2进行了写操作，将B写入内存位置V
4、线程2将A再次写入内存位置V
5、线程1进行CAS操作，发现V中仍然是A，交换成功
尽管线程1的CAS操作成功，但线程1并不知道内存位置V的数据发生过改变
2、ABA问题示例
public class ABADemo {
private static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100);
public static void main(String[] args) {
new Thread(() -> {
atomicReference.compareAndSet(100, 101);
atomicReference.compareAndSet(101, 100);
},"t1").start();
new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(atomicReference.compareAndSet(100, 2019) + "\t修改后的值:" + atomicReference.get());
},"t2").start();
}
}
- 初始值为100，线程t1将100改成101，然后又将101改回100
- 线程t2先睡眠1秒，等待t1操作完成，然后t2线程将值改成2019
- 可以看到，线程2修改成功
输出结果：
true 修改后的值:2019
3、ABA问题解决
要解决ABA问题，可以增加一个版本号，当内存位置V的值每次被修改后，版本号都加1
AtomicStampedReference
AtomicStampedReference内部维护了对象值和版本号，在创建AtomicStampedReference对象时，需要传入初始值和初始版本号，
当AtomicStampedReference设置对象值时，对象值以及状态戳都必须满足期望值，写入才会成功
示例
public class ABADemo {
private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<Integer>(100,1);
public static void main(String[] args) {
new Thread(() -> {
System.out.println("t1拿到的初始版本号:" + atomicStampedReference.getStamp());
//睡眠1秒，是为了让t2线程也拿到同样的初始版本号
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicStampedReference.compareAndSet(100, 101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
atomicStampedReference.compareAndSet(101, 100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
},"t1").start();
new Thread(() -> {
int stamp = atomicStampedReference.getStamp();
System.out.println("t2拿到的初始版本号:" + stamp);
//睡眠3秒，是为了让t1线程完成ABA操作
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("最新版本号:" + atomicStampedReference.getStamp());
System.out.println(atomicStampedReference.compareAndSet(100, 2019,stamp,atomicStampedReference.getStamp() + 1) + "\t当前 值:" + atomicStampedReference.getReference());
},"t2").start();
}
}
1、初始值100，初始版本号1
2、线程t1和t2拿到一样的初始版本号
3、线程t1完成ABA操作，版本号递增到3
4、线程t2完成CAS操作，最新版本号已经变成3，跟线程t2之前拿到的版本号1不相等，操作失败
输出结果：
t1拿到的初始版本号:1
t2拿到的初始版本号:1
最新版本号:3 false
当前 值:100
AtomicMarkableReference
AtomicStampedReference可以给引用加上版本号，追踪引用的整个变化过程，如：A -> B -> C -> D - > A，通过AtomicStampedReference，我们可以知道，引用变量中途被更改了3次
但是，有时候，我们并不关心引用变量更改了几次，只是单纯的关心是否更改过，所以就有了AtomicMarkableReference
AtomicMarkableReference的唯一区别就是不再用int标识引用，而是使用boolean变量——表示引用变量是否被更改过
示例
public class ABADemo {
private static AtomicMarkableReference<Integer> atomicMarkableReference = new AtomicMarkableReference<Integer>(100,false);
public static void main(String[] args) {
new Thread(() -> {
System.out.println("t1版本号是否被更改:" + atomicMarkableReference.isMarked());
//睡眠1秒，是为了让t2线程也拿到同样的初始版本号
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicMarkableReference.compareAndSet(100, 101,atomicMarkableReference.isMarked(),true);
atomicMarkableReference.compareAndSet(101, 100,atomicMarkableReference.isMarked(),true);
},"t1").start();
new Thread(() -> {
boolean isMarked = atomicMarkableReference.isMarked();
System.out.println("t2版本号是否被更改:" + isMarked);
//睡眠3秒，是为了让t1线程完成ABA操作
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("是否更改过:" + atomicMarkableReference.isMarked());
System.out.println(atomicMarkableReference.compareAndSet(100, 2019,isMarked,true) + "\t当前 值:" + atomicMarkableReference.getReference());
},"t2").start();
}
}
1、初始值100，初始版本号未被修改 false
2、线程t1和t2拿到一样的初始版本号都未被修改 false
3、线程t1完成ABA操作，版本号被修改 true
4、线程t2完成CAS操作，版本号已经变成true，跟线程t2之前拿到的版本号false不相等，操作失败
输出结果：
t1版本号是否被更改:false
t2版本号是否被更改:false
是否更改过:truefalse
当前 值:100
Java乐观锁实现之CAS操作
介绍CAS操作前，我们先简单看一下乐观锁 与 悲观锁这两个常见的锁概念。
悲观锁：
从Java多线程角度，存在着“可见性、原子性、有序性”三个问题，悲观锁就是假设在实际情况中存在着多线程对同一共享的竞争，所以在操作前先占有共享资源（悲观态度）。因此，悲观锁是阻塞，独占的，存在着频繁的线程上下文切换，对资源消耗较大。synchronized就是悲观锁的一种实现。
乐观锁：
如名一样，每次操作都认为不会发生冲突，尝试执行，并检测结果是否正确。如果正确则执行成功，否则说明发生了冲突，回退再重新尝试。乐观锁的过程可以分为两步：冲突检测 和 数据更新。在Java多线程中乐观锁一个常见实现即：CAS操作。
在数据库中，悲观锁的流程如下：
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
MySQL InnoDB中使用悲观锁：
要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0;
//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;
上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。
上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。
优点与不足
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。
使用版本号实现乐观锁
使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。
1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};
优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
synchronized和Lock的异同
JAVA语言使用两种机制来实现堆某种共享资源的同步，synchronized和Lock。其中，synchronized使用Object对象本身的notify、wait、notifyAll调度机制，而lock可以使用Condition进行线程之间的调度，完成synchronized实现所有功能。
具体而言，两者的主要区别主要表现在以下几个方面：
1）用法不一样。在需要同步的对象中加入synchronized控制，synchronized既可以加在方法上，也可以加在特定代码中，括号中表示需要锁的对象。而Lock需要显示的指定起始位置和终点位置。synchronized是托管给JVM执行的，而Lock的锁定是通过代码实现的，它有比synchronized更精确的线程定义
2）性能不一样。在JDK 5中增加的ReentrantLock。它不仅拥有和synchronized相同的并发性和内存语义，还增加了锁投票，定时锁，等候和中断锁等。它们的性能在不同情况下会不同：在资源竞争不是很激励的情况下，synchronized的性能要优于ReentrantLock，带在资源紧张很激烈的情况下，synchronized的性能会下降的很快，而ReentrantLock的性能基本保持不变。
3）锁机制不一样。synchronized获得锁和释放锁的机制都在代码块结构中，当获得锁时，必须以相反的机制去释放，并且自动解锁，不会因为异常导致没有被释放而导致死锁。而Lock需要开发人员手动去释放，并且写在finally代码块中，否则会可能引起死锁问题的发生。此外，Lock还提供的更强大的功能，可以通过tryLock的方式采用非阻塞的方式取获得锁。
虽然synchronized和Lock都可以用来实现线程同步，但最好不要同时使用两种放式，因为synchronized和ReentrantLock所使用的机制不同，但是他们是独立运行的，相当于两种类型的锁，在使用时不会影响。示例如下：
import java.util.concurrent.locks.Lock;import java.util.concurrent.locks.ReentrantLock;
public class SyncTest {
private int value;
Lock lock = new ReentrantLock();
public synchronized void addValueSync(){
this.value++;
System.out.println(Thread.currentThread().getName()+":"+value);
}
public void addValueLock(){
try {
lock.lock();
value++;
System.out.println(Thread.currentThread().getName()+":"+value);
}finally {
lock.unlock();
}
}
}
public class Main {
public static void main(String[] args){
final SyncTest st = new SyncTest();
Thread t1 = new Thread(
new Runnable(){
@Override
public void run() {
// TODO Auto-generated method stub
for(int i = 0;i<5;i++){
st.addValueSync();
try {
Thread.sleep(20);
} catch (InterruptedException e) {
// TODO: handle exception e.printStackTrace();
}
}
}}
);
Thread t2 = new Thread(
new Runnable() {
@Override
public void run() {
// TODO Auto-generated method stub
for(int i = 0;i <5 ;i++){
st.addValueLock();
try {
Thread.sleep(20);
} catch (InterruptedException e) {
// TODO: handle exception e.printStackTrace();
}
}
}
}
);
t1.start();
t2.start();
}
}
线程安全是多线程领域的问题，线程安全可以简单理解为一个方法或者一个实例可以在多线程环境中使用而不会出现问题。
在 Java 多线程编程当中，提供了多种实现 Java 线程安全的方式：
最简单的方式，使用 Synchronization 关键字
使用 java.util.concurrent.atomic 包中的原子类，例如 AtomicInteger
使用 java.util.concurrent.locks 包中的锁
使用线程安全的集合 ConcurrentHashMap
使用 volatile 关键字，保证变量可见性（直接从内存读，而不是从线程 cache 读）
来源：https://www.cnblogs.com/day-day--up/p/12290279.html