NoSQL 之Redis集群模式

一:Redis集群方式

Redis有三种模式:分别是主从复制、哨兵模式、Cluster

1:主从模式:

主从复制是高可用Redis的基础,哨兵和群集都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单故障恢复。

缺陷:故障恢复无法自动化,写操作无法负载均衡,存储能力受到单机的限制。

2:哨兵模式:

在主从复制的基础上,哨兵实现了自动化的故障恢复。

缺陷:写操作无法负载均衡,存储能力受到单机的限制,哨兵无法对从节点进行自动故障转移;在读写分离场景下,从节点故障会导致读服务不可用,需要对从节点做额外的监控、切换操作。

3:集群模式

通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。

Redis-Cluster 是在 Redis3.0 版中推出,支持 Redis 分布式集群部署模式,采用无中心分布式架构。所有的 Redis 节点彼此互联(PING-PONG 机制),内部使用二进制协议优化传输速度和带宽。节点的 fail 是通过集群中超过半数的节点检测失败时才生效。客户端与 Redis节点直连,不需要中间代理层。客户端也不需要连接集群所有节点,连接集群中任何一个可用节点即可,这样即减少了代理层,也大大提高了 Redis 集群性能。

Redis Cluster通过创建多个副本来保证数据的可靠性。每个分片都有一个主节点和多个从节点,主节点负责处理读写操作,而从节点则复制主节点的数据。当主节点发生故障时,从节点会自动切换为主节点,提供读写服务。这样可以确保即使发生节点故障,系统仍然能够继续提供服务,保证数据的高可用性。

模式

版本

优点

缺点

主从模式

redis2.8之前

1、解决数据备份问题
2、做到读写分离,提高服务器性能

1、master故障,无法自动故障转移,需人工介入
2、master无法实现动态扩容

哨兵模式

redis2.8级之后的模式

1、Master 状态监测
2、master节点故障,自动切换主从,故障自愈
3、所有slave从节点,随之更改新的master节点

1、slave节点下线,sentinel不会对其进行故障转移,连接从节点的客户端因为无法获取到新的可用从节点
2、master无法实行动态扩容

redis cluster模式

redis3.0版本之后

1、有效的解决了redis在分布式方面的需求
2、遇到单机内存,并发和流量瓶颈等问题时,可采用Cluster方案达到负载均衡的目的
3、可实现动态扩容
4、P2P模式,无中心化
5、通过Gossip协议同步节点信息
6、自动故障转移、Slot迁移中数据可用
7、自动分割数据到不同的节点上
8、整个集群的部分节点失败或者不可达的情况下能够继续处理命令

1、架构比较新,最佳实践较少
2、为了性能提升,客户端需要缓存路由表信息
3、节点发现、reshard操作不够自动化
4、不支持处理多个keys的命令,因为这需要在不同的节点间移动数据
5、Redis 集群不像单机 Redis 那样支持多数据库功能, 集群只使用默认的 0 号数据库, 并且不能使用 SELECT index 命令

二:集群模式简介

集群,即 Redis Cluster, 是Redis 3. 0开始引入的分布式存储方案。集群由多个节点(Node) 组成,Redis 的数据分布在这些节点中。集群中的节点分为主节点和从节点;只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。

redis集群采用master-slave的方式,即1个master节点可以包含多个slave节点,slave节点主要对master节点的数据进行备份,如果master节点挂了,可以启动salve节点替换掉原先的master节点,作为新的master节点。redis集群使用投票容错机制,如果集群中超过半数以上的节点投票认为某节点挂了,那么这个节点就会被认为挂掉了,所以,在设置redis集群时,最少的master节点为3个,如果每一个master节点都添加一个slave节点的话,搭建一个redis集群总共需要6个节点,即3个master节点,3个slave节点。

redis集群没有统一的入口,客户端连接集群的时候,连接集群中的任意节点即可。

Redis集群是一个由多个主从节点群组成的分布式服务集群,它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式,这种集群模式没有中心节点,可水平扩展,据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式,且集群配置非常简单。redis集群的运用主要是针对海量数据+高并发+高可用的场景。

三:数据分片方式

对象保存到redis之前先经过CRC16哈希到一个指定的Node上,这个过程即redis cluster的分片,集群内部将所有的key映射到16384个Slot中,集群中的每个Redis Instance负责其中的一部分的Slot的读写。集群客户端连接集群中任一Redis Instance即可发送命令,当Redis Instance收到自己不负责的Slot的请求时,会将负责请求Key所在Slot的Redis Instance地址返回给客户端,客户端收到后自动将原请求重新发往这个地址,对外部透明。一个Key到底属于哪个Slot由 (HASH_SLOT = CRC16(key) mod 16384) 决定。只有master节点会被分配槽位,slave节点不会分配槽位。

Redis Cluster通过哈希算法将数据分散到多个节点上,实现数据的分片。每个节点负责管理一部分数据,并提供相应的读写操作。分片机制可以将数据均匀地分布在多个节点上,提高系统的并发处理能力。当某个节点发生故障时,只会影响该节点上的数据,而不会影响整个系统的可用性。

具体的分片方式有客户端分片、代理分片和Twemproxy 代理分片机制。

1:客户端分片

客户端分片方案是将分片工作放在业务程序端。程序代码根据预先设置的路由规则,直接对多个 Redis 实例进行分布式访问。这样的好处是,群集不依赖于第三方分布式中间件,实现方法和代码都自己掌控,可随时调整,不用担心踩到坑。这实际上是一种静态分片技术,Redis 实例的增减,都得手工调整分片程序。基于此分片机制的开源产品,现在仍不多见。

这种分片机制的性能比代理式更好(少了一个中间分发环节),但缺点是升级麻烦,对研发人员的个人依赖性强,需要有较强的程序开发能力做后盾。如果主力程序员离职,可能新的负责人会选择重写一遍。所以这种方式下可运维性较差,一旦出现故障,定位和解决都得研发人员和运维人员配合解决,故障时间变长。因此这种方案,难以进行标准化运维,不太适

合中小公司。

2:代理分片

代理分片方案是将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求,根据路由规则,将这些请求分发给正确的 Redis 实例并返回给业务程序。这种机制下,一般会选用第三方代理程序(而不是自己研发)。因为后端有多个 Redis 实例,所以这类程序又称为分布式中间件。这种分片机制的好处是业务程序不用关心后端 Redis实例,维护起来也方便。虽然会因此带来些性能损耗,但对于 Redis 这种内存读写型应用,相对而言是能容忍的。这是比较推荐的集群实现方案。像 Twemproxy、Codis 就是基于该机制的开源产品的其中代表,应用非常广泛。

(1)Twemproxy 代理分片机制

Twemproxy 是一种代理分片机制,由 Twitter 开源。Twemproxy 作为代理,可接受来自多个程序的访问,按照路由规则,转发给后台的各个 Redis 服务器,再原路返回。这个方案顺理成章地解决了单个 Redis 单实例问题。当然 Twemproxy 本身也是单点,需要用Keepalived 做高可用方案。在很长的时间内,Twemproxy 是应用范围最广、稳定性最高、最久经考验的分布式中间件。

这种分片方式无法平滑地扩容/缩容,增加了运维难度。当业务量突增需要增加 Redis 服务器或业务量萎缩需要减少 Redis 服务器时,Twemproxy 都无法平滑地进行扩容或缩容等操作。

并且Twemproxy 代理分片机制对运维操作不友好,甚至没有控制面板。由于使用了中间件代理,相比客户端直接连接服务器方式,性能上有所损耗,实测性能效果降低了 20%左右。

(2)Codis 代理分片机制

Codis 由豌豆荚于 2014 年 11 月开源,基于 Go 语言和 C 语言开发,是近期涌现的、国人开发的优秀开源软件之一,现已广泛用于豌豆荚的各种 Redis 业务场景。从各种压力测试来看,Codis 的稳定性符合高效运维的要求。实测 Codis 集群业务处理性能改善很多,最初集群处理数据性能要比Twemproxy差20%左右,现在比Twemproxy好很多。并且Codis具有可视化运维管理界面。因此综合方面会优于 Twemproxy 很多。目前越来越多的公司选择 Codis。

Codis 引入了 Group 的概念,每个 Group 包括 1 个 Redis Master 及至少 1 个 RedisSlave,这是和 Twemproxy 的区别之一。这样做的好处是,如果当前 Master 有问题,则运维人员可通过 Dashboard“自助式”切换到 Slave,而不需要小心翼翼地修改程序配置文件。

为支持数据热迁移(Auto Rebalance),出品方修改了 Redis Server 源码,并称之为 CodisServer。Codis 采用预先分片(Pre-Sharding)机制,事先规定分成 1024 个 slots(也就是说,最多能支持后端 1024 个 Codis Server),这些路由信息保存在 zookeeper 中。

3:服务器端分片

服务器端分片是 Redis 官方的集群分片技术。Redis-Cluster 将所有 Key 映射到 16384个 slot 中,集群中每个 Redis 实例负责一部分,业务程序是通过集成的 Redis-Cluster 客户端进行操作。客户端可以向任一实例发出请求,如果所需数据不在该实例中,则该实例引导客户端自动去对应实例读写数据。Redis-Cluster 成员之间的管理包括节点名称、IP、端口、状态、角色等,都通过节点与之间两两通讯,定期交换信息并更新。

四:负载均衡的实现

客户端路由: 在Redis Cluster中,客户端需要根据数据的键名选择正确的节点进行读写操作。Redis Cluster使用哈希槽(hash slot)来划分数据,并将每个哈希槽映射到相应的节点上。客户端可以根据键名的哈希值,将请求发送到对应的节点上,实现负载均衡。

自动迁移: Redis Cluster具有自动迁移功能,当节点加入或离开集群时,系统会自动重新分配数据,保持各个节点上哈希槽的均衡。当节点加入集群时,系统会将一部分哈希槽从其他节点迁移到新节点上;当节点离开集群时,系统会将该节点上的哈希槽重新分配给其他节点。这种机制可以在节点数目变化时,自动调整数据的分布,实现负载均衡。

故障检测与恢复: Redis Cluster具有故障检测和自动恢复的机制。集群中的节点会相互监控,检测节点的健康状态。当某个节点被检测到不可用时,系统会自动将该节点标记为下线,并将该节点上的哈希槽重新分配给其他节点。当节点恢复正常时,系统会将其重新加入集群,并进行数据迁移,保持数据的一致性。

Redis Cluster通过分片和副本机制实现了数据的高可用性和负载均衡。分片机制将数据均匀地分布在多个节点上,提高了系统的并发处理能力;副本机制则保证了数据的可靠性,即使发生节点故障,也能够继续提供服务。同时,Redis Cluster通过客户端路由、自动迁移和故障检测与恢复等机制,实现了负载均衡和故障自动转移。在实际应用中,合理设计和配置Redis Cluster,可以提高系统的性能、可靠性和可扩展性。

五:故障的处理

1:故障转移

当从节点发现自己的主节点变为已下线(FAIL)状态时,便尝试进Failover,以期成为新的主。

以下是故障转移的执行步骤:

  1. 从下线主节点的所有从节点中选中一个从节点
  2. 被选中的从节点执行SLAVEOF NO NOE命令,成为新的主节点
  3. 新的主节点会撤销所有对已下线主节点的槽指派,并将这些槽全部指派给自己
  4. 新的主节点对集群进行广播PONG消息,告知其他节点已经成为新的主节点
  5. 新的主节点开始接收和处理槽相关的请求
  6. 集群slots是否必须完整才能对外提供服务

2:多slave选举

在多个slave情况下如果一个master宕机,需要基于Raft协议选举方式来实现的新主的选举。步骤如下:

  1. 当从节点发现自己的主节点进行已下线状态时,从节点会广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息,要求所有收到这条消息,并且具有投票权的主节点向这个从节点投票。
  2. 如果一个主节点具有投票权,并且这个主节点尚未投票给其他从节点,那么主节点将向要求投票的从节点返回一条,CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息,表示这个主节点支持从节点成为新的主节点。
  3. 每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息,并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。
  4. 如果集群里有N个具有投票权的主节点,那么当一个从节点收集到大于等于集群N/2+1张支持票时,这个从节点就成为新的主节点。
  5. 如果在一个选举周期没有从能够收集到足够的支持票数,那么集群进入一个新的选举周期,并再次进行选主,直到选出新的主节点为止。

五:Redis群集部署

1:安装redis(每个节点都要安装)

[root@localhost ~]# systemctl stop firewalld

[root@localhost ~]# setenforce 0

[root@localhost ~]# yum -y install gcc* zlib-devel

[root@localhost ~]# tar xvzf redis-5.0.14.tar.gz

[root@localhost ~]# cd redis-5.0.14/

[root@localhost redis-5.0.14]# make

[root@localhost redis-5.0.14]# make PREFIX=/usr/local/redis install

[root@localhost ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/

[root@localhost redis-5.0.14]# cd /root/redis-5.0.14/utils/

[root@localhost utils]# ./install_server.sh

2:修改配置文件(每个节点都要配置,只有IP地址不同,其他都相同)

[root@localhost ~]# vim /etc/redis/6379.conf

 bind 0.0.0.0 ##62行

protected-mode yes

port 6379

tcp-backlog 511

timeout 0

tcp-keepalive 300

daemonize yes

supervised no

pidfile /var/run/redis_6379.pid

loglevel notice

logfile /var/log/redis_6379.log

appendonly yes      ##开启 aof 持久化

。。。。。略。。。。。

cluster-enabled yes ##722行,去掉注释符,表示启用群集

cluster-config-file nodes-6379.conf ##730行,去掉注释

cluster-node-timeout 15000 ##736行,去掉注释

cluster-require-full-coverage no ##813行,去掉注释,将yes改为no

注释:

  • 开启Cluster:cluster-enabled yes
  • 集群配置文件:cluster-config-file nodes-7000.conf。这个配置文件不是要我们去配的,而是Redis运行时保存配置的文件,所以我们也不可以修改这个文件。
  • 集群超时时间:cluster-node-timeout 15000。结点超时多久则认为它宕机了。
  • 槽是否全覆盖:cluster-require-full-coverage no。默认是yes,只要有结点宕机导致16384个槽没全被覆盖,整个集群就全部停止服务,所以一定要改为no

[root@localhost ~]# /etc/init.d/redis_6379 restart

[root@localhost ~]# netstat -anpt | grep 6379

tcp        0      0 192.168.10.101:6379     0.0.0.0:*               LISTEN      20315/redis-server  

tcp        0      0 192.168.10.101:16379    0.0.0.0:*               LISTEN      20315/redis-server

3:创建redis群集

redis-cli --cluster create --cluster-replicas 1 192.168.10.101:6379 192.168.10.102:6379 192.168.10.103:6379 192.168.10.104:6379 192.168.10.105:6379 192.168.10.106:6379

备注:

需要至少3个master节点,副本数至少为1,即每个master需要一个从节点

5:测试群集

[root@localhost ~]# redis-cli -h 192.168.10.106 -p 6379 -c

192.168.10.106:6379> set centos 7.3

192.168.10.106:6379> get centos

192.168.10.106:6379> quit

[root@localhost ~]# redis-cli -h 192.168.10.105 -p 6379 -c

192.168.10.105:6379> get centos

192.168.10.105:6379> quit

6:集群信息查看

[root@localhost ~]# redis-cli

192.168.10.106:6379> cluster nodes

7:添加节点

[root@localhost ~]# redis-cli -c -p 6379 cluster meet 192.168.10.107 6379

OK

[root@localhost ~]# redis-cli

127.0.0.1:6379> cluster nodes

注意:

添加完后此新节点是master的角色

8:添加节点的另一中方法

redis-cli --cluster add-node 192.168.10.109:6379 192.168.10.107:6379

注意:

10.109是要新添加的节点,10.107是当前集群中的任意一个节点

9:修改新节点为其他节点的从节点

[root@localhost ~]# redis-cli -h 192.168.10.109 -p 6379

192.168.10.109:6379> cluster replicate 5472bbc9226737ca2199e146080ddaa41686a694

让10.109称为10.107的从节点,此ID是10.107的ID

10:重新分配槽位

重新分片基本上意味着将slot 重新分配,就像集群创建一样,它是使用 redis-cli 实用程序完成的。

注意:平均分配所有的槽位,使用以下命令会自动降16384个槽位自动分配给集群的每一个master,不用手动指定槽为分配。

redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 192.168.10.101:6379

只需要指定一个老的节点(10.21.108.174:3001),redis 会自动查找其他节点。 

11:删除节点

(1)清除10.109的槽位信息

[root@localhost ~]# redis-cli -h 192.168.10.109 -p 6379

192.168.10.109:6379> flushall

OK

192.168.10.109:6379> cluster reset

OK

(2)删除10.109的节点

redis-cli --cluster del-node 192.168.10.101:6379 fe75330d96c2c3af9c5a02b9819d66b2e8a48da2

注意:

此ID为10.107的ID

集群排错思路

注意1:

在创建redis集群服务时,提示以下错误:

/usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis/client.rb:124:in `call': ERR Slot 0 is already busy (Redis::CommandError)

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:3282:in `block in cluster'

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:50:in `block in synchronize'

from /usr/local/rvm/rubies/ruby-2.4.5/lib/ruby/2.4.0/monitor.rb:214:in `mon_synchronize'

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:50:in `synchronize'

from /usr/local/rvm/gems/ruby-2.4.5/gems/redis-4.1.0/lib/redis.rb:3281:in `cluster'

from ./redis-trib.rb:212:in `flush_node_config'

from ./redis-trib.rb:906:in `block in flush_nodes_config'

from ./redis-trib.rb:905:in `each'

from ./redis-trib.rb:905:in `flush_nodes_config'

from ./redis-trib.rb:1426:in `create_cluster_cmd'

from ./redis-trib.rb:1830:in `<main>'

错误提示是说:slot插槽被占用了、这是因为 搭建集群前时,以前redis的旧数据和配置信息没有清理干净。

解决方案:

             用redis-cli 登录到每个节点执行  flushall  和 cluster reset  就可以了。

注意2:

如果配置文件中没有监听127.0.0.1,在使用/etc/init.d/redis_6379.conf start启动redis服务时(停止或重启都是如此),会提示连接127.0.0.1:6379失败

解决方法:

使用如下方法启动

[root@localhost ~]# redis-server /etc/redis/6379.conf

使用如下命令关闭

[root@localhost ~]# redis-cli -h 192.168.10.103 -p 6379 shutdown

注意3:

配置文件中如果没有监听127.0.0.1的地址,在连接是需要使用如下方法:

redis-cli -h 192.168.10.101 -p 6379

这里的ip为本机监听的ip

注意4:

在做群集的时候各个节点不要监听127.0.0.1的地址,否则,在建立群集时会有如下情况

>>> Creating cluster

>>> Performing hash slots allocation on 6 nodes...

Using 3 masters:

192.168.10.101:6379

192.168.10.102:6379

192.168.10.103:6379

Adding replica 192.168.10.104:6379 to 192.168.10.101:6379

Adding replica 192.168.10.105:6379 to 192.168.10.102:6379

Adding replica 192.168.10.106:6379 to 192.168.10.103:6379

M: 4d06690cfdc9b90f0fd5a03d90c00502b4f33c35 192.168.10.101:6379

   slots:0-5460 (5461 slots) master

M: 9bcde42c8b5f3f1b0c23787cd5776a01eaedb2e1 192.168.10.102:6379

   slots:5461-10922 (5462 slots) master

M: 0f7864b42a3e7ab0f6d738bd066e18d0de1f4893 192.168.10.103:6379

   slots:10923-16383 (5461 slots) master

S: 61165338694dab2381308edf8d63b2a6fc68e558 192.168.10.104:6379

   replicates 4d06690cfdc9b90f0fd5a03d90c00502b4f33c35

S: efe896c8745ce4e001d8c84588ba67a45a243a29 192.168.10.105:6379

   replicates 9bcde42c8b5f3f1b0c23787cd5776a01eaedb2e1

S: 418c2562eedac8f9cce4b1540fc8f9ff4bcf0f1c 192.168.10.106:6379

   replicates 0f7864b42a3e7ab0f6d738bd066e18d0de1f4893

Can I set the above configuration? (type 'yes' to accept): yes

>>> Nodes configuration updated

>>> Assign a different config epoch to each node

>>> Sending CLUSTER MEET messages to join the cluster

Waiting for the cluster to join...............................................................................................................................................................................................................................................................................................................................................................................

系统会一直停留在这里,这是在等待其他节点并入到群集中,需要在其他slave的主机上接受其master才可以

Adding replica 192.168.10.104:6379 to 192.168.10.101:6379

Adding replica 192.168.10.105:6379 to 192.168.10.102:6379

Adding replica 192.168.10.106:6379 to 192.168.10.103:6379

按照这里的提示登录其他slave

127.0.0.1:6379> CLUSTER MEET 192.168.10.101 6379

然后等待连接即可

其他注意事项:

  1. redis master 宕机,恢复后不会自动切为主
  2. 扩容redis cluster如果我们大量使用redis cluster的话,有一个痛点就是扩容的机器加入集群的时候,分配主从。现在只能使用命令去操作,非常的凌乱。而且如果redis cluster是线上集群或者是有数据的话,极其容易造成丢数据。
  3. redis cluster 从节点支持可读的前提下得在执行readonly执行,程序读取从节点时也需要执行。一次连接需要执行一次,客户端关闭即失效。
  4. redis cluster 启动必须以绝对路径的方式启动,如果不用绝对路径启动,会产生新的nodes.conf 文件,集群的主从对应关系就会变乱,从而导致集群奔溃。

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

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

相关文章

netscaler LDAP+RADIUS传统的双因素认证方式(之一)

如果使用传统的双因素认证方式&#xff0c;可以通过在Citrix ADC (NetScaler) 13.1上配置Gateway Virtual Server来实现LDAP和RADIUS的双因素认证。当前配置方式&#xff0c;采用Cateway vServer两个Basic Authtication Policy方式实现&#xff0c;以下是详细步骤&#xff1a; …

【码题集】习题

目录 史莱姆融合 松鼠接松果 新月轩就餐 史莱姆融合 根据题意就是一道集合合并的题&#xff0c;所以要用并查集&#xff0c;不过最后我们要输出整个序列&#xff0c;所以要在合并的时候维护一个链表&#xff0c;以便最终合并成一个大集合的时候&#xff0c;输出整个链表就是…

Kotlin Misk Web框架

Kotlin Misk Web框架 1 添加依赖1.1 build.gradle.kts1.2 settings.gradle.kts1.3 gradle.properties 2 请求接口3 程序模块4 主服务类5 测试结果 Misk 是由 Square 公司开发的一个开源的多语言服务器框架&#xff0c;主要用于构建微服务。它主要使用 Kotlin 语言&#xff0c;但…

UGC与AI引领的下一个10年,丝芭传媒已经准备好

丝芭传媒最近传来的消息&#xff0c;都跟技术相关。 基于自研AI大模型“Paro&#xff08;心乐舞河&#xff09;”的AIGPT及AIGC生成工具APP“鹦鹉人”开启用户内测。2023年3月技术测试的图形化智能社交基座“美踏元宇宙”&#xff0c;也将开放首轮用户内测。 此外&#xff0c…

Studying-代码随想录训练营day31| 56.合并区间、738.单调递增的数字、968.监控二叉树、贪心算法总结

第31天&#xff0c;贪心最后一节(ง •_•)ง&#x1f4aa;&#xff0c;编程语言&#xff1a;C 目录 56.合并区间 738.单调递增的数字 968.监控二叉树 贪心算法总结 56.合并区间 文档讲解&#xff1a;代码随想录合并区间 视频讲解&#xff1a;手撕合并区间 题目&#xf…

高效图纸管理:彩虹图纸管理软件助您一臂之力

高效图纸管理&#xff1a;彩虹图纸管理软件助您一臂之力 在制造业的激烈竞争中&#xff0c;高效图纸管理是企业提升竞争力和降低成本的关键。然而&#xff0c;传统的图纸管理方式往往存在效率低下、信息混乱等问题。此时&#xff0c;彩虹图纸管理软件凭借其卓越的性能和丰富的功…

一个vue页面复用方案

前言 问大家一个问题&#xff0c;曾经的你是否也遇到过&#xff0c;一个项目中有好几个页面长得基本相同&#xff0c;但又差那么一点&#xff0c;想用 vue extends 继承它又不能按需继承html模板部分&#xff0c;恰好 B 页面需要用的 A 页面 80% 的模板&#xff0c;剩下的 20%…

【验收支撑】软件系统验收计划书(直接套用原件doc)

编写软件验收计划是软件开发过程中的一个关键步骤&#xff0c;其重要性体现在以下几个方面&#xff1a; 明确验收标准&#xff1a;软件验收计划详细列出了验收的标准、测试方法、测试环境等&#xff0c;确保所有相关人员对验收的期望和要求有清晰的认识。这有助于避免在验收阶段…

triton需要cuda11.8版本--so 安装个11.8的cuda

1.安装一个11.8的cuda 查看ubunto版本 lsb_release -a查看cpu架构 uname -m到官网得到相应的命令&#xff1a;CUDA Toolkit Archive | NVIDIA Developer 依次输入两条命令。如果没有没有sudo权限就将cuda安装路径修改在自己目录下&#xff1a; sh cuda_11.8.0_520.61.05_li…

论文AIGC率超标?一键降重快速搞定

如何有效降低AIGC论文的重复率&#xff0c;也就是我们说的aigc如何降重&#xff1f;AIGC疑似度过高确实是个比较愁人的问题。如果你用AI帮忙写了论文&#xff0c;就一定要在交稿之前做一下AIGC降重的检查。一般来说&#xff0c;如果论文的AIGC超过30%&#xff0c;很可能会被判定…

【EI征稿】第四届机器人、自动化与智能控制国际会议

【快速通道】 参会方式&#xff1a;担任会议committee成员、组建workshop 、参会报告、参会交流、审稿专家、投稿参会。 会议地点&#xff1a; 湖南 长沙 会议时间&#xff1a;12月6日-9日 会议检索&#xff1a;EI检索 会议官网&#xff1a;https://www.icraic.org/ 投稿链接&a…

华为910b推理Qwen1.5-72b

前情提要&#xff1a;华为910b部署训练推理大模型&#xff0c;本人之前并没有接触过&#xff0c;所以&#xff0c;写此文档进行记录。 &#xff08;注意&#xff1a;版本适配很重要&#xff01;&#xff01;不然就像我一样走了好多坑~~~&#xff09; 首先&#xff0c;看一张图…

大鲸鱼—docker 基本概念及安装使用

目录 一、docker前言 1.什么是Docker&#xff1f; 2.Docker的宗旨 3.容器的优点 4.Docker与虚拟机的区别 5.Docker核心概念 镜像 容器 仓库 6.为什么要用容器 7.容器越来越受欢迎的原因 8.容器在内核中支持2种重要技术 二、Docker安装 三、Docker 镜像操作 1.搜…

旷视AI开源新突破:上传照片即可生成表情包视频!

日前&#xff0c;旷视科技发布了一项新的开源AI人像视频生成框架——MegActor。该框架让用户只需输入一张静态肖像图片和一段视频&#xff08;如演讲、表情包、rap&#xff09;&#xff0c;便可生成一段表情丰富、动作一致的AI人像视频。生成的视频长度取决于输入的视频长度。与…

API接口详解及其在电子商务中的应用研究

目录 引言 一、API接口概述 1.1 API接口定义 1.2 API接口的作用 二、API接口分类 2.1 根据使用对象分类 2.2 根据协议和数据格式分类 三、API接口设计原则 四、API接口在电子商务中的应用 4.1 数据交换与集成 4.2 个性化推荐与营销 4.3 库存管理与订单处理 4.4 数…

C++ 数据结构探索:构建高效程序的基础

C 数据结构探索&#xff1a;构建高效程序的基础 在C编程的广阔领域中&#xff0c;数据结构是理解和实现高效、可维护程序的核心。数据结构是计算机存储、组织数据的方式&#xff0c;它们使得数据访问和修改操作更加高效。本文将带您走进C中几种常见且重要的数据结构&#xff0…

数据湖仓一体(一) 编译hudi

目录 一、大数据组件版本信息 二、数据湖仓架构 三、数据湖仓组件部署规划 四、编译hudi 一、大数据组件版本信息 hudi-0.14.1zookeeper-3.5.7seatunnel-2.3.4kafka_2.12-3.5.2hadoop-3.3.5mysql-5.7.28apache-hive-3.1.3spark-3.3.1flink-1.17.2apache-dolphinscheduler-3.1.9…

气膜仓储与传统仓储的成本优势对比—轻空间

随着物流和仓储需求的不断增长&#xff0c;企业对仓储设施的要求也日益提高。传统仓储设施虽然具有一定的优势&#xff0c;但在建设和运营成本上往往较高。近年来&#xff0c;气膜仓储作为一种新型仓储方式&#xff0c;以其独特的优势逐渐受到市场青睐。轻空间将详细探讨气膜仓…

spring boot实现短信验证码功能

1、到阿里云网站申请 https://market.aliyun.com/products/5700000 2/cmapi00046920.html2、配置文件&#xff0c;可申请测试 sms:app-code: xxxxxxxxxtemplate-id: xxxxxxx3、使用restTemplate用于第三方接口调用 package com.example.rsocketclient.config;import org.spr…

Altium Designer输出Gerber文件步骤

参考链接 技术指导&#xff1a;Altium Designer输出Gerber文件步骤 (jlc.com)https://www.jlc.com/portal/server_guide_10171.html 特此记录 anlog 2024年7月12日