SpringCloud Alibaba - Seata 四种分布式事务解决方案（TCC、Saga）+ 实践部署（下）

目录

一、Seata 分布式解决方案

1.1、TCC 模式

1.1.1、TCC 模式理论

对比 TCC 和 AT 模式的一致性和隔离性

TC 的工作模型

1.2.2、TCC 模式优缺点

1.2.3、TCC 模式注意事项：空回滚

1.2.4、TCC 模式注意事项：业务悬挂

1.2.5、实现 TCC 模式

案例：在用户余额扣减服务中，实现 TCC 模式.

实现案例

a）TCC 的 try、confirm、cancel 方法都需要在接口中基于注解来声明

b）建表

c）对应刚刚上述所描述的实现思路，可以基本实现（未考虑空回滚 和 业务悬挂） 

d）考虑空回滚

e）幂等问题

f）业务悬挂问题

g）到此，整个业务完成.

1.2、Saga 模式

1.2.1、Saga 模式理论

1.2.2、saga 模式优缺点

一、Seata 分布式解决方案

1.1、TCC 模式

1.1.1、TCC 模式理论

TCC 模式和 AT 模式很相似，第一阶段都是独立事务，执行完了直接提交，不同的是 TCC 模式不用去加锁，也不用生成快照，因此性能上会更好.

TCC 模式的第二阶段是基于人工编码的方式来实现数据恢复的，不像 AT 是自动实现的.

人工编码的方式需要实现三个方法，分别是 try、confirm、cancel.

  • try：用来进行资源的检测和预留. 也就是说我需要修改某个资源的时候，先把这个资源预留下来，等到第二阶段的时候在对这个资源进行一个具体的操作.
  • cancel：如果第二阶段需要进行回滚，就执行 cancel. cancel 是对预留资源的一个释放（可以理解为对 try 的反向操作）.
  • confirm：完成资源业务操作（这里要求 try 成功，那么 confirm 一定要成功）.

例如现在我的账户余额是 100 元，现在要扣掉 30 元.  如果分成 try、cancel、confirm 这三个阶段.

  1. try 阶段：做资金的检测和预留.  检测就是判断余额够不够（当前余额为 100，要扣 30 肯定是够的）.  预留就是说如果余额充足，就先把要扣的 30 元金额冻结起来，也就是说可用余额扣减 30，冻结金额增加 30，而总金额是没有变化的.
  2. confirm 阶段：如果 try 阶段执行成功了，就会执行 confirm 进行提交.  这里就提交就是直接把 try 阶段冻结的 30 元金额直接扣掉，因此总金额就变成 70 元了.
  3. cancel 阶段：如果有人在执行 try 阶段失败了，就要执行 cancel 进行回滚.  这里就是对 try 阶段的一个反向操作.  在 try 阶段冻结的30元余额解冻，可用余额也就增加了 30.   因此从 try 到 cancel 可以看到总金额是没有变化的，变化的仅仅是冻结的部分.
对比 TCC 和 AT 模式的一致性和隔离性

一致性：首先第一阶段两个模式都是各自提交各自的事务，因此两种模式都有可能出现提交成功和失败的情况，导致状态不一致，需要通过第二阶段来调整.  也就是说这两种模式都是最终一致性.

隔离性：AT 模式是需要通过加锁实现隔离（在第一、第二阶段持有全局锁），而 TCC 模式下不需要加锁隔离，因为在第一阶段是通过冻结来实现隔离（冻结了一部分金额），就算此时有另一个事务也要冻结金额，那就直接从可用余额中取一部分冻结，所以事务之间都没有任何影响，不需要加锁，那么 TCC 模式的性能就要比 AT 模式好很多了.

TC 的工作模型

第一阶段：

这里大部分都和 AT 很像，一开始都是由 TM 去开启全局事务并注册到 TC 上面，然后 TM 去通知每一个分支事务去执行，然后请求被 RM 拦截，RM 就会先去注册分之十五，然后去执行 try 预留资源，执行完后直接提交，随后向 TC 报告事务的状态（资源预留执行成功了？还是失败了）.

第二阶段：

TM 通知 TC 事务结束了，那么 TC 就要对事务的状态做判断了.  如果分支预留资源成功了，就直接执行 confirm 提交即可；如果发现其中任意一个有问题，就要执行 cancel 逻辑.

1.2.2、TCC 模式优缺点

优点：

性能高：第一阶段执行完直接提交事务，并且既不用生成快照，也不用使用全局锁. 可以认为是所有分布式事务模型中性能最好的.

不依赖数据库：不需要依赖于事务性的数据库，因为是靠预留资源来做代偿的.  也就是说不仅可以使用 mysql 这种关系型数据库，也可以使用 redis 这种非关系型数据库去实现 TCC 模式.

缺点：

代码侵入高：try、confirm、cancel 这三个方法需要人工编写.

软状态，最终一致：第一阶段执行完后，直接提交事务.

考虑幂等：将来 confirm 和 cancel 可能会执行失败，Seata 看到失败了就会重试，就可能造成死循环.  因此要考虑各种健壮性.

1.2.3、TCC 模式注意事项：空回滚

问题：

在将执行某个分支事务的时候，发现执行分支事务的请求因为某种原因（网络抖动）阻塞住了，一旦阻塞的时间超过了超时时间，就会将超时的错误报告给 TC，然后 TC 就会告诉这个分支事务的 RM：“那你去回滚吧”，此时 RM 就会去执行 cancel 的业务. 

这就导致本身你没有执行 try 预留资源，现在却要执行 cancel 去释放预留资源.  比方说 try 的业务就是去冻结 30 元的余额，但是在没有进行 try 之前却要进行释放 30 元冻结余额的业务，这不就出事了吗？

解决方案：

因此这里需要做一个空回滚. 

在 try 执行请求因为某种原因阻塞时，可能会导致全局事务超时，从而先触发了 cancel 逻辑，此时根本就没有做资源预留，就不能回滚，并且也不能报错（不然 Seata 会以为 cancel 出问题了，会重试，最后导致死循环）.  那么空回滚只需要我们返回一个正常结束即可.

1.2.4、TCC 模式注意事项：业务悬挂

问题：

在执行完空回滚之后，try 逻辑的请求阻塞突然通畅，就会去执行资源预留业务，但是资源预留了之后就没有后续了（已经执行过 cancel 中的空回滚了），既没有 cancel，也没有 confirm，业务只执行了一半.  这就是业务悬挂.

比如说我本来有 100 元余额，执行完空回滚后，try逻辑突然通常，冻结了我 30 元的可用余额，然后也没有后续业务了，就导致我这 30 元有是有，但是却一直用不了.

解决办法：

在执行 try 的时候，先判断一下是否回滚过，如果回滚过了 try 就不能执行了.  同样在执行 cancel 的时候，需要判断一下，try 是不是已经执行了，如果 try 没有执行，就去做一个空回滚.

怎么知道 try 到底有没有执行过呢？这就需要在数据库中在创建一个表，用来记录事务的状态（记录上一步是执行了 try 呢？还是cancel？还是confirm？）.  

1.2.5、实现 TCC 模式

案例：在用户余额扣减服务中，实现 TCC 模式.

那么实现的思路如下：

  1. try：扣减可用余额，添加冻结金额.
  2. confirm：删除冻结金额.
  3. cancel：恢复可用金额，删除冻结金额.
  4. 注意事项：保证 confirm、cancel 接口的幂等性，注意 空回滚 和 业务悬挂.

实现案例
a）TCC 的 try、confirm、cancel 方法都需要在接口中基于注解来声明

语法如下：

@LocalTCC
public interface TCCService {/*** Try逻辑，@TwoPhaseBusinessAction中的name属性要与当前方法名一致，用于指定Try逻辑对应的方法* commitMethod 用来指定 confirm 逻辑，值必须对应自己实现的方法名. rollbackMethod 表示 cancel 逻辑，值必须对应自己实现的方法名.*/@TwoPhaseBusinessAction(name = "prepare", commitMethod = "confirm", rollbackMethod = "cancel")void prepare(@BusinessActionContextParameter(paramName = "param") String param);/*** 二阶段confirm确认方法、可以另命名，但要保证与commitMethod一致 ** @param context 上下文,可以传递try方法的参数* @return boolean 执行是否成功*/boolean confirm (BusinessActionContext context);/*** 二阶段回滚方法，要保证与rollbackMethod一致*/boolean cancel (BusinessActionContext context);
}

根据上述语法，就可以编写用户余额冻结服务的接口 AccountTCCService ，如下

@LocalTCC
public interface AccountTCCService {/*** try：冻结指定余热* @param userId* @param money*/@TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,@BusinessActionContextParameter(paramName = "money") int money);/*** 删除冻结余额* @param ctx* @return*/boolean confirm(BusinessActionContext ctx);/*** 删除冻结余额，恢复可用余额* @param ctx* @return*/boolean cancel(BusinessActionContext ctx);}

b）建表

这里我们已经有了用户金额表，如下：

这里我们还需要创建 用户冻结金额表 ，如下：

CREATE TABLE `account_freeze_tbl`  (`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,`user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,`freeze_money` int(11) UNSIGNED NULL DEFAULT 0,`state` int(1) NULL DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',PRIMARY KEY (`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;

对应实体类如下：

@Data
@TableName("account_freeze_tbl")
public class AccountFreeze {@TableId(type = IdType.INPUT)private String xid;private String userId;private Integer freezeMoney;private Integer state;public static abstract class State {public final static int TRY = 0;public final static int CONFIRM = 1;public final static int CANCEL = 2;}
}

c）对应刚刚上述所描述的实现思路，可以基本实现（未考虑空回滚 和 业务悬挂） 

AccountTCCService 接口，如下：

@Slf4j
@Service
public class AccountTCCServiceImpl implements AccountTCCService {@Autowiredprivate AccountMapper accountMapper;@Autowiredprivate AccountFreezeMapper freezeMapper;@Override@Transactionalpublic void deduct(String userId, int money) {//1.获取事务 idString xid = RootContext.getXID();//2.扣减可用余额accountMapper.deduct(userId, money);//3.增加冻结金额，并记录当前事务的状态AccountFreeze freeze = new AccountFreeze();freeze.setUserId(userId);freeze.setXid(xid);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freezeMapper.insert(freeze);}@Overridepublic boolean confirm(BusinessActionContext ctx) {//1.添加事务 idString xid = RootContext.getXID();//2.根据 id 删除冻结记录int count = freezeMapper.deleteById(xid);return count == 1;}@Overridepublic boolean cancel(BusinessActionContext ctx) {//1.查询冻结记录String xid = RootContext.getXID();AccountFreeze freeze = freezeMapper.selectById(xid);//2.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());//3.清理冻结余额，状态修改为 cancelfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count = freezeMapper.updateById(freeze);return count == 1;}}
d）考虑空回滚

考虑在执行 try 逻辑阻塞超时，执行了 cancel 逻辑，那么就需要考虑空回滚.  主要记录 cancel 状态即可.

    @Overridepublic boolean cancel(BusinessActionContext ctx) {//1.查询冻结记录String xid = RootContext.getXID();AccountFreeze freeze = freezeMapper.selectById(xid);//a. 空回滚判断if (freeze == null) {//这里主要记录当前的 cancel 状态freeze = new AccountFreeze();//这里能拿到 userId 和 money 是因为在 AccountTCCService 接口中通过 BusinessActionContextParameter 注解注册了String userId = ctx.getActionContext("userId").toString();freeze.setUserId(userId);freeze.setXid(xid);freeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.TRY);freezeMapper.insert(freeze);}//2.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());//3.清理冻结余额，状态修改为 cancelfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count = freezeMapper.updateById(freeze);return count == 1;}

e）幂等问题

第一次超时了，进行空回滚（添加 freeze，设置状态为 cancel），第二次又超时了，freeze 不为空，就会进行恢复金额逻辑.  这就出问题了，不能进行恢复金额操作，因此，这里需要进行判断，如果处理过了，直接返回 true 即可.

    @Overridepublic boolean cancel(BusinessActionContext ctx) {//1.查询冻结记录String xid = RootContext.getXID();AccountFreeze freeze = freezeMapper.selectById(xid);//a. 空回滚判断if (freeze == null) {//这里主要记录当前的 cancel 状态freeze = new AccountFreeze();//这里能拿到 userId 和 money 是因为在 AccountTCCService 接口中通过 BusinessActionContextParameter 注解注册了String userId = ctx.getActionContext("userId").toString();freeze.setUserId(userId);freeze.setXid(xid);freeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.TRY);freezeMapper.insert(freeze);}//b.幂等问题：第一次超时了，进行空回滚，第二次又超时了，freeze 不为空，就会进行恢复金额逻辑(这就出问题了).if(freeze.getState() == AccountFreeze.State.CANCEL) {//已经处理过依次 cancel 了，无需重复处理return true;}//2.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());//3.清理冻结余额，状态修改为 cancelfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count = freezeMapper.updateById(freeze);return count == 1;}

confirm 为什么不考虑幂等了？

因为 confirm 逻辑是删除冻结记录，底层就是 sql 调用 delete.  因此即使操作多次，也无妨.

f）业务悬挂问题

处理过 cancel 之后，就没必要再处理 try 了，因此这里只需要判断 freeze 是否存在冻结记录，如果有，拒绝即可.

    @Override@Transactionalpublic void deduct(String userId, int money) {//1.获取事务 idString xid = RootContext.getXID();//a. 业务悬挂问题处理：判断 freeze 中是否有冻结记录，如果有，一定是 cancel 执行过，要拒绝业务AccountFreeze oldFreeze = freezeMapper.selectById(xid);if(oldFreeze != null) {return;}//2.扣减可用余额accountMapper.deduct(userId, money);//3.增加冻结金额，并记录当前事务的状态AccountFreeze freeze = new AccountFreeze();freeze.setUserId(userId);freeze.setXid(xid);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freezeMapper.insert(freeze);}

g）到此，整个业务完成.

全代码如下：

@Slf4j
@Service
public class AccountTCCServiceImpl implements AccountTCCService {@Autowiredprivate AccountMapper accountMapper;@Autowiredprivate AccountFreezeMapper freezeMapper;@Override@Transactionalpublic void deduct(String userId, int money) {//1.获取事务 idString xid = RootContext.getXID();//a. 业务悬挂问题处理：判断 freeze 中是否有冻结记录，如果有，一定是 cancel 执行过，要拒绝业务AccountFreeze oldFreeze = freezeMapper.selectById(xid);if(oldFreeze != null) {return;}//2.扣减可用余额accountMapper.deduct(userId, money);//3.增加冻结金额，并记录当前事务的状态AccountFreeze freeze = new AccountFreeze();freeze.setUserId(userId);freeze.setXid(xid);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freezeMapper.insert(freeze);}@Overridepublic boolean confirm(BusinessActionContext ctx) {//1.添加事务 idString xid = RootContext.getXID();//2.根据 id 删除冻结记录int count = freezeMapper.deleteById(xid);return count == 1;}@Overridepublic boolean cancel(BusinessActionContext ctx) {//1.查询冻结记录String xid = RootContext.getXID();AccountFreeze freeze = freezeMapper.selectById(xid);//a. 空回滚判断if (freeze == null) {//这里主要记录当前的 cancel 状态freeze = new AccountFreeze();//这里能拿到 userId 和 money 是因为在 AccountTCCService 接口中通过 BusinessActionContextParameter 注解注册了String userId = ctx.getActionContext("userId").toString();freeze.setUserId(userId);freeze.setXid(xid);freeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.TRY);freezeMapper.insert(freeze);}//b.幂等问题：第一次超时了，进行空回滚，第二次又超时了，freeze 不为空，就会进行恢复金额逻辑(这就出问题了).if(freeze.getState() == AccountFreeze.State.CANCEL) {//已经处理过依次 cancel 了，无需重复处理return true;}//2.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());//3.清理冻结余额，状态修改为 cancelfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count = freezeMapper.updateById(freeze);return count == 1;}}

1.2、Saga 模式

1.2.1、Saga 模式理论

Saga模式是SEATA提供的长事务解决方案。也分为两个阶段：

第一阶段：

与 AT 一样，直接提交本地事务.

第二阶段：

如果第一阶段大家都成功了，就什么也不做.

如果第一阶段有失败的，那么他会反向做一个补偿逻辑去回滚.  这里确实和 tcc 优点像，但不完全一样，因为  tcc 再第一阶段中不是处理事务，只是做资源预留.

比如 扣余额业务，TCC 就直接冻结了，而 saga 是直接把余额扣掉了，如果 saga 第一阶段出现问题，第二阶段就是把扣掉的余额增加回来，实现回滚逻辑的.

1.2.2、saga 模式优缺点

缺点：

没有隔离性：因为一二阶段既没有全局锁，也没有预留资源，所有事务与事务之间可能存在脏写问题.

软状态持续时间不确定：saga 模式是按顺序执行每一个事务，如果有任何一个出现问题，就会立刻反向补偿. 因此这个不一致的时间不确定.

优点：

吞吐能力高：基于事件驱动实现异步调用，也就是一个事务完成了，自己执行下一个事务，无需阻塞等待.

性能高：第一阶段无需上锁，性能高.

实现简单：不用像 TCC 那样编写三个阶段，实现简单.

1.2.3、补充说明

Ps：由于这种模式的使用场景极少，因此就不演示了.

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/95990.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

（六）正点原子STM32MP135移植——内核移植

（六）正点原子STM32MP135移植——内核移植

目录 一、概述 二、编译官方代码 三、移植 四、编译 一、概述 前面已经移植好了TF-A、optee、u-boot，在u-boot能正常跑起来的情况下，现在来移植内核。 二、编译官方代码 进入kernel目录 2.1 解压源码、打补丁 /* 解压源码 */ tar xf linux-6.1.28.…
阅读更多...
【Go语言实战】(25) 分布式算法 MapReduce

【Go语言实战】(25) 分布式算法 MapReduce

MapReduce 写在前面 身为大数据专业的学生，其实大学我也多多少少接触过mapreduce，但是当时觉得这玩意太老了，觉得这和php一样会被时代淘汰。只能说当时确实太年轻了，没有好好珍惜那时候的学习资源… 现在回过头来看mapreduce&a…
阅读更多...
想做好接口测试，先把这些概念搞清楚了

想做好接口测试，先把这些概念搞清楚了

接口一般来说有两种，一种是程序内部的接口，一种是系统对外的接口。 系统对外的接口 比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能给你提供一个他们写好的方法来获取数据，你引用…
阅读更多...
【BBC新闻文章分类】使用 TF 2.0和 LSTM 的文本分类

【BBC新闻文章分类】使用 TF 2.0和 LSTM 的文本分类

一、说明 NLP上的许多创新是如何将上下文添加到词向量中。常见的方法之一是使用递归神经网络
阅读更多...
数据结构之带头双向循环链表

数据结构之带头双向循环链表

目录 链表的分类 带头双向循环链表的实现 带头双向循环链表的结构 带头双向循环链表的结构示意图 空链表结构示意图 单结点链表结构示意图 多结点链表结构示意图 链表创建结点 双向链表初始化 销毁双向链表 打印双向链表 双向链表尾插 尾插函数测试 双向链表头插 …
阅读更多...
如何选择合适的自动化测试工具？

如何选择合适的自动化测试工具？

自动化测试是高质量软件交付领域中最重要的实践之一。在今天的敏捷开发方法中，几乎任一软件开发过程都需要在开发阶段的某个时候进行自动化测试，以加速回归测试的工作。自动化测试工具可以帮助测试人员以及整个团队专注于自动化工具无法处理的各自任务&a…
阅读更多...
【数据结构---排序】很详细的哦

【数据结构---排序】很详细的哦

本篇文章介绍数据结构中的几种排序哦~ 文章目录 前言一、排序是什么？二、排序的分类 1.直接插入排序2.希尔排序3.选择排序4.冒泡排序5.快速排序6.归并排序总结 前言 排序在我们的生活当中无处不在，当然，它在计算机程序当中也是一种很重要的操…
阅读更多...
关掉在vscode使用copilot时的提示音

关掉在vscode使用copilot时的提示音

1. 按照图示的操作File --> Preferences --> Settings 2. 搜索框输入关键字Sound，因为是要关掉声音，所以找有关声音的设置 3. 找到如下图所示的选项 Audio Cues:Line Has Inline Suggetion,将其设置为Off 这样，就可以关掉suggest code时…
阅读更多...
Elasticsearch：什么时候应该考虑在 Elasticsearch 中添加协调节点？

Elasticsearch：什么时候应该考虑在 Elasticsearch 中添加协调节点？

仅协调节点（coordinating only nodes）充当智能负载均衡器。 仅协调节点的这种特殊角色通过减轻数据和主节点的协调责任，为广泛的集群提供了优势。 加入集群后，这些节点与任何其他节点类似，都会获取完整的集群状态&…
阅读更多...
毕业设计选题之Android基于移动端的线上订餐app外卖点餐安卓系统源码 调试 开题 lw

毕业设计选题之Android基于移动端的线上订餐app外卖点餐安卓系统源码 调试 开题 lw

💕💕作者：计算机源码社 💕💕个人简介：本人七年开发经验，擅长Java、Python、PHP、.NET、微信小程序、爬虫、大数据等，大家有这一块的问题可以一起交流！ 💕&…
阅读更多...
C# - Opencv应用（1） 之VS下环境配置详解

C# - Opencv应用（1） 之VS下环境配置详解

C# - Opencv应用（1） 之VS下环境配置详解 有时候，单纯c#做前端时会联合C实现的dll来落地某些功能由于有时候会用C - Opencv实现算法后封装成dll，但是有时候会感觉麻烦，不如直接通过C#直接调用Opencv在此慢慢总结下C# -…
阅读更多...
SpringBoot vue云办公系统

SpringBoot vue云办公系统

SpringBoot vue云办公系统 系统功能 云办公系统 登录 员工资料管理: 搜索员工 添加编辑删除员工 导入导出excel 薪资管理: 工资账套管理 添加编辑删除工资账套 员工账套设置 系统管理: 基础信息设置 部门管理 职位管理 职称管理 权限组管理 操作员管理 开发环境和技术 开发语…
阅读更多...
选择适合户外篷房企业的企业云盘解决方案

选择适合户外篷房企业的企业云盘解决方案

“户外篷房企业用什么企业云盘好？Zoho WorkDrive企业网盘可以帮助户外篷房企业实现文档统一管理、提高工作效率、加强团队协作，并且支持各种文件类型的预览和编辑。” S公司是一家注重管理规范的大型户外篷房企业，已经有10余年的经验。作为设…
阅读更多...
string和const char*参数类型选择的合理性对比

string和const char*参数类型选择的合理性对比

在编程中，我们经常需要处理字符串类型的参数。在C中，有两种常见的表示字符串的参数类型，即string和const char*。本文将对比这两种参数类型的特点，分析其在不同情况下的合理性，以便程序员能够根据实际需求做出正确的选…
阅读更多...
Docker安装ActiveMQ

Docker安装ActiveMQ

ActiveMQ简介 官网地址：https://activemq.apache.org/ 简介： ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了,…
阅读更多...
次方计数的拆贡献法（考虑组合意义）+限定类问题善用值域与位置进行ds：1006T3

次方计数的拆贡献法（考虑组合意义）+限定类问题善用值域与位置进行ds：1006T3

对于多次方的计数问题可以考虑拆贡献。 题目问 ∣ S ∣ 3 |S|^3 ∣S∣3， ∣ S ∣ |S| ∣S∣ 表示选的点数。相当于在 ∣ S ∣ |S| ∣S∣ 中选了3次，也就是选了3个可相同的点。 先考虑3个不相同点的贡献，对应任意3个点，必然会对…
阅读更多...
【小工具-生成合并文件】使用python实现2个excel文件根据主键合并生成csv文件

【小工具-生成合并文件】使用python实现2个excel文件根据主键合并生成csv文件

1 小工具说明 1.1 功能说明 一般来说，我们会先有一个老的文件，这个文件内容是定制好相关列的表格，作为每天的报告。 当下一天来的时候，需要根据新的报表文件和昨天的报表文件做一个合并，合并的时候就会出现有些事新增…
阅读更多...
【BI看板】Superset2.0+图表二次开发初探

【BI看板】Superset2.0+图表二次开发初探

Superset图表功能也很丰富了，但一些个性化的定制需求就需要二次开发了。网上二开的superset版本大多是0.xxx版本的或1.5xxx版本，本次用的是2.xxx。 源码相关说明 源码目录 superset-2.0\superset-frontend\plugins\plugin-chart-echarts 插件相关资料 官…
阅读更多...
【重拾C语言】六、批量数据组织（二）线性表——分类与检索（主元排序、冒泡排序、插入排序、顺序检索、对半检索）

【重拾C语言】六、批量数据组织（二）线性表——分类与检索（主元排序、冒泡排序、插入排序、顺序检索、对半检索）

目录 前言 六、批量数据组织——数组 6.4 线性表——分类与检索 6.4.1 主元排序 6.4.2 冒泡排序 6.4.3 插入排序 6.4.4 顺序检索（线性搜索） 6.4.5 对半检索（二分查找） 算法比较 前言 线性表是一种常见的数据结构&#xf…
阅读更多...
在linux下预览markdown的方法，转换成html和pdf

在linux下预览markdown的方法，转换成html和pdf

背景 markdown是一种便于编写和版本控制的格式，但却不便于预览——特别是包含表格等复杂内容时，单纯的语法高亮是远远不够的——这样就不能边预览边调整内容，需要找到一种预览方法。 思路 linux下有个工具，叫pandoc&#xff0c…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023