微服务知识02

1、九大高并发解决方案

2、系统架构图​​​​​​​

3、分布式事务

本地事务、分布式事务

操作不同服务器的数据库（垂直分库）

4、分布式事务解决方案（没有seata之前）

（1）XA协议（强一致性）

（单节点 不能用集群，没有办法保证）数据库节点的解决方案

        1）2pc二阶段提交

        2）3pc三阶段提交

（2）SAGE（XA优化）

（3）TCC（类似3pc）业务解决方案（强一致性）

（4）MQ事务（最终一致性）支持事务消息

（5）本地消息表（最终一致性）

 （6）最大努力通知（MQ优化）事务发起者增加事务的校验接口（最终一致性）

5、mysql日志

Mysql主要有三种日志: Redo log、 Undo log、Binlog

undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。
redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复，事务持久化；
binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制

6、XA协议原理

        （1）2pc 二阶段提交（东西写到日志文件中）五步

缺点：性能、阻塞问题 ，可用性（订单协调者参与者，那就不能用集群[事务失效]->单节点）

、数据一致性（commit后，部分服务器异常）

        1）准备阶段

发起与处理请求

数据未提交

通知事务管理器yes/no

        2）提交阶段

事务管理器发起提交

数据库提交

（3）3pc 三阶段提交

数据库级别

缺点：可用性（单节点问题）、数据不一致（磁盘满了写入失败、同时操作、发送中断请求瞬间已经写好了）、数据库必须支持事务

准备阶段引入的超时机制

预备阶段 

 7、TCC（空回挂问题）

优点：不需要要数据库支持事务、应用程序级别的操作、并发高（可以不用加锁）

缺点：复杂（自己操作），空悬挂问题，

空回滚	在没有调用TCC资源Try方法得情况下，调用了二阶段得Cancel方法，Cancel方法需要识别出这是一个空回滚，然后直接返回成功	当一个分支事务所在服务宕机或者网络异常，分支事务调用记录为失败，这个时候其实还没有执行Try阶段的，当故障恢复后，分支事务进行回滚则会调用二阶段得Cancel方法，从而形成空回滚。

​​​​​​​​​​​​​​

空回滚
在没有调用TCC资源Try方法得情况下，调用了二阶段得Cancel方法，Cancel方法需要识别出这是一个空回滚，然后直接返回成功。

出现原因
当一个分支事务所在服务宕机或者网络异常，分支事务调用记录为失败，这个时候其实还没有执行Try阶段的，当故障恢复后，分支事务进行回滚则会调用二阶段得Cancel方法，从而形成空回滚。

解决思路
解决的关键就是要识别出这个空回滚。方法很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。TM在发起全局事务时会生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。可以再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

幂等
TCC模式在Try阶段执行成功后必须保证二阶段也成功执行，所以二阶段需要有重试机制。

幂等出现原因
为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

解决思路

在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态，如果是未执行的状态则执行否则不执行。
 

悬挂
悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

出现原因
在 RPC(远程访问) 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者并且真正执行成功，而此时Try 方法才执行完成并且将所需的业务资源预留，但是此时二阶段已经完成无法对预留的资源做出处理。对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。

解决思路
是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

8、CAP定律（分布式系统必须遵守规则）

（1）C 一致性 （在分布式接口中读取节点数据，必须保证准确性）

强一致性	订单数据保存成功，库存必须更新成功（本地事务）
最终一致性
弱一致性

（2）A可用性 （分布式系统中每个请求都应该得到响应）

（3）P分区容错性（如果某个分区出现了故障系统必须还能正常对外提供服务）

9、一般是AP、CP

10、Seata

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式

TC (Transaction Coordinator) - 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器

管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

 

11、Seata模式

（1）AT事务模式 （2w+并发会出bug）

基于支持本地 ACID 事务的关系型数据库

Java 应用，通过 JDBC 访问数据库

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

• 二阶段：

  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

优点：对程序侵入性小

缺点：必须支持事务，使用全局锁，性能比TCC差

原理：

（2）TCC模式

12、Seata

• 基于消息实现的分布式事务
• 基于补偿实现的分布式事务
• 基于TCC实现的分布式事务
• 基于SAGA实现的分布式事务
• 基于2PC、3PC实现的分布式事务

12、Seata分布式事务部署流程

（1）新建文件docker-compose.yml

​​​​​​​​​​​​​​

version: "3.1"
services:
  seata-server:
    image: seataio/seata-server:1.6.0
    ports:
      - "7091:7091"
      - "8091:8091"

（2）修改权限

（2）部署上去 

docker-compose  up -d

（3）复制 （容器id：固定的东西）

docker ps
docker  cp  dab3007fb00e:/seata-server/resources ./

（4）修改resources里面的application.yml

server:
  port: 7091
spring:
  application:
    name: seata-server

logging:
  config: classpath:logback-spring.xml
console:
  user:
    username: seata
    password: seata  
seata:
  config:
    type: nacos
    nacos:
      server-addr: 129.204.151.181:8848
      group: SEATA_GROUP
      data-id: seataServer.properties
  registry:
    type: nacos
    nacos:
      application: seata-server
      server-addr: 129.204.151.181:8848
      group: SEATA_GROUP
  security:
    secretKey: SeataSecretKey0c382ef121d778043159209298fd40bf3850a017
    tokenValidityInMilliseconds: 1800000
    ignore:
      urls: /,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/api/v1/auth/login

（5）启动nacos （id：8848）

（6）进入nacos配置配置中心

（7）在配置中心建一个远程配置文件 seataServer.properties

data id、Group在application.yml里面（步骤4）

​​​​​​​ 

transport.type=TCP
transport.server=NIO
transport.heartbeat=true
transport.enableTmClientBatchSendRequest=false
transport.enableRmClientBatchSendRequest=true
transport.enableTcServerBatchSendResponse=false
transport.rpcRmRequestTimeout=30000
transport.rpcTmRequestTimeout=30000
transport.rpcTcRequestTimeout=30000
transport.threadFactory.bossThreadPrefix=NettyBoss
transport.threadFactory.workerThreadPrefix=NettyServerNIOWorker
transport.threadFactory.serverExecutorThreadPrefix=NettyServerBizHandler
transport.threadFactory.shareBossWorker=false
transport.threadFactory.clientSelectorThreadPrefix=NettyClientSelector
transport.threadFactory.clientSelectorThreadSize=1
transport.threadFactory.clientWorkerThreadPrefix=NettyClientWorkerThread
transport.threadFactory.bossThreadSize=1
transport.threadFactory.workerThreadSize=default
transport.shutdown.wait=3
transport.serialization=seata
transport.compressor=none
# 声明事务组
service.vgroupMapping.order_tx_group=default
#service.vgroupMapping.member_tx_group=default
# service.vgroupMapping.coupon_tx_group=default

service.disableGlobalTransaction=false

client.metadataMaxAgeMs=30000
#Transaction rule configuration, only for the client
client.rm.asyncCommitBufferLimit=10000
client.rm.lock.retryInterval=10
client.rm.lock.retryTimes=30
client.rm.lock.retryPolicyBranchRollbackOnConflict=true
client.rm.reportRetryCount=5
client.rm.tableMetaCheckEnable=true
client.rm.tableMetaCheckerInterval=60000
client.rm.sqlParserType=druid
client.rm.reportSuccessEnable=false
client.rm.sagaBranchRegisterEnable=false
client.rm.sagaJsonParser=fastjson
client.rm.tccActionInterceptorOrder=-2147482648
client.rm.sqlParserType=druid
client.tm.commitRetryCount=5
client.tm.rollbackRetryCount=5
client.tm.defaultGlobalTransactionTimeout=60000
client.tm.degradeCheck=false
client.tm.degradeCheckAllowTimes=10
client.tm.degradeCheckPeriod=2000
client.tm.interceptorOrder=-2147482648
client.undo.dataValidation=true
client.undo.logSerialization=jackson
client.undo.onlyCareUpdateColumns=true
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000
client.undo.logTable=undo_log
client.undo.compress.enable=true
client.undo.compress.type=zip
client.undo.compress.threshold=64k
#For TCC transaction mode
tcc.fence.logTableName=tcc_fence_log
tcc.fence.cleanPeriod=1h
# You can choose from the following options: fastjson, jackson, gson
tcc.contextJsonParserType=fastjson

#Log rule configuration, for client and server
log.exceptionRate=100

store.mode=db
store.lock.mode=db
store.session.mode=db

store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://129.204.151.181:3307/seata-server?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
store.db.user=root
store.db.password=lht660036
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.distributedLockTable=distributed_lock
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000


#Transaction rule configuration, only for the server
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.distributedLockExpireTime=10000
server.session.branchAsyncQueueSize=5000
server.session.enableBranchAsyncRemove=false
server.enableParallelRequestHandle=true
server.enableParallelHandleBranch=false
server.applicationDataLimit=64000
server.applicationDataLimitCheck=false

server.raft.server-addr=127.0.0.1:7091,127.0.0.1:7092,127.0.0.1:7093
server.raft.snapshotInterval=600
server.raft.applyBatch=32
server.raft.maxAppendBufferSize=262144
server.raft.maxReplicatorInflightMsgs=256
server.raft.disruptorBufferSize=16384
server.raft.electionTimeoutMs=2000
server.raft.reporterEnabled=false
server.raft.reporterInitialDelay=60
server.raft.serialization=jackson
server.raft.compressor=none
server.raft.sync=true


#Metrics configuration, only for the server
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898

1. 1）修改事务组

1. 2）修改持久化模式

（8）创建数据库mysql（或者用Docker的）

        1)新建docker-compose.yml

version: '3'
services:
  mysql-3307:
    image: mysql
    container_name: mysql-3307
    hostname: mysql3307
    ports:
      - '3307:3306'
    environment:
      MYSQL_ROOT_PASSWORD: lht660036
      MYSQL_USER: mysql
      MYSQL_PASSWORD: mysql
      TZ: Asia/Shanghai
    volumes:
      - ./mysql/data:/var/lib/mysql
      - ./mysql/log:/var/log/mysql

        2）给权限，执行 

​​​​​​​

        3)新建数据库

（9）加入以下表

https://github.com/apache/incubator-seata/blob/develop/script/server/db/mysql.sql

-- -------------------------------- The script used when storeMode is 'db' --------------------------------
-- the table to store GlobalSession data
CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR(128) NOT NULL,
    `transaction_id`            BIGINT,
    `status`                    TINYINT      NOT NULL,
    `application_id`            VARCHAR(32),
    `transaction_service_group` VARCHAR(32),
    `transaction_name`          VARCHAR(128),
    `timeout`                   INT,
    `begin_time`                BIGINT,
    `application_data`          VARCHAR(2000),
    `gmt_create`                DATETIME,
    `gmt_modified`              DATETIME,
    PRIMARY KEY (`xid`),
    KEY `idx_status_gmt_modified` (`status` , `gmt_modified`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

-- the table to store BranchSession data
CREATE TABLE IF NOT EXISTS `branch_table`
(
    `branch_id`         BIGINT       NOT NULL,
    `xid`               VARCHAR(128) NOT NULL,
    `transaction_id`    BIGINT,
    `resource_group_id` VARCHAR(32),
    `resource_id`       VARCHAR(256),
    `branch_type`       VARCHAR(8),
    `status`            TINYINT,
    `client_id`         VARCHAR(64),
    `application_data`  VARCHAR(2000),
    `gmt_create`        DATETIME(6),
    `gmt_modified`      DATETIME(6),
    PRIMARY KEY (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

-- the table to store lock data
CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(128),
    `transaction_id` BIGINT,
    `branch_id`      BIGINT       NOT NULL,
    `resource_id`    VARCHAR(256),
    `table_name`     VARCHAR(32),
    `pk`             VARCHAR(36),
    `status`         TINYINT      NOT NULL DEFAULT '0' COMMENT '0:locked ,1:rollbacking',
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_status` (`status`),
    KEY `idx_branch_id` (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

CREATE TABLE IF NOT EXISTS `distributed_lock`
(
    `lock_key`       CHAR(20) NOT NULL,
    `lock_value`     VARCHAR(20) NOT NULL,
    `expire`         BIGINT,
    primary key (`lock_key`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('AsyncCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryCommitting', ' ', 0);
INSERT INTO `distributed_