dubbo负载均衡策略和集群容错策略都有哪些？
负载均衡策略
-
Random(随机)默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了
-
Round Robin(轮询)还有roundrobin loadbalance，这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些
-
Least Active(最少活跃)这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求
-
Consistent Hash(一致性哈希)一致性Hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大
集群容错策略
-
Fail over失败自动切换，自动重试其他机器，默认就是这个，常见于读操作
-
Fail fast一次调用失败就立即失败，常见于写操作
-
Fail safe出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
-
Fail back失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种
-
Forking并行调用多个provider，只要一个成功就立即返回
-
Broadcacst逐个调用所有的provider
动态代理策略呢？
默认使用javassist动态字节码生成，创建代理类
但是可以通过spi扩展机制配置自己的动态代理策略
dubbo的spi思想是什么？
简单来说就是service provider interface，说白了是什么意思呢，比如你有个接口，现在这个接口有3个实现类，那么在系统运行的时候对这个接口到底选择哪个实现类呢？这就需要spi了，需要根据指定的配置或者是默认的配置，去找到对应的实现类加载进来，然后用这个实现类的实例对象。
接口A -> 实现A1，实现A2，实现A3
配置一下，接口A = 实现A2
在系统实际运行的时候，会加载你的配置，用实现A2实例化一个对象来提供服务
比如说你要通过jar包的方式给某个接口提供实现，然后你就在自己jar包的META-INF/services/目录下放一个跟接口同名的文件，里面指定接口的实现里是自己这个jar包里的某个类。ok了，别人用了一个接口，然后用了你的jar包，就会在运行的时候通过你的jar包的那个文件找到这个接口该用哪个实现类。
这是jdk提供的一个功能。
比如说你有个工程A，有个接口A，接口A在工程A里是没有实现类的 -> 系统在运行的时候，怎么给接口A选择一个实现类呢？
你就可以自己搞一个jar包，META-INF/services/，放上一个文件，文件名就是接口名，接口A，接口A的实现类=com.xxx.service.实现类A2。让工程A来依赖你的这个jar包，然后呢在系统运行的时候，工程A跑起来，对接口A，就会扫描自己依赖的所有的jar包，在每个jar里找找，有没有META-INF/services文件夹，如果有，在里面找找，有没有接口A这个名字的文件，如果有在里面找一下你指定的接口A的实现是你的jar包里的哪个类？
SPI机制，一般来说用在哪儿？插件扩展的场景，比如说你开发的是一个给别人使用的开源框架，如果你想让别人自己写个插件，插到你的开源框架里面来，扩展某个功能。
经典的思想体现，大家平时都在用，比如JDBC
java定义了一套jdbc的接口，但是java是没有提供jdbc的实现类
但是实际上项目跑的时候，要使用JDBC接口的哪些实现类呢？一般来说，们要根据自己使用的数据库，比如MySQL，你就将mysql-jdbc-connector.jar，引入进来；oracle，你就将oracle-jdbc-connector.jar，引入进来。
在系统跑的时候，碰到你使用JDBC的接口，他会在底层使用你引入的那个jar中提供的实现类
但是dubbo也用了spi思想，不过没有用jdk的spi机制，是自己实现的一套spi机制。
Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
Protocol接口，dubbo要判断一下，在系统运行的时候，应该选用这个Protocol接口的哪个实现类来实例化对象来使用呢？
他会去找一个你配置的Protocol，他就会将你配置的Protocol实现类，加载到jvm中来，然后实例化对象，就用你的那个Protocol实现类就可以了
微内核，可插拔，大量的组件，Protocol负责rpc调用的东西，你可以实现自己的rpc调用组件，实现Protocol接口，给自己的一个实现类即可。
这行代码就是dubbo里大量使用的，就是对很多组件，都是保留一个接口和多个实现，然后在系统运行的时候动态根据配置去找到对应的实现类。如果你没配置，那就走默认的实现好了，没问题。
@SPI("dubbo")
public interface Protocol {
int getDefaultPort();
@Adaptive
<T> Exporter<T> export(Invoker<T> invoker) throws RpcException;
@Adaptive
<T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;
void destroy();
}
在dubbo自己的jar里，在/META_INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol文件中：
dubbo = com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol http = com.alibaba.dubbo.rpc.protocol.http.HttpProtocol hessian = com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
所以说，这就看到了dubbo的spi机制默认是怎么玩儿的了，其实就是Protocol接口，@SPI(“dubbo”)说的是，通过SPI机制来提供实现类，实现类是通过dubbo作为默认key去配置文件里找到的，配置文件名称与接口全限定名一样的，通过dubbo作为key可以找到默认的实现了就是com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol。
dubbo的默认网络通信协议，就是dubbo协议，用的DubboProtocol
如果想要动态替换掉默认的实现类，需要使用@Adaptive接口，Protocol接口中，有两个方法加了@Adaptive注解，就是说那俩接口会被代理实现。
比如这个Protocol接口搞了俩@Adaptive注解标注了方法，在运行的时候会针对Protocol生成代理类，这个代理类的那俩方法里面会有代理代码，代理代码会在运行的时候动态根据url中的protocol来获取那个key，默认是dubbo，你也可以自己指定，你如果指定了别的key，那么就会获取别的实现类的实例了。
通过这个url中的参数不通，就可以控制动态使用不同的组件实现类
好吧，那下面来说说怎么来自己扩展dubbo中的组件
自己写个工程，要是那种可以打成jar包的，里面的src/main/resources目录下，搞一个META-INF/services，里面放个文件叫：com.alibaba.dubbo.rpc.Protocol，文件里搞一个my=com.xxx.MyProtocol。自己把jar弄到nexus私服里去。
然后自己搞一个dubbo provider工程，在这个工程里面依赖你自己搞的那个jar，然后在spring配置文件里给个配置：
<dubbo:protocol name=”my” port=”20000” />
这个时候provider启动的时候，就会加载到们jar包里的my=com.xxx.MyProtocol这行配置里，接着会根据你的配置使用你定义好的MyProtocol了，这个就是简单说明一下，你通过上述方式，可以替换掉大量的dubbo内部的组件，就是扔个你自己的jar包，然后配置一下即可。
dubbo里面提供了大量的类似上面的扩展点，就是说，你如果要扩展一个东西，只要自己写个jar，让你的consumer或者是provider工程，依赖你的那个jar，在你的jar里指定目录下配置好接口名称对应的文件，里面通过key=实现类。
如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试？
服务治理
-
调用链路自动生成
一个大型的分布式系统，或者说是用现在流行的微服务架构来说吧，分布式系统由大量的服务组成。那么这些服务之间互相是如何调用的？调用链路是啥？说实话，几乎到后面没人搞的清楚了，因为服务实在太多了，可能几百个甚至几千个服务。
那就需要基于dubbo做的分布式系统中，对各个服务之间的调用自动记录下来，然后自动将各个服务之间的依赖关系和调用链路生成出来，做成一张图，显示出来，大家才可以看到对吧。
服务A -> 服务B -> 服务C
-> 服务E
-> 服务D
-> 服务F
-> 服务W
-
服务访问压力以及时长统计
需要自动统计各个接口和服务之间的调用次数以及访问延时，而且要分成两个级别。一个级别是接口粒度，就是每个服务的每个接口每天被调用多少次，TP50，TP90，TP99，三个档次的请求延时分别是多少；第二个级别是从源头入口开始，一个完整的请求链路经过几十个服务之后，完成一次请求，每天全链路走多少次，全链路请求延时的TP50，TP90，TP99，分别是多少。
这些东西都搞定了之后，后面才可以来看当前系统的压力主要在哪里，如何来扩容和优化
-
服务可用性
服务分层（避免循环依赖），调用链路失败监控和报警，服务鉴权，每个服务的可用性的监控（接口调用成功率？几个9？）99.99%，99.9%，99%
服务降级
比如说服务A调用服务B，结果服务B挂掉了，服务A重试几次调用服务B，还是不行，直接降级，走一个备用的逻辑，给用户返回响应
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd"> <dubbo:application name="dubbo-consumer" /> <dubbo:registry address="zookeeper://127.0.0.1:2181" /> <dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="return null"> </dubbo:reference> </beans>
可以将mock修改为true，然后在跟接口同一个路径下实现一个Mock类，命名规则是接口名称加Mock后缀。然后在Mock类里实现自己的降级逻辑。
public class HelloServiceMock implements HelloService { public void sayHello() { // 降级逻辑 } }
失败重试
所谓失败重试，就是consumer调用provider要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。
<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>
某个服务的接口，要耗费5s，你这边不能干等着，你这边配置了timeout之后，等待2s，还没返回，直接就撤了，不能干等你
如果是超时了，timeout就会设置超时时间；如果是调用失败了自动就会重试指定的次数
你就结合你们公司的具体的场景来说说你是怎么设置这些参数的，timeout，一般设置为200ms，们认为不能超过200ms还没返回
retries，3次，设置retries，还一般是在读请求的时候，比如你要查询个数据，你可以设置个retries，如果第一次没读到，报错，重试指定的次数，尝试再次读取2次
分布式服务接口的幂等性如何设计（比如不能重复扣款）？
保证幂等性主要三点
-
对于每个请求必须有一个唯一的标识
-
每次处理完请求之后，必须有一个记录标识这个请求处理过了
-
每次接收请求需要进行判断之前是否处理过的逻辑处理
如何自己设计一个类似dubbo的rpc框架？
-
注册中心
使用能够存储键值对的某种存储工具,比如zk redis 数据库等等,和ip:port:接口名和服务提供方的具体实现类绑定起来,然后服务端启动socket监听
-
动态代理服务消费者
消费端引入服务端提供的接口,对该接口进行动态代理,让其代理对象使用注册中心提供的IP:PORT:接口名,向服务端发起socket长连接,写入需要调用的方法名,方法参数,然后远程调用服务端的该方法,服务端将结果通过socket写入返回.
-
自定义通信协议
在socket数据传输过程中,可以定义传输协议,是使用json还是java serializable还是hessian还是protobuf等协议,这一协议,服务提供者和消费者都要遵守
-
请求负载均衡
假如有多个服务提供者提供相同的服务,需要分散消费者的远程调用请求.
分布式服务框架
zk都有哪些使用场景？
-
分布式协调(zk节点Watch机制)
这个其实是zk很经典的一个用法，简单来说，就好比，你A系统发送个请求到mq，然后B消息消费之后处理了。那A系统如何知道B系统的处理结果？用zk就可以实现分布式系统之间的协调工作。A系统发送请求之后可以在zk上对某个节点的值注册个监听器，一旦B系统处理完了就修改zk那个节点的值，A立马就可以收到通知，完美解决。
-
分布式锁(创建有序临时节点)
对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行另外一个机器再执行。那么此时就可以使用zk分布式锁，一个机器接收到了请求之后先获取zk上的一把分布式锁，就是可以去创建一个znode，接着执行操作；然后另外一个机器也尝试去创建那个znode，结果发现自己创建不了，因为被别人创建了。。。。那只能等着，等第一个机器执行完了自己再执行
-
配置信息管理
通过客户端向zk注册一个配置节点监听器,一旦zk上的配置节点新增了配置或者修改了配置,客户端都会受到zk发来的消息
-
高可用性
比如hadoop、hdfs、yarn等很多大数据系统，都选择基于zk来开发HA高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过zk感知到切换到备用进程
分布式锁
一般实现分布式锁都有哪些方式？
-
redis单机实现(setNX)
最普通的实现方式，如果就是在redis里创建一个key算加锁
SET my:lock 随机值 NX PX 30000，这个命令就ok，这个的NX的意思就是只有key不存在的时候才会设置成功，PX 30000的意思是30秒后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了。
释放锁就是删除key，但是一般可以用lua脚本删除，判断value一样才删除：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
为啥要用随机值呢？因为如果某个客户端获取到了锁，但是阻塞了很长时间才执行完，此时可能已经自动释放锁了，此时可能别的客户端已经获取到了这个锁，要是你这个时候直接删除
key
的话会有问题，所以得用随机值加上面的
lua
脚本来释放锁
-
redis分布式实现(RedLock算法) -----不推荐使用
在Redis的分布式环境中，们假设有N个Redis master。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。们确保将在N个实例上使用与在Redis单实例下相同方法获取和释放锁。现在们假设有5个Redis master节点，同时们需要在5台服务器上面运行这些Redis实例，这样保证他们不会同时都宕掉。
为了取到锁，客户端应该执行以下操作:
-
获取当前Unix时间，以毫秒为单位。
-
依次尝试从5个实例，使用相同的key和具有唯一性的value（例如UUID）获取锁。当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁。
-
客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的Redis节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
-
如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。
-
如果因为某些原因，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）。
-
-
zookeeper实现
zk分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时znode，此时创建成功了就获取了这个锁；这个时候别的客户端来创建锁会失败，只能注册个监听器监听这个锁。释放锁就是删除这个znode，一旦释放掉就会通知客户端，然后有一个等待着的客户端就可以再次重新枷锁
使用zk来设计分布式锁可以吗？
package com.zookeeper.java.distributed_lock; import org.apache.zookeeper.CreateMode; import org.apache.zookeeper.KeeperException; import org.apache.zookeeper.ZooDefs; import org.apache.zookeeper.ZooKeeper; import java.util.*; import java.util.concurrent.CountDownLatch; /** * zk实现分布式锁 * * @author zhuliang * @date 2019/6/19 12:17 */ public class DistributedLock { private ZooKeeper zooKeeper; private String root = "/LOCKS"; private String lockId; private int sessionTimeout; private byte[] data = {1, 2}; private CountDownLatch latch = new CountDownLatch(1); public DistributedLock() throws Exception { this.zooKeeper = ZookeeperFactory.getInstance(); this.sessionTimeout = ZookeeperFactory.getSessionTimeout(); } public boolean lock() { //创建新的临时有序节点 将其自动生成的序号返回值作为 锁id try { lockId = zooKeeper.create(root + "/", data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); System.out.println(Thread.currentThread().getName() + "-> 成功创建的lock节点[" + lockId + "] 开始竞争锁"); //获取root下所有的子节点 List<String> children = zooKeeper.getChildren(root, true); //利用treeSet排序特性将其排序 SortedSet<String> sortedSet = new TreeSet<>(); //并将其元素前面拼接上父节点路径 for (String s : children) { sortedSet.add(root + "/" + s); } //获取最小的节点 如果最小的节点存在 且等于lockId 则可以获取锁 if (sortedSet.first().equals(lockId)) { System.out.println(Thread.currentThread().getName() + "-> 成功获得锁 lock节点[" + lockId + "]"); return true; } //如果不等于lockId SortedSet<String> lessThanLockId = sortedSet.headSet(lockId); if (!lessThanLockId.isEmpty()) { //获取比当前lockId小的上一个节点 其实这个preLockId就是正在被使用的锁的id String preLockId = lessThanLockId.last(); //然后给这个正在被使用的锁 添加一个watcher 当这个锁被调用delete,get,set的时候就会触发watch时间 zooKeeper.exists(preLockId, new LockWatcher(latch)); // latch.await(sessionTimeout, TimeUnit.MILLISECONDS); latch.await(); //上面这段代码意味着如果会话超时或者节点被删除了 System.out.println(Thread.currentThread().getName() + "-> 成功获得锁[" + lockId + "]"); } return true; } catch (KeeperException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } return false; } public boolean unlock() { System.out.println(Thread.currentThread().getName() + "-> 开始施放锁[" + lockId + "]"); try { System.out.println("节点[" + lockId + "]成功被删除"); zooKeeper.delete(lockId, -1); return true; } catch (InterruptedException e) { e.printStackTrace(); } catch (KeeperException e) { e.printStackTrace(); } return false; } public static void main(String[] args) { CountDownLatch latch = new CountDownLatch(10); Random random = new Random(); for (int i = 0; i < 10; i++) { new Thread(() -> { DistributedLock lock = null; try { lock = new DistributedLock(); latch.countDown(); latch.await(); lock.lock(); Thread.sleep(random.nextInt(3000)); } catch (Exception e) { e.printStackTrace(); } finally { if (lock != null) { lock.unlock(); } } }).start(); } } } /* * 最终结果 获得锁->释放锁 是按顺序进行的 * Thread-3-> 成功创建的lock节点[/LOCKS/0000000090] 开始竞争锁 Thread-2-> 成功创建的lock节点[/LOCKS/0000000091] 开始竞争锁 Thread-7-> 成功创建的lock节点[/LOCKS/0000000093] 开始竞争锁 Thread-6-> 成功创建的lock节点[/LOCKS/0000000094] 开始竞争锁 Thread-0-> 成功创建的lock节点[/LOCKS/0000000092] 开始竞争锁 Thread-4-> 成功创建的lock节点[/LOCKS/0000000095] 开始竞争锁 Thread-1-> 成功创建的lock节点[/LOCKS/0000000096] 开始竞争锁 Thread-8-> 成功创建的lock节点[/LOCKS/0000000097] 开始竞争锁 Thread-9-> 成功创建的lock节点[/LOCKS/0000000098] 开始竞争锁 Thread-5-> 成功创建的lock节点[/LOCKS/0000000099] 开始竞争锁 Thread-3-> 成功获得锁 lock节点[/LOCKS/0000000090] Thread-3-> 开始施放锁[/LOCKS/0000000090] 节点[/LOCKS/0000000090]成功被删除 Thread-2-> 成功获得锁[/LOCKS/0000000091] Thread-2-> 开始施放锁[/LOCKS/0000000091] 节点[/LOCKS/0000000091]成功被删除 Thread-0-> 成功获得锁[/LOCKS/0000000092] Thread-0-> 开始施放锁[/LOCKS/0000000092] 节点[/LOCKS/0000000092]成功被删除 Thread-7-> 成功获得锁[/LOCKS/0000000093] Thread-7-> 开始施放锁[/LOCKS/0000000093] 节点[/LOCKS/0000000093]成功被删除 Thread-6-> 成功获得锁[/LOCKS/0000000094] Thread-6-> 开始施放锁[/LOCKS/0000000094] 节点[/LOCKS/0000000094]成功被删除 Thread-4-> 成功获得锁[/LOCKS/0000000095] Thread-4-> 开始施放锁[/LOCKS/0000000095] 节点[/LOCKS/0000000095]成功被删除 Thread-1-> 成功获得锁[/LOCKS/0000000096] Thread-1-> 开始施放锁[/LOCKS/0000000096] 节点[/LOCKS/0000000096]成功被删除 Thread-8-> 成功获得锁[/LOCKS/0000000097] Thread-8-> 开始施放锁[/LOCKS/0000000097] 节点[/LOCKS/0000000097]成功被删除 Thread-9-> 成功获得锁[/LOCKS/0000000098] Thread-9-> 开始施放锁[/LOCKS/0000000098] 节点[/LOCKS/0000000098]成功被删除 Thread-5-> 成功获得锁[/LOCKS/0000000099] Thread-5-> 开始施放锁[/LOCKS/0000000099] 节点[/LOCKS/0000000099]成功被删除 */
这两种分布式锁的实现方式哪种效率比较高？
redis分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能
zk分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小
另外一点就是，如果是redis获取锁的那个客户端bug了或者挂了，那么只能等待超时时间之后才能释放锁；而zk的话，因为创建的是临时znode，只要客户端挂了，znode就没了，此时就自动释放锁
redis分布式锁比较麻烦，遍历上锁，计算时间等等。。。zk的分布式锁语义清晰实现简单
所以先不分析太多的东西，就说这两点，个人实践认为zk的分布式锁比redis的分布式锁牢靠、而且模型简单易用
分布式事务
-
两阶段提交（2PC）
两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。
1. 运行过程
1.1 准备阶段
协调者询问参与者事务是否执行成功，参与者发回事务执行结果。
1.2 提交阶段
如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。
需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。
2. 存在的问题
2.1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。
2.2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。
2.3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
2.4 太过保守 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。
-
补偿事务（TCC）
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
-
Try 阶段主要是对业务系统做检测及资源预留
-
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
-
Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
举个例子，假入 Bob 要向 Smith 转账，思路大概是： 们有一个本地方法，里面依次调用
-
首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
-
在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
-
如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。
优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
-
-
本地消息表（异步确保）
本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。
-
在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
-
之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
-
在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。
优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。
-
-
可靠消息最终一致性方案（MQ 事务消息）
这个的意思，就是干脆不要用本地的消息表了，直接基于MQ来实现事务。比如阿里的RocketMQ就支持消息事务。
大概的意思就是：
1）A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了
3）如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地的事务
4）mq会自动定时轮询所有prepared消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认消息？那是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，别确认消息发送失败了。
5）这个方案里，要是系统B的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如B系统本地回滚后，想办法通知系统A也回滚；或者是发送报警由人工来手工回滚和补偿
这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你举用RocketMQ支持的，要不你就自己基于类似ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的
优点： 实现了最终一致性，不需要依赖本地数据库事务。
缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。
-
最大努力通知方案
这个方案的大致意思就是：
1）系统A本地事务执行完之后，发送个消息到MQ
2）这里会有个专门消费MQ的最大努力通知服务，这个服务会消费MQ然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统B的接口
3）要是系统B执行成功就ok了；要是系统B执行失败了，那么最大努力通知服务就定时尝试重新调用系统B，反复N次，最后还是不行就放弃
-
阿里GTS（Global Transaction Service）
详情见官网
分布式事务总结
其实用任何一个分布式事务的这么一个方案，都会导致你那块儿代码会复杂10倍。很多情况下，系统A调用系统B、系统C、系统D，们可能根本就不做分布式事务。如果调用报错会打印异常日志。
每个月也就那么几个bug，很多bug是功能性的，体验性的，真的是涉及到数据层面的一些bug，一个月就几个，两三个？如果你为了确保系统自动保证数据100%不能错，上了几十个分布式事务，代码太复杂；性能太差，系统吞吐量、性能大幅度下跌。
99%的分布式接口调用，不要做分布式事务，直接就是监控（发邮件、发短信）、记录日志（一旦出错，完整的日志）、事后快速的定位、排查和出解决方案、修复数据。
每个月，每隔几个月，都会对少量的因为代码bug，导致出错的数据，进行人工的修复数据，自己临时动手写个程序，可能要补一些数据，可能要删除一些数据，可能要修改一些字段的值。
比你做50个分布式事务，成本要来的低上百倍，低几十倍
trade off，权衡，要用分布式事务的时候，一定是有成本，代码会很复杂，开发很长时间，性能和吞吐量下跌，系统更加复杂更加脆弱反而更加容易出bug；好处，如果做好了，TCC、可靠消息最终一致性方案，一定可以100%保证你那快数据不会出错。
1%，0.1%，0.01%的业务，资金、交易、订单，们会用分布式事务方案来保证，会员积分、优惠券、商品信息，其实不要这么搞了
分布式会话
分布式session如何实现？
-
Tomcat + Redis
使用session的代码跟以前一样，还是基于tomcat原生的session支持即可，然后就是用一个叫做Tomcat RedisSessionManager的东西，让所有们部署的tomcat都将session数据存储到redis即可。
在tomcat的配置文件中，配置一下
<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" /> <Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager" host="{redis.host}" port="{redis.port}" database="{redis.dbnum}" maxInactiveInterval="60"/>
搞一个类似上面的配置即可，你看是不是就是用了RedisSessionManager，然后指定了redis的host和 port就ok了。
<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" /> <Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager" sentinelMaster="mymaster" sentinels="<sentinel1-ip>:26379,<sentinel2-ip>:26379,<sentinel3-ip>:26379" maxInactiveInterval="60"/>
还可以用上面这种方式基于redis哨兵支持的redis高可用集群来保存session数据，都是ok的
-
Spring Session + Redis
分布式会话的这个东西重耦合在tomcat中，如果要将web容器迁移成jetty，难道你重新把jetty都配置一遍吗？
因为上面那种tomcat + redis的方式好用，但是会严重依赖于web容器，不好将代码移植到其他web容器上去，尤其是你要是换了技术栈咋整？比如换成了spring cloud或者是spring boot之类的。还得好好思忖思忖。
所以现在比较好的还是基于java一站式解决方案，spring了。人家spring基本上包掉了大部分的们需要使用的框架了，spirng cloud做微服务了，spring boot做脚手架了，所以用sping session是一个很好的选择。
pom.xml
<dependency> <groupId>org.springframework.session</groupId> <artifactId>spring-session-data-redis</artifactId> <version>1.2.1.RELEASE</version> </dependency> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.8.1</version> </dependency>
spring配置文件中
<bean id="redisHttpSessionConfiguration" class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration"> <property name="maxInactiveIntervalInSeconds" value="600"/> </bean> <bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig"> <property name="maxTotal" value="100" /> <property name="maxIdle" value="10" /> </bean> <bean id="jedisConnectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" destroy-method="destroy"> <property name="hostName" value="${redis_hostname}"/> <property name="port" value="${redis_port}"/> <property name="password" value="${redis_pwd}" /> <property name="timeout" value="3000"/> <property name="usePool" value="true"/> <property name="poolConfig" ref="jedisPoolConfig"/> </bean>
web.xml
<filter> <filter-name>springSessionRepositoryFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSessionRepositoryFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
示例代码
@Controller @RequestMapping("/test") public class TestController { @RequestMapping("/putIntoSession") @ResponseBody public String putIntoSession(HttpServletRequest request, String username){ request.getSession().setAttribute("name", “leo”); return "ok"; } @RequestMapping("/getFromSession") @ResponseBody public String getFromSession(HttpServletRequest request, Model model){ String name = request.getSession().getAttribute("name"); return name; } }
上面的代码就是ok的，给spring session配置基于redis来存储session数据，然后配置了一个spring session的过滤器，这样的话，session相关操作都会交给spring session来管了。接着在代码中，就用原生的session操作，就是直接基于spring sesion从redis中获取数据了。
实现分布式的会话，有很多种很多种方式，说的只不过比较常见的两种方式，tomcat + redis早期比较常用；近些年，重耦合到tomcat中去，通过spring session来实现。
-
不使用session（使用JWT）
使用 JWT（Java Web Token）储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓
如何设计一个高并发系统？
其实所谓的高并发，如果要理解这个问题呢，其实就得从高并发的根源出发，为什么会有高并发？
说的浅显一点，很简单，就是因为刚开始系统都是连接数据库的，但是要知道数据库支撑到每秒并发两三千的时候，基本就快完了。所以才有说，很多公司，刚开始干的时候，技术比较low，结果业务发展太快，有的时候系统扛不住压力就挂了。
当然会挂了，凭什么不挂？数据库如果瞬间承载每秒5000,8000，甚至上万的并发，一定会宕机，因为比如mysql就压根儿扛不住这么高的并发量。
所以为啥高并发牛逼？就是因为现在用互联网的人越来越多，很多app、网站、系统承载的都是高并发请求，可能高峰期每秒并发量几千，很正常的。如果是什么双十一了之类的，每秒并发几万几十万都有可能。
高并发架构
（1）系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以抗高并发么。
（2）缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以可以考虑考虑你的项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发。
（3）MQ，必须得用MQ。可能还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，你要是用redis来承载写那肯定不行，人家是缓存，数据随时就被LRU了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的，这个之前还特意说过。
（4）分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。
（5）读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。
（6）Elasticsearch，可以考虑用es。es是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来抗更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用es来承载，还有一些全文搜索类的操作，也可以考虑用es来承载。
上面的6点，基本就是高并发系统肯定要干的一些事儿，大家可以仔细结合之前讲过的知识考虑一下，到时候你可以系统的把这块阐述一下，然后每个部分要注意哪些问题，之前都讲过了，你都可以阐述阐述，表明对这块是有点积累的。
说句实话，毕竟真正厉害的一点，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样？其实实际上在真正的复杂的业务系统里，做高并发要远远比这个图复杂几十倍到上百倍。需要考虑，哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何join，哪些数据要放到缓存里去啊，放哪些数据再可以抗掉高并发的请求，需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是务必复杂的，一旦做过一次，一旦做好了，在这个市场上就会非常的吃香。