小菜鸟

悲观锁和乐观锁

悲观锁

悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次拿数据是都会上锁，如数据库中的行锁、表锁、读锁、写锁等操作都会上锁，java中的synchronized就是悲观锁的思想

任何的数据操作都会有数据加锁、用户态内核态切换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等操作

如：synchronized、ReentrantLock等都是悲观锁

ReentrantLock虽然使用的是CAS，但是其CAS是对于锁的获取，所以一开始就上锁了。与乐观锁在拿数据时不上锁的理念是不一样的，不是所有用了CAS操作的都是乐观锁

乐观锁

乐观锁总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候回判断一下在此期间别人有没有更新这条数据，可以使用版本号机制和CAS算法实现。乐观锁适用于读多写少的情况，可以提升吞吐量，如java的atomic包下的原子变量类就是使用了CAS来实现的乐观锁

乐观锁不需要线程挂起，所以也叫做非阻塞同步

如：Atomic类都是乐观锁

elasticsearch过程分析

写到哪个分片？

写索引是只能写在主分片上，然后同步到副本。那么如何确定写到哪个分片呢？这个在分片那篇文章中也有提到shard = hash(routing) % number_of_primary_shards

routing默认是文档的_id，也可以自定义

索引文档

当用户向一个节点提交了一个创建文档的请求，节点会计算文档应该加入到哪个分片中，每个节点都存储了每个分片存储在哪个节点的信息，因此协调节点会将请求发送到对应的节点，当主分片完成索引，会将请求发送到所有的副本，保持每个分片的数据都是最新的

每次写入新文档时，都会先写到内存中，然后将这一操作写入translog文件中，此时如果执行搜索，是无法索引到对应文档的。elasticsearch会每隔一段时间进行一次刷新操作，此时内存中的文档会被写入file system cache中，并构成一个segment，此时segment内的文档可以被搜索到，但是还未写入磁盘，如果发生断电，这些文档仍可能丢失。

为了避免丢失数据，会将没有持久化到磁盘的数据写入到事务日志记录，translog文件中

数据一致性

数据一致性的问题其实是对分布式事务的另一种解释，分布式事务就是希望在多机环境下可以像单机一样实现强一致性，但是这种强一致性付出的代价很大，而在很多场景下，其实是不需要做到强一致性的，只要最终一致就行。

这里来了解一下数据一致性的基础理论CAP和BASE

CAP

CAP表示三个单词，Consistency、Availability、Partition-Tolerance，这里就三个单词分别进行说明

• Consistency 所有的节点在同一时间读到同样的数据，也就是数据的一致性，当数据写入成功后，所有的节点会同时看到这个新的数据
• Availability 保证无论成功还是失败，每个请求都能够在有限的时间内收到一个反馈，也就是数据的可用性
• Partition-Tolerance 分布式系统在遇到任何网络分区故障时，仍需要保证对外提供一致性和可用性的服务，除非是整个网络环境都发生了故障

分布式系统中的各个节点在不同的网络中，这意味着必然会有网络断开的风险，所以网络分区肯定无法避免。

在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，就导致了一致性无法满足，除非我们牺牲可用性，暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。

在系统中，我们不能够同时满足上述三项，只能满足两项

• CA 放弃分区容忍性，加强一致性和可用性，也就是传统的单机架构，放弃P也就放弃了可扩展性
• AP 放弃一致性，追求分区容忍性以及可用性。这里是指放弃强一致性，使用最终一致性，不等待复制完成，只在主分片写完后直接返回
• CP 放弃可用性，追求一致性和分区容忍性。如果遇到网络分区问题或其他故障时，复制操作可能会被延后，受到影响的服务需要等待一段时间，导致无法在有限的时间内返回数据，失去了可用性

分布式事务

事务具有四个特征ACID，分别为原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)，在单机数据库中很容易实现，但在分布式数据库中，数据分散在不同的机器上，如何对这些数据进行分布式的事务处理呢？

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

分布式事务模型和规范

The Open Group提出了一个分布式事务规范-XA，以及分布式事务处理模型-X/OpenDTP模型

X/OpenDTP模型

该模型中定义了三个组件，即Application Program，Resource Manager和Transaction Manager

• Application Program AP，即应用程序，可以理解为使用DTP模型的程序，定义了事务边界，并定义了构成该事务的应用程序的特定操作

• Resource Manager RM，即资源管理器，可以理解为DBMS系统，应用程序通过资源管理器对资源进行控制，资源管理器能够提供单数据库的事务能力，通过XA接口将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理，资源必须实现XA定义的接口，资源管理器提供了存储共享资源的支持

  XA接口是DTP模型定义的接口，用于向事务管理器提供该资源管理器的提交、回滚能力

• Transaction Manager TM，即事务管理器，负责协调和管理事务，提供给AP应用程序编程接口并管理资源管理器。事务管理器向事务指定标识，监视它们的的进程，并负责处理事务的完成和失败。事务分支标识(XID)由TM指定，以标识一个RM内的全局事务和特定分支，它是TM中日志与RM中日志之间的相关标记。两阶段提交或者回滚需要XID，以便在系统启动时执行再同步操作

  事务管理器还管理着所有的资源管理器，通过它们提供的XA接口来统一调度这些资源管理器，以实现分布式事务

  DTP只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，TM可以采用2PC、3PC、Paxos等协议实现分布式事务。

maven转为web项目

只需要三步，就可以将一个普通的maven项目变为一个web项目

• 在main目录下，添加webapp目录
• 在webapp目录下，添加WEB-INF目录
• 在WEB-INF目录下，添加web.xml文件

打包方式改为war(Maven默认使用的是jar打包方式)

1
2
3
4

<groupId>com.zhanghe.study</groupId>
<artifactId>study-maven</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>

注意一下，maven的web项目默认目录结构为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

目录结构
    src  源码 主程序
        main
            - java  源文件
            - resources  框架配置文件 
        test
            - java
            - resources
        webapp  
          - WEB-INF
              - web.xml
          - img
          - css
          - js
    pom.xml