组件（lvs,keeplive,orm,mysql，分布式事务）

lvs  

      LVS 已经集成到Linux内核系统中，ipvsadm 是 LVS 的命令行管理工具。
    目前有三种 IP 负载均衡技术（ VS/NAT 网络地址转换 、VS/TUN  IP 隧道技术实现虚拟服务器 和 VS/DR  直接路由）；
    八种调度算法：轮询 round robin,加权轮询调度,最小连链接读，加权最少链接调度，目标地址散列，源地址散列。

 keeplive

keeplive c语言编写路由软件，基础linux 提供负载和高可用功能
    VRRP实现了高可用性 协议，VRRP是路由器故障转移的基础。是一个基于 VRRP 协议来实现的服务高可用方案，可以利用其来避免 IP 单点故障，一般与其它负载均衡技术（如 LVS 、HAProxy 、Nginx）一起工作来达到集群的高可用。
    Keepalived 工作在 TCP/IP 参考模型的第三、第四和第五层，也就是网络层、传输层和应用层
       在网络层，运行着四个重要的协议：互连网协议 IP、互连网控制报文协议 ICMP、地址转换协议 ARP 以及反向地址转换协议 RARP。
　　Keepalived 在网络层采 用的最常见的工作方式是通过ICMP协议向服务器集群中的每个节点发送一个 ICMP 的数据包（类似于 ping 实现的功能），如果某个节点没有返回响应数据包，那么 就认为此节点发生了故障，Keepalived 将报告此节点失效，并从服务器集群中剔除故障节点。
在传输层，提供了两个主要的协议：传输控制协议 TCP 和用户数据协议 UDP。传输控制协议 TCP 可以提供可靠的数据传输服务，IP 地址和端口，代表一个 TCP 连接的 一个连接端。
要获得 TCP 服务,须在发送机的一个端口上和接收机的一个端口上建立连接，而 Keepalived 在传输层就是利用 TCP 协议的端口连接和扫描技术来 判断集群节点是否正常的。
比如，对于常见的 Web 服务默认的 80 端口、SSH 服务默认的 22 端口等，Keepalived 一旦在传输层探测到这些端口没有响应数据返回， 就认为这些端口发生异常，然后强制将此端口对应的节点从服务器集群组中移除。
 在应用层，可以运行 FTP、TELNET、SMTP、DNS 等各种不同类型的高层协议，Keepalived 的运行方式也更加全面化和复杂化，用户可以通过自定义 Keepalived 的工作方式，
例如用户可以通过编写程序来运行 Keepalived，而 Keepalived 将根据用户的设定检测各种程序或服务是否允许正常，如果 Keepalived 的检测结果 与用户设定不一致时，Keepalived 将把对应的服务从服务器中移除。

orm 

  jdbc    
1.加载驱动class.forname("com.mysql.jbdc.Drive");
2.通过驱动管理类获取数据库连接 Connect connect=       DriverManager.getConnect("jdbc:mysql://localhost:3306/test", "root", "123")
3.获取预处理的statement   preparedStatement = connection.prepareStatement(sql);
4.向数据库发出sql执行查询，查询出结果集  resultSet =  preparedStatement.executeQuery();

 Hibernate、mybits 
//1.加载classpath路径下的配置文件/hibernate.cfg.xml
    InputStram  in  =Resource.getResourceAsStram("mybits-config.xml");
//2. 根据加载配置文件产生的输入流穿件一个SqlsessionFactory
    SqlsessionFactory  sessionFactory=new SqlSessionFacotyBuilder().build(in);
//3.根据SqlSessionFactory创建Sqlsession
             SqlSession  session = sesssionFactory.openSesion();
//4.创建并启动事务Transation
//5.提交事务
//6.关闭session/sessionFactory

总结：通过SqlSessionFactoryBuilder从mybatis-config.xml配置文件中构建出SqlSessionFactory，
然后，SqlSessionFactory的实例直接开启一个SqlSession，再通过SqlSession实例获得Mapper对象并运行Mapper映射的SQL语句，完成对数据库的CRUD和事务提交，之后关闭SqlSession。

mysql  架构

主从：读写分离；半同步复制，默认是异步复制，全同步复制
MHA（ master High availabilty） 高可用；一主多从，至少三台，自动故障转移， 半同步复制
mgr集群；MySQL Group Replication(mysql 组复制)，是MySQL官方于2016年推出的一个全新的高可用扩展解决方案。是一种基于paxos协议的状态机复制
    主主，一主多从,多主多从

分布式事务

前提

各系统的所有操作应当保证幂等。

两段提交（2PC）

               角色：协调者和参与者；协调者向参与者进行预提交，收到回应commit;

流程图

 

二阶段提交看似能够提供原子性的操作，但它存在着严重的缺陷

• 网络抖动导致的数据不一致： 第二阶段中协调者向参与者发送commit命令之后，一旦此时发生网络抖动，导致一部分参与者接收到了commit请求并执行，可其他未接到commit请求的参与者无法执行事务提交。进而导致整个分布式系统出现了数据不一致。

• 超时导致的同步阻塞问题： 2PC中的所有的参与者节点都为事务阻塞型，当某一个参与者节点出现通信超时，其余参与者都会被动阻塞占用资源不能释放。

• 单点故障的风险： 由于严重的依赖协调者，一旦协调者发生故障，而此时参与者还都处于锁定资源的状态，无法完成事务commit操作。虽然协调者出现故障后，会重新选举一个协调者，可无法解决因前一个协调者宕机导致的参与者处于阻塞状态的问题。

三段提交（3PC）

               3PC比2PC多了一个询问阶段，也就是准备、预提交、提交

三段提交（3PC）是对两段提交（2PC）的一种升级优化，3PC在2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前，各参与者节点的状态都一致。同时在协调者和参与者中都引入超时机制，当参与者各种原因未收到协调者的commit请求后，会对本地事务进行commit，不会一直阻塞等待，解决了2PC的单点故障问题，但3PC 还是没能从根本上解决数据一致性的问题。

 

TCC（Try-Confirm-Cancel）又被称补偿事务

    TCC核心思想："针对每个操作都要注册一个与其对应的确认（Try）和补偿（Cancel）"。

参考：https://www.cnblogs.com/chengxy-nds/p/12465423.html

Seata 是一款阿里开源的分布式事务解决方案