【雷丰阳-谷粒商城 】【分布式高级篇-微服务架构篇】【25】【分布式事务】

news2024/12/28 4:15:12

持续学习&持续更新中…

守破离

【雷丰阳-谷粒商城 】【分布式高级篇-微服务架构篇】【25】【分布式事务】

  • 本地事务
    • 事务的基本性质
    • 事务的隔离级别（下面四个越往下，隔离级 别越高，并发能力越差）
    • 事务的传播行为（是否共用事务）
  • 事务的坑 ：本地事务方法互调，其他方法的事务设置失效
  • 问题：本地事务，在分布式系统下，只能控制住自己的回滚，控制不了其他服务的回滚
  • 分布式事务
    • 分布式系统经常出现的异常
    • CAP 定理
    • 分布式系统中实现一致性的 raft 算法
    • BASE 理论
    • 强一致性、弱一致性、最终一致性
  • 分布式事务几种方案
    • 2PC 模式
    • 柔性事务-TCC 事务补偿型方案
    • 柔性事务-最大努力通知型方案
    • 柔性事务-可靠消息+最终一致性方案（异步确保型）
  • 分布式事务—Seata
  • 整合Seata
  • 参考

本地事务

事务的基本性质

数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation) 和持久性(Durabilily)，简称就是 ACID；

  • 原子性：一系列的操作整体不可拆分，要么同时成功，要么同时失败
  • 一致性：数据在事务的前后，业务整体一致。：转账。A:1000；B:1000； 转 200 ； 事务成功： A：800 B：1200
  • 隔离性：事务之间互相隔离。
  • 持久性：一旦事务成功，数据一定会落盘在数据库。

在以往的单体应用中，我们多个业务操作使用同一条连接操作不同的数据表，一旦有异常， 我们可以很容易的整体回滚；

  • Business：我们具体的业务代码
  • Storage：库存业务代码；扣库存
  • Order：订单业务代码；保存订单
  • Account：账号业务代码；减账户余额

比如买东西业务，扣库存，下订单，账户扣款，是一个整体；必须同时成功或者失败，一个事务开始，代表以下的所有操作都在同一个连接里面；
在这里插入图片描述

事务的隔离级别（下面四个越往下，隔离级 别越高，并发能力越差）

  • READ UNCOMMITTED（读未提交） ：该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为脏读。

  • READ COMMITTED（读已提交） ：一个事务可以读取另一个已提交的事务。Oracle和SQL Server的默认隔离级别。
    同一个事务中，该隔离级别下，同样的 select 多次读取会读出不一样的结果，此现象称为不可重复读问题

  • REPEATABLE READ（可重复读） ：该隔离级别是 MySQL 默认的隔离级别 ：在同一个事务里，同样的 select 操作，select到的结果始终是事务开始时时间点的状态。 因此，同样的 select 操作在该事务中读到的结果会是一致的，但是，会有幻读现象。MySQL 的 InnoDB 引 擎可以通过 next-key locks 机制来避免幻读。

  • SERIALIZABLE（序列化） ：在该隔离级别下事务都是串行顺序执行的，MySQL数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。

事务的传播行为（是否共用事务）

  • PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务， 就加入该事务，该设置是最常用的设置。

  • PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

  • PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。

  • PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

  • PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

  • PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。

  • PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

事务的坑 ：本地事务方法互调，其他方法的事务设置失效

  • 同一个对象内，事务方法互调，其他方法的事务设置默认失效，原因：绕过了代理对象，没有用到代理对象，事务使用代理对象来控制的
  • 解决：使用代理对象来调用其他事务方法
	  1）、引入aop-starter：spring-boot-starter-aop；引入了aspectj
	            <dependency>
		            <groupId>org.springframework.boot</groupId>
		            <artifactId>spring-boot-starter-aop</artifactId>
		        </dependency>
	  2）、@EnableAspectJAutoProxy(exposeProxy = true)；开启 aspectj 动态代理功能。
	      以后所有的动态代理都是aspectj创建的（即使没有接口也可以创建动态代理）。
	      exposeProxy = true：对外暴露代理对象
	  3）、本类互调用代理对象调
	     OrderServiceImpl orderService = (OrderServiceImpl) AopContext.currentProxy();
	         orderService.b();
	         orderService.c();

    //事务的隔离级别(isolation = Isolation.REPEATABLE_READ)
    //REQUIRED、REQUIRES_NEW

    //坑：同一个对象内，事务方法互调，他们的事务设置默认失效，原因：事务使用代理对象来控制的，直接调用绕过了代理对象
    @Transactional(timeout = 30)
    public void a() {
        //使用this调用，b，c做任何设置都没用。都是和a公用一个事务
//        this.b(); 没用
//        this.c(); 没用
        OrderServiceImpl orderService = (OrderServiceImpl) AopContext.currentProxy();
        orderService.b(); //a事务。应用到了自己的事务设置REQUIRED，如果是REQUIRED，那么自己的事务设置不起作用，和a()共用
        orderService.c(); //新事务。应用到了自己的事务设置REQUIRES_NEW, timeout = 20 ，自己的事务设置起作用
//        bService.b(); //a事务
//        cService.c(); //新事务
        int i = 10 / 0;
    }

    @Transactional(propagation = Propagation.REQUIRED, timeout = 2)
    public void b() {
        //执行了7s，回滚不
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW, timeout = 20)
    public void c() {

    }

问题：本地事务，在分布式系统下，只能控制住自己的回滚，控制不了其他服务的回滚

在这里插入图片描述

  • 库存调用成功了，但是网络原因，或者其他原因，导致Feign调用超时了，此时：订单回滚，库存不会回滚。
  • 假如还有个远程扣减积分服务是在订单服务调用成功后调用的，该服务出异常 ：订单会回滚；由于库存服务已经成功的远程执行，不会回滚。
    //本地事务，在分布式系统下，只能控制住自己的回滚，控制不了其他服务的回滚
    //应该使用分布式事务，但是分布式事务比较复杂，比较复杂的最大原因：网络问题+分布式机器。
//    @GlobalTransactional  //高并发
    @Transactional
    @Override
    public SubmitOrderResponseVo submitOrder(OrderSubmitVo vo) {
        confirmVoThreadLocal.set(vo);
        SubmitOrderResponseVo response = new SubmitOrderResponseVo();
        MemberRespVo memberRespVo = LoginUserInterceptor.loginUser.get();
        response.setCode(0);
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        String orderToken = vo.getOrderToken();
        Long result = redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class), Arrays.asList(OrderConstant.USER_ORDER_TOKEN_PREFIX + memberRespVo.getId()), orderToken);
        if (result == 0L) {
            response.setCode(1);
            return response;
        } else {
            //令牌验证成功  //下单：去创建订单，验令牌，验价格，锁库存...

            //1、创建订单，订单项等信息
            OrderCreateTo order = createOrder();
            //2、验价
            if (Math.abs(order.getOrder().getPayAmount().subtract(vo.getPayPrice()).doubleValue()) < 0.01) { //金额对比
                // 3、保存订单
                saveOrder(order);
                //4、库存锁定。只要有异常回滚订单数据。
                // 库存锁定需要的数据：订单号，所有订单项（skuId，skuName，num）

                //4、远程锁库存
                R r = wareFeignService.orderLockStock(getLockVo(order));

                //TODO 问题1：库存调用成功了，但是网络原因，或者其他原因，导致Feign调用超时了，此时：订单回滚，库存不会回滚。

                if (r.getCode() == 0) {
                    //锁成功了
                    response.setOrder(order.getOrder());

                    //TODO 问题2：假如还有个远程扣减积分服务
                    // 该服务出异常 ：订单会回滚；由于库存服务已经成功的远程执行，不会回滚。
                    int i = 10/0; //模拟扣减积分出异常

                    //TODO 清除购物车已经下单的商品

                    return response;
                } else {
                    //锁定失败
                    response.setCode(3);
                    String msg = (String) r.get("msg");
                    throw new NoStockException(msg);
                }
            } else {
                response.setCode(2);
                return response;
            }
        }
    }

分布式事务

分布式系统经常出现的异常

机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失…

在这里插入图片描述

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。

CAP 定理

CAP 原则又称 CAP 定理，指的是在一个分布式系统中

  1. 一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访 问同一份最新的数据副本）
  2. 可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据 更新具备高可用性）
  3. 分区容错性（Partition tolerance）：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。 分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

在这里插入图片描述

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们， 剩下的 C 和 A 无法同时做到。

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所 以节点故障、网络故障是常态，而且要保证服务可用性达到 99.99999%（N 个 9），即保证 P 和 A，舍弃 C。

分布式系统中实现一致性的 raft 算法

http://thesecretlivesofdata.com/raft/

https://raft.github.io/

raft算法核心：领导选举、日志复制

领导选举、日志复制这两个动作的过程中有两个时间在起作用：自旋时间 （随机的，也叫选举时间）、心跳时间（固定的，指定的时间间隔）

raft算法下的节点有三个状态：随从、候选者 、领导

  • 领导根据心跳时间给随从发送心跳（可能会附加日志，通过日志可以更新其他节点的数据），随从收到消息会回复领导 ，并将随从自己的自旋时间重置
  • 随从如果接收不到领导者的消息会在随机自旋时间结束后成为候选者
  • 候选者会让其他节点为自己投票选自己成为新一轮的领导（加上自己大多数同意即可）

raft算法下对系统的所有更改都要经过领导者

Raft 可以在面对网络分区时保持一致。

BASE 理论

BASE 理论是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以采用适当的弱一致性，即最终一致性。

BASE 是指

  • 基本可用（Basically Available）

    • 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、 功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系 统不可用。
    • 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的 查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），我 们就得去查其他节点，导致查询 结果的响应时间增加到了 1~2 秒。
    • 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性， 部分消费者可能会被引导到一个降级页面。

  • 软状态（ Soft State）

    • 软状态是指允许系统存在中间状态（成功状态、中间状态、失败状态），而该中间状态不会影响系统整体可用性。
    • 分布 式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。

  • 最终一致性（ Eventual Consistency）

    • 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
    • 弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

强一致性、弱一致性、最终一致性

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。

如果能容忍后续的部分或者全部访问不到，则是弱一致性。

如果经过一段时间后要求 能访问到更新后的数据，则是最终一致性

分布式事务几种方案

2PC 模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。

MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。

其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

  • 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是 否可以提交.
  • 第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。

在这里插入图片描述

XA的特点：

  • 刚性事务

  • XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较 低。

  • XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景

  • XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。

  • 许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。

  • 也有 3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间 未收到回应则做出相应处理）

柔性事务-TCC 事务补偿型方案

  • 刚性事务：遵循 ACID 原则，强一致性。
  • 柔性事务：遵循 BASE 理论，最终一致性；

与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

在这里插入图片描述

一段业务代码分为三个方法： try(prepare)、confirm(commit)、 cancel(rollback)

  • 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
  • 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
  • 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

在这里插入图片描述

柔性事务-最大努力通知型方案

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。

这种 方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。

这种 方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通 知次数后即不再通知。

案例：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对 账文件），支付宝的支付成功异步回调

柔性事务-可靠消息+最终一致性方案（异步确保型）

发送端防止消息丢失：

  1. 做好消息确认机制（publisher，consumer【手动ack】）
  2. 每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍

消费者：

  1. 开启手动ACK
  2. 将消费者的业务消费接口设计为幂等的，比如要解锁库存先判断状态

分布式事务—Seata

https://seata.apache.org/zh-cn/docs/overview/terminology/

在这里插入图片描述

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整合Seata

https://seata.apache.org/zh-cn/docs/user/quickstart/

每一个微服务先必须创建 undo_log 表；

CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT       NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(128) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
    ) ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table';
ALTER TABLE `undo_log` ADD INDEX `ix_log_created` (`log_created`);

导入依赖 spring-cloud-starter-alibaba-seata ；

	<dependency>
	    <groupId>com.alibaba.cloud</groupId>
	    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
	</dependency>

安装事务协调器；seata-server（seata-all-0.7.1，所以该项目使用seata-server-0.7.1.zip）： https://github.com/seata/seata/releases

解压seata-server，修改注册中心配置registry.conf，并启动seata-server

     registry {
         type = "nacos"
         nacos {
             serverAddr = "localhost:8848"
             ...
         }
     }

所有想要用到分布式事务的微服务使用seata的DataSourceProxy代理自己的数据源

@Configuration
public class MySeataConfig {

    @Autowired
    DataSourceProperties dataSourceProperties;

    @Bean
    public DataSource dataSource(DataSourceProperties dataSourceProperties){
        HikariDataSource dataSource = dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
        if (StringUtils.hasText(dataSourceProperties.getName())) {
            dataSource.setPoolName(dataSourceProperties.getName());
        }
        return new DataSourceProxy(dataSource);
    }
    
}

每个微服务，都必须把seata-server-0.7.1/conf目录下的registry.conf、file.conf这两个文件拷贝到自己的resources目录下，然后修改自己微服务下的file.conf：

vgroup_mapping.{application.name}-fescar-service-group = "default"
比如订单服务：
vgroup_mapping.gulimall-order-fescar-service-group = "default"

给分布式大事务的入口标注@GlobalTransactional,，每一个远程的小事务用@Transactional

    @GlobalTransactional
//    @Transactional
    @Override
    public SubmitOrderResponseVo submitOrder(OrderSubmitVo vo) {
            //1、创建订单，订单项等信息
            OrderCreateTo order = createOrder();
            // 3、保存订单
            saveOrder(order);
            //4、库存锁定。只要有异常回滚订单数据。
            // 库存锁定需要的数据：订单号，所有订单项（skuId，skuName，num）

            //4、远程锁库存
            R r = wareFeignService.orderLockStock(getLockVo(order));

            //TODO 问题1：库存调用成功了，但是网络原因，或者其他原因，导致Feign调用超时了，此时：订单回滚，库存不会回滚。

            if (r.getCode() == 0) {
                //锁成功了
                response.setOrder(order.getOrder());

                //TODO 问题2：假如还有个远程扣减积分服务
                // 该服务出异常 ：订单会回滚；由于库存服务已经成功的远程执行，不会回滚。
                int i = 10/0; //模拟扣减积分出异常
                
            } 
    }

    /**
     * 为某个订单锁定库存
     *
     * @Transactional(rollbackFor = NoStockException.class)
     * 默认只要是运行时异常都会回滚
     */
    @Transactional
    @Override
    public Boolean orderLockStock(WareSkuLockVo vo) {
        //TODO 按照下单的收货地址，找到一个就近仓库，锁定库存。

        //1、找到每个商品在哪个仓库都有库存
        List<OrderItemVo> locks = vo.getLocks();

启动测试分布式事务

参考

雷丰阳: Java项目《谷粒商城》Java架构师 | 微服务 | 大型电商项目.

本文完，感谢您的关注支持！

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

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

相关文章

花几千上万学习Java，真没必要！（七）

花几千上万学习Java，真没必要！（七）

swtich语句&#xff1a; 测试代码1&#xff1a; package testswitch.com;//根据月份和年份&#xff0c;当月份是 2 时&#xff0c;检查年份是否为闰年&#xff0c;然后继续执行下一个 case&#xff0c;打印出"三月"&#xff0c;然后终止switch 语句。 public class …
阅读更多...
微软Edge浏览器深度解析：性能、安全性与特色功能全面评测

微软Edge浏览器深度解析：性能、安全性与特色功能全面评测

一、引言 自Windows 10操作系统推出以来&#xff0c;微软Edge浏览器作为默认的网页浏览器&#xff0c;凭借其现代化的设计和出色的性能表现&#xff0c;逐渐获得了用户的认可。本文旨在对Edge浏览器进行深入分析&#xff0c;探讨其在多个方面的表现。 二、界面与操作体验 界面…
阅读更多...
力扣每日一题：807. 保持城市天际线

力扣每日一题：807. 保持城市天际线

文章目录 ***今日份每日一题&#xff1a;***题目要求&#xff1a;示例如下&#xff1a;示例1示例2 解释剖析示例示例1示例2 将逻辑思路转换为代码 力扣官网&#xff1a;前往作答&#xff01;&#xff01;&#xff01;&#xff01; 今日份每日一题&#xff1a; 题目要求&#…
阅读更多...
算法-二叉树常见问题详解

算法-二叉树常见问题详解

文章目录 1. 二叉树的三种遍历方式的实质2. 二叉树的序列化与反序列化3. 根据前序中序反序列创建二叉树4. 二叉树的路径问题5. LCA公共祖先问题6. 二叉搜索树的LCA问题7. 验证搜索二叉树8. 修建搜索二叉树9. 二叉树打家劫舍问题 1. 二叉树的三种遍历方式的实质 这个相信大家都不…
阅读更多...
Python从0到100（四十）：Web开发简介-从前端到后端（文末免费送书）

Python从0到100（四十）：Web开发简介-从前端到后端（文末免费送书）

前言&#xff1a; 零基础学Python&#xff1a;Python从0到100最新最全教程。 想做这件事情很久了&#xff0c;这次我更新了自己所写过的所有博客&#xff0c;汇集成了Python从0到100&#xff0c;共一百节课&#xff0c;帮助大家一个月时间里从零基础到学习Python基础语法、Pyth…
阅读更多...
王权与自由steam服测试资格申请 王权与自由国际服测试资格申请

王权与自由steam服测试资格申请 王权与自由国际服测试资格申请

不少人都开始期待《王权与自由国际服》的内测&#xff0c;消息已经传出&#xff0c;这款游戏的内测马上会在 太平洋时间4月10日下午1点&#xff0c;也就是世界标准时间的晚上8点&#xff0c;开始封闭式Beta测试&#xff0c;测试时间有为一周&#xff0c;持续到4月17日的太平洋…
阅读更多...
万字长文之分库分表里如何设计一个主键生成算法？【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表】

万字长文之分库分表里如何设计一个主键生成算法？【后端面试题 | 中间件 | 数据库 | MySQL | 分库分表】

分库分表是在面试里一个非常热门而且偏难的话题&#xff0c;下面了解UUID、自增主键和雪花算法的特点&#xff0c;并且在面试的时候刷出亮点。 前置 所谓的分库分表严格来说是分数据源、分库和分表。例如每个公司订单表的分库分表策略就是用了8个主从集群&#xff0c;每个主从…
阅读更多...
Layout View

Layout View

GoTo 数据网格和视图入门 本文档仅概述特定于LayoutView的功能。有关常用卡和选择功能的信息&#xff0c;请参阅根卡和布局视图一文。 Template Card 布局视图使用布局控件来排列卡片内的内容。对于每个网格列&#xff0c;都会生成一个LayoutViewField对象。切换到数据网格设…
阅读更多...
django超市管理系统-计算机毕业设计源码53507

django超市管理系统-计算机毕业设计源码53507

摘 要 随着社会经济的不断发展&#xff0c;超市作为零售行业的一部分&#xff0c;扮演着重要的角色。在信息技术的快速发展的背景下&#xff0c;计算机软件和硬件技术的普及应用在商业管理中起到了至关重要的作用&#xff0c;因此基于Django的超市管理系统应运而生&#xff0c;…
阅读更多...
昇思25天学习打卡营第15天|基于MobileNetv2的垃圾分类

昇思25天学习打卡营第15天|基于MobileNetv2的垃圾分类

一、关于MobileNetv2 MobileNet网络专注于移动端、嵌入式或IoT设备的轻量级CNN网络。MobileNet网络使用深度可分离卷积&#xff08;Depthwise Separable Convolution&#xff09;的思想在准确率小幅度降低的前提下&#xff0c;大大减小了模型参数与运算量。并引入宽度系数 α和…
阅读更多...
MySQL集群、Redis集群、RabbitMQ集群

MySQL集群、Redis集群、RabbitMQ集群

一、MySQL集群 1、集群原理 MySQL-MMM 是 Master-Master Replication Manager for MySQL&#xff08;mysql 主主复制管理器&#xff09;的简称。脚本&#xff09;。MMM 基于 MySQL Replication 做的扩展架构&#xff0c;主要用来监控 mysql 主主复制并做失败转移。其原理是将真…
阅读更多...
解决vscode项目中无法识别宏定义的问题

解决vscode项目中无法识别宏定义的问题

在c_cpp_properties.json中的"defines":[]中定义的宏无法被识别。 从而导致代码中的宏开关无法生效&#xff0c;造成代码的阅读不便利。 排查路线是&#xff1a; 关闭所有插件&#xff0c;删除当前工程目录下的.vscode文件夹。 经过一系列排查发现是C/C插件与clangd插…
阅读更多...
能把进程和线程讲的这么透彻的，没有20年功夫还真不行【0基础也能看懂】

能把进程和线程讲的这么透彻的，没有20年功夫还真不行【0基础也能看懂】

本篇会加入个人的所谓鱼式疯言 ❤️❤️❤️鱼式疯言:❤️❤️❤️此疯言非彼疯言 而是理解过并总结出来通俗易懂的大白话, 小编会尽可能的在每个概念后插入鱼式疯言,帮助大家理解的. &#x1f92d;&#x1f92d;&#x1f92d;可能说的不是那么严谨.但小编初心是能让更多人…
阅读更多...
数据库基本查询（表的增删查改）

数据库基本查询（表的增删查改）

一、增加 1、添加信息 insert 语法 insert into table_name (列名) values (列数据1&#xff0c;列数据2&#xff0c;列数据3...) 若插入时主键或唯一键冲突就无法插入。 但如果我们就是要修改一列信息也可以用insert insert into table_name (列名) values (列数据1&am…
阅读更多...
nginx的正向与反向代理

nginx的正向与反向代理

正向代理与反向代理的区别 虽然正向代理和反向代理都涉及代理服务器接收客户端请求并向服务端转发请求&#xff0c;但它们之间存在一些关键的区别&#xff1a; 正向代理&#xff1a; 在正向代理中&#xff0c;代理服务器代表客户端向服务器发送请求&#xff0c;并将服务…
阅读更多...
【Linux】安装PHP扩展-igbinary

【Linux】安装PHP扩展-igbinary

说明 本文档是在centos7.6的环境下&#xff0c;安装PHP7.4之后&#xff0c;安装对应的PHP扩展igbinary。 一、igbinary简述 igbinary 是一个 PHP 扩展&#xff0c;主要用于序列化和反序列化数据&#xff0c;其设计目的是为了提高序列化过程中的性能和内存效率。 优点&#…
阅读更多...
wifi信号处理的CRC8、CRC32

wifi信号处理的CRC8、CRC32

&#x1f9d1;&#x1f3fb;个人简介&#xff1a;具有3年工作经验&#xff0c;擅长通信算法的MATLAB仿真和FPGA实现。代码事宜&#xff0c;私信博主&#xff0c;程序定制、设计指导。 &#x1f680;wifi信号处理的CRC8、CRC32 目录 &#x1f680;1.CRC概述 &#x1f680;1.C…
阅读更多...
LeNet入门和Pytorch实现

LeNet入门和Pytorch实现

1. LeNet简介 LeNet是一系列网络的合称&#xff0c;包括LeNet1-LeNet5&#xff0c;是卷积神经网络的开山之作。 文献&#xff1a;LeCun Y, Boser B, Denker J, et al. Handwritten digit recognition with a back-propagation network[J]. Advances in neural information pro…
阅读更多...
鸿蒙开发：Universal Keystore Kit（密钥管理服务）【查询密钥是否存在(C/C++)】

鸿蒙开发：Universal Keystore Kit（密钥管理服务）【查询密钥是否存在(C/C++)】

查询密钥是否存在(C/C) HUKS提供了接口供应用查询指定密钥是否存在。 在CMake脚本中链接相关动态库 target_link_libraries(entry PUBLIC libhuks_ndk.z.so)开发步骤 构造对应参数。 指定密钥别名keyAlias&#xff0c;密钥别名最大长度为64字节。查询密钥需要的属性TAG&#…
阅读更多...
DZS-12CE/S延时中间继电器 导轨安装 约瑟JOSEF

DZS-12CE/S延时中间继电器 导轨安装 约瑟JOSEF

中间继电器型号&#xff1a; DZS-254 DZS-145 DZS-233 DZS-121 DZS-112 DZS-121 DZS-12BG DZS-12B DZS-213 DZS-234 DZS-11B/Q DZS-226 DZS-652 DZS-17E/302 DZS-12CE/S DZS-821 DZS-226 DZS-249 DZS-254G DZS-12E DZS-895 DZS-234 DZS-655G DZS-651 DZS-115 DZS-…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023