当前位置: 首页 > news >正文

HBase客户端、服务器端、列簇设计、HDFS相关优化,HBase写性能优化切入点,写异常问题检查点

HBase客户端、服务器端、列簇设计、HDFS相关优化,HBase写性能优化切入点,写异常问题检查点

  • HBase读优化
  • 1.1 HBase客户端优化
    • 1) scan缓存是否设置合理?
    • 2) get请求是否可以使用批量请求?
    • 3) 请求是否可以显示指定列簇或者列?
    • 4) 离线批量读取请求是否设置禁止缓存?
  • 1.2 HBase服务器端优化
    • 1) 读请求是否均衡?
    • 2) BlockCache是否设置合理?
    • 3) HFile文件是否太多?
    • 4) Compaction是否消耗系统资源过多?
  • 1.3 HBase列簇设计优化
    • 1) Bloomfilter是否设置?是否设置合理?
  • 1.4 HDFS相关优化
    • 1) Short-Circuit Local Read功能是否开启?
    • 2) Hedged Read功能是否开启?
    • 3) 数据本地率是否太低?
  • 1.5 HBase读性能优化归纳
  • HBase写优化
  • 2.1 写性能优化切入点
    • 1) 是否需要写WAL?WAL是否需要同步写入?
    • 2) Put是否可以同步批量提交?
    • 3) Put是否可以异步批量提交?
    • 4) Region是否太少?
    • 5) 写入请求是否不均衡?
    • 6) 写入KeyValue数据是否太大?
      • 案件一:大字段写入导致其他业务吞吐量急剧下降
      • 案件二:大字段scan导致RegionServer宕机
  • 2.2 写异常问题检查点
    • 1) Memstore设置是否会触发Region级别或者RegionServer级别flush操作?
    • 2) Store中HFile数量是否大于配置参数blockingStoreFile?

HBase读优化

1.1 HBase客户端优化

和大多数系统一样,客户端作为业务读写的入口,姿势使用不正确通常会导致本业务读延迟较高实际上存在一些使用姿势的推荐用法,这里一般需要关注四个问题:

1) scan缓存是否设置合理?

优化原理:在解释这个问题之前,首先需要解释什么是scan缓存,通常来讲一次scan会返回大量数据,因此客户端发起一次scan请求,实际并不会一次就将所有数据加载到本地,而是分成多次RPC请求进行加载,这样设计一方面是因为大量数据请求可能会导致网络带宽严重消耗进而影响其他业务,另一方面也有可能因为数据量太大导致本地客户端发生OOM。

在这样的设计体系下用户会首先加载一部分数据到本地,然后遍历处理,再加载下一部分数据到本地处理,如此往复,直至所有数据都加载完成。数据加载到本地就存放在scan缓存中,默认100条数据大小。

通常情况下,默认的scan缓存设置就可以正常工作的。但是在一些大scan(一次scan可能需要查询几万甚至几十万行数据)来说,每次请求100条数据意味着一次scan需要几百甚至几千次RPC请求,这种交互的代价无疑是很大的。因此可以考虑将scan缓存设置增大,比如设为500或者1000就可能更加合适。

之前做过一次试验,在一次scan扫描10w+条数据量的条件下,将scan缓存从100增加到1000,可以有效降低scan请求的总体延迟,延迟基本降低了25%左右。

优化建议:大scan场景下将scan缓存从100增大到500或者1000,用以减少RPC次数

2) get请求是否可以使用批量请求?

优化原理:HBase分别提供了单条get以及批量get的API接口,使用批量get接口可以减少客户端到RegionServer之间的RPC连接数,提高读取性能。

另外需要注意的是,批量get请求要么成功返回所有请求数据,要么抛出异常。

优化建议:使用批量get进行读取请求

3) 请求是否可以显示指定列簇或者列?

优化原理:HBase是典型的列簇数据库,意味着同一列簇的数据存储在一起,不同列簇的数据分开存储在不同的目录下。

如果一个表有多个列簇,只是根据Rowkey而不指定列簇进行检索的话不同列簇的数据需要独立进行检索,性能必然会比指定列簇的查询差很多,很多情况下甚至会有2倍~3倍的性能损失。

优化建议:可以指定列簇或者列进行精确查找的尽量指定查找

4) 离线批量读取请求是否设置禁止缓存?

优化原理:通常离线批量读取数据会进行一次性全表扫描,一方面数据量很大,另一方面请求只会执行一次。这种场景下如果使用scan默认设置,就会将数据从HDFS加载出来之后放到缓存。

可想而知,大量数据进入缓存必将其他实时业务热点数据挤出,其他业务不得不从HDFS加载,进而会造成明显的读延迟毛刺

优化建议:离线批量读取请求设置禁用缓存,scan.setBlockCache(false)

1.2 HBase服务器端优化

一般服务端端问题一旦导致业务读请求延迟较大的话,通常是集群级别的,即整个集群的业务都会反映读延迟较大。可以从4个方面入手:

1) 读请求是否均衡?

优化原理:极端情况下假如所有的读请求都落在一台RegionServer的某几个Region上,这一方面不能发挥整个集群的并发处理能力,另一方面势必造成此台RegionServer资源严重消耗(比如IO耗尽、handler耗尽等),落在该台RegionServer上的其他业务会因此受到很大的波及。

可见,读请求不均衡不仅会造成本身业务性能很差,还会严重影响其他业务。当然,写请求不均衡也会造成类似的问题,可见负载不均衡是HBase的大忌。

观察确认:观察所有RegionServer的读请求QPS曲线,确认是否存在读请求不均衡现象

优化建议:RowKey必须进行散列化处理(比如MD5散列),同时建表必须进行预分区处理

2) BlockCache是否设置合理?

优化原理:BlockCache作为读缓存,对于读性能来说至关重要。默认情况下BlockCache和Memstore的配置相对比较均衡(各占40%),可以根据集群业务进行修正,比如读多写少业务可以将BlockCache占比调大。

另一方面,BlockCache的策略选择也很重要,不同策略对读性能来说影响并不是很大,但是对GC的影响却相当显著,尤其BucketCache的offheap模式下GC表现很优越。另外,HBase 2.0对offheap的改造(HBASE-11425)将会使HBase的读性能得到2~4倍的提升,同时GC表现会更好!

观察确认:观察所有RegionServer的缓存未命中率、配置文件相关配置项一级GC日志,确认BlockCache是否可以优化

优化建议:JVM内存配置量 < 20G,BlockCache策略选择LRUBlockCache;否则选择BucketCache策略的offheap模式;期待HBase 2.0的到来!

3) HFile文件是否太多?

优化原理:HBase读取数据通常首先会到Memstore和BlockCache中检索(读取最近写入数据&热点数据),如果查找不到就会到文件中检索。

HBase的类LSM结构会导致每个store包含多数HFile文件,文件越多,检索所需的IO次数必然越多,读取延迟也就越高。

文件数量通常取决于Compaction的执行策略,一般和两个配置参数有关:

hbase.hstore.compactionThreshold
hbase.hstore.compaction.max.size

前者表示一个store中的文件数超过多少就应该进行合并,后者表示参数合并的文件大小最大是多少,超过此大小的文件不能参与合并。这两个参数不能设置太"松"(前者不能设置太大,后者不能设置太小),导致Compaction合并文件的实际效果不明显,进而很多文件得不到合并。这样就会导致HFile文件数变多。

观察确认:观察RegionServer级别以及Region级别的storefile数,确认HFile文件是否过多

优化建议hbase.hstore.compactionThreshold设置不能太大,默认是3个;设置需要根据Region大小确定,通常可以简单的认为 hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold

4) Compaction是否消耗系统资源过多?

优化原理:Compaction是将小文件合并为大文件,提高后续业务随机读性能,但是也会带来IO放大以及带宽消耗问题(数据远程读取以及三副本写入都会消耗系统带宽)。

正常配置情况下Minor Compaction并不会带来很大的系统资源消耗,除非因为配置不合理导致Minor Compaction太过频繁,或者Region设置太大情况下发生Major Compaction。

观察确认:观察系统IO资源以及带宽资源使用情况,再观察Compaction队列长度,确认是否由于Compaction导致系统资源消耗过多

优化建议

  1. Minor Compaction设置:hbase.hstore.compactionThreshold设置不能太小,又不能设置太大,因此建议设置为5~6;hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold

  2. Major Compaction设置:大Region读延迟敏感业务( 100G以上)通常不建议开启自动Major Compaction,手动低峰期触发。小Region或者延迟不敏感业务可以开启Major Compaction,但建议限制流量;

  3. 期待更多的优秀Compaction策略,类似于stripe-compaction尽早提供稳定服务

1.3 HBase列簇设计优化

HBase列簇设计对读性能影响也至关重要,其特点是只影响单个业务,并不会对整个集群产生太大影响。列簇设计主要从以下方面检查:

1) Bloomfilter是否设置?是否设置合理?

优化原理:Bloomfilter主要用来过滤不存在待检索RowKey或者Row-Col的HFile文件,避免无用的IO操作。

它会告诉你在这个HFile文件中是否可能存在待检索的KV,如果不存在,就可以不用消耗IO打开文件进行seek。很显然,通过设置Bloomfilter可以提升随机读写的性能。

Bloomfilter取值有两个,row以及rowcol,需要根据业务来确定具体使用哪种。如果业务大多数随机查询仅仅使用row作为查询条件,Bloomfilter一定要设置为row,否则如果大多数随机查询使用row+cf作为查询条件,Bloomfilter需要设置为rowcol。如果不确定业务查询类型,设置为row。

优化建议:任何业务都应该设置Bloomfilter,通常设置为row就可以,除非确认业务随机查询类型为row+cf,可以设置为rowcol

1.4 HDFS相关优化

HDFS作为HBase最终数据存储系统,通常会使用三副本策略存储HBase数据文件以及日志文件。

从HDFS的角度望上层看,HBase即是它的客户端,HBase通过调用它的客户端进行数据读写操作,因此HDFS的相关优化也会影响HBase的读写性能。这里主要关注如下三个方面:

1) Short-Circuit Local Read功能是否开启?

优化原理:当前HDFS读取数据都需要经过DataNode,客户端会向DataNode发送读取数据的请求,DataNode接受到请求之后从硬盘中将文件读出来,再通过TPC发送给客户端。Short Circuit策略允许客户端绕过DataNode直接读取本地数据。(具体原理参考此处)

优化建议:开启Short Circuit Local Read功能

2) Hedged Read功能是否开启?

优化原理:HBase数据在HDFS中一般都会存储三份,而且优先会通过Short-Circuit Local Read功能尝试本地读。但是在某些特殊情况下,有可能会出现因为磁盘问题或者网络问题引起的短时间本地读取失败,为了应对这类问题,社区开发者提出了补偿重试机制 – Hedged Read。

该机制基本工作原理为:客户端发起一个本地读,一旦一段时间之后还没有返回,客户端将会向其他DataNode发送相同数据的请求。哪一个请求先返回,另一个就会被丢弃。

优化建议:开启Hedged Read功能

3) 数据本地率是否太低?

数据本地率:HDFS数据通常存储三份,假如当前RegionA处于Node1上,数据a写入的时候三副本为(Node1,Node2,Node3),数据b写入三副本是(Node1,Node4,Node5),数据c写入三副本(Node1,Node3,Node5),可以看出来所有数据写入本地Node1肯定会写一份,数据都在本地可以读到,因此数据本地率是100%。

现在假设RegionA被迁移到了Node2上,只有数据a在该节点上,其他数据(b和c)读取只能远程跨节点读,本地率就为33%(假设a,b和c的数据大小相同)。

优化原理:数据本地率太低很显然会产生大量的跨网络IO请求,必然会导致读请求延迟较高,因此提高数据本地率可以有效优化随机读性能。

数据本地率低的原因一般是因为Region迁移(自动balance开启、RegionServer宕机迁移、手动迁移等),因此一方面可以通过避免Region无故迁移来保持数据本地率,另一方面如果数据本地率很低,也可以通过执行major_compact提升数据本地率到100%。

优化建议:避免Region无故迁移,比如关闭自动balance、RS宕机及时拉起并迁回飘走的Region等;在业务低峰期执行major_compact提升数据本地率

1.5 HBase读性能优化归纳

在本文开始的时候提到读延迟较大无非三种常见的表象,单个业务慢集群随机读慢某个业务随机读之后其他业务受到影响导致随机读延迟很大

了解完常见的可能导致读延迟较大的一些问题之后,我们将这些问题进行如下归类,读者可以在看到现象之后在对应的问题列表中进行具体定位:

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

HBase写优化

和读相比,HBase写数据流程倒是显得很简单:数据先顺序写入HLog,再写入对应的缓存Memstore,当Memstore中数据大小达到一定阈值(128M)之后,系统会异步将Memstore中数据flush到HDFS形成小文件

HBase数据写入通常会遇到两类问题,一类是写性能较差,另一类是数据根本写不进去。这两类问题的切入点也不尽相同,如下图所示:

在这里插入图片描述

2.1 写性能优化切入点

1) 是否需要写WAL?WAL是否需要同步写入?

优化原理:数据写入流程可以理解为一次顺序写WAL + 一次写缓存,通常情况下写缓存延迟很低,因此提升写性能就只能从WAL入手。

WAL机制一方面是为了确保数据即使写入缓存丢失也可以恢复,另一方面是为了集群之间异步复制。默认WAL机制开启且使用同步机制写入WAL。

首先考虑业务是否需要写WAL,通常情况下大多数业务都会开启WAL机制(默认),但是对于部分业务可能并不特别关心异常情况下部分数据的丢失,而更关心数据写入吞吐量,比如某些推荐业务,这类业务即使丢失一部分用户行为数据可能对推荐结果并不构成很大影响,但是对于写入吞吐量要求很高,不能造成数据队列阻塞。这种场景下可以考虑关闭WAL写入,写入吞吐量可以提升2x~3x。退而求其次,有些业务不能接受不写WAL,但可以接受WAL异步写入,也是可以考虑优化的,通常也会带来1x~2x的性能提升。

优化推荐:根据业务关注点在WAL机制与写入吞吐量之间做出选择

其他注意点:对于使用Increment操作的业务,WAL可以设置关闭,也可以设置异步写入,方法同Put类似。相信大多数Increment操作业务对WAL可能都不是那么敏感~

2) Put是否可以同步批量提交?

优化原理:HBase分别提供了单条put以及批量put的API接口,使用批量put接口可以减少客户端到RegionServer之间的RPC连接数,提高写入性能。另外需要注意的是,批量put请求要么全部成功返回,要么抛出异常。

优化建议:使用批量put进行写入请求

3) Put是否可以异步批量提交?

优化原理:业务如果可以接受异常情况下少量数据丢失的话,还可以使用异步批量提交的方式提交请求。提交分为两阶段执行:用户提交写请求之后,数据会写入客户端缓存,并返回用户写入成功;当客户端缓存达到阈值(默认2M)之后批量提交给RegionServer。需要注意的是,在某些情况下客户端异常的情况下缓存数据有可能丢失。

优化建议:在业务可以接受的情况下开启异步批量提交

使用方式:setAutoFlush(false)

4) Region是否太少?

优化原理:当前集群中表的Region个数如果小于RegionServer个数,即Num(Region of Table) < Num(RegionServer),可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度,如果Num(Region of Table) > Num(RegionServer),再增加Region个数效果并不明显。

优化建议:在Num(Region of Table) < Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer;

5) 写入请求是否不均衡?

优化原理:另一个需要考虑的问题是写入请求是否均衡,如果不均衡,一方面会导致系统并发度较低,另一方面也有可能造成部分节点负载很高,进而影响其他业务。分布式系统中特别害怕一个节点负载很高的情况,一个节点负载很高可能会拖慢整个集群,这是因为很多业务会使用Mutli批量提交读写请求,一旦其中一部分请求落到该节点无法得到及时响应,就会导致整个批量请求超时。因此不怕节点宕掉,就怕节点奄奄一息!

优化建议:检查RowKey设计以及预分区策略,保证写入请求均衡。

6) 写入KeyValue数据是否太大?

KeyValue大小对写入性能的影响巨大,一旦遇到写入性能比较差的情况,需要考虑是否由于写入KeyValue数据太大导致。KeyValue大小对写入性能影响曲线图如下:

在这里插入图片描述

图中横坐标是写入的一行数据(每行数据10列)大小,左纵坐标是写入吞吐量,右坐标是写入平均延迟(ms)。可以看出随着单行数据大小不断变大,写入吞吐量急剧下降,写入延迟在100K之后急剧增大。

说到这里,有必要和大家分享两起在生产线环境因为业务KeyValue较大导致的严重问题,一起是因为大字段业务写入导致其他业务吞吐量急剧下降,另一起是因为大字段业务scan导致RegionServer宕机。

案件一:大字段写入导致其他业务吞吐量急剧下降

部分业务反馈集群写入忽然变慢、数据开始堆积的情况,查看集群表级别的数据读写QPS监控,发现问题的第一个关键点:业务A开始写入之后整个集群其他部分业务写入QPS都几乎断崖式下跌,初步怀疑黑手就是业务A。

下图是当时业务A的写入QPS(事后发现忘了截取其他表QPS断崖式下跌的惨象),但是第一感觉是QPS并不高啊,怎么去影响别人!

在这里插入图片描述

于是就继续查看其他监控信息,首先确认系统资源(主要是IO)并没有到达瓶颈,其次确认了写入的均衡性,直至看到下图,才追踪到影响其他业务写入的第二个关键点:RegionServer的handler(配置150)被残暴耗尽:

在这里插入图片描述

对比上面两张图,是不是发现出奇的一致,那就可以基本确认是由于该业务写入导致这台RegionServer的handler被耗尽,进而其他业务拿不到handler,自然写不进去。那问题来了,为什么会这样?

正常情况下handler在处理完客户端请求之后会立马释放,唯一的解释是这些请求的延迟实在太大

试想,我们去汉堡店排队买汉堡,有150个窗口服务,正常情况下大家买一个很快,这样150个窗口可能只需要50个服务。假设忽然来了一批大汉,要定制超大汉堡,好了,所有的窗口都工作起来,而且因为大汉堡不好制作导致服务很慢,这样必然会导致其他排队的用户长时间等待,直至超时。

可回头一想这可是写请求啊,怎么会有这么大的请求延迟!和业务方沟通之后确认该表主要存储语料库文档信息,都是平均100K左右的数据,是不是已经猜到了结果,没错,就是因为这个业务KeyValue太大导致。KeyValue太大会导致HLog文件写入频繁切换、flush以及compaction频繁触发,写入性能急剧下降

目前针对这种较大KeyValue写入性能较差的问题还没有直接的解决方案,好在社区已经意识到这个问题,在接下来即将发布的下一个大版本HBase 2.0.0版本会针对该问题进行深入优化,详见HBase MOB,优化后用户使用HBase存储文档、图片等二进制数据都会有极佳的性能体验。

案件二:大字段scan导致RegionServer宕机

案件现场:有段时间有个0.98集群的RegionServer经常频繁宕机,查看日志是由于”java.lang.OutOfMemoryError: Requested array size exceeds VM limit”,如下图所示:

在这里插入图片描述

原因分析:通过查看源码以及相关文档,确认该异常发生在scan结果数据回传给客户端时由于数据量太大导致申请的array大小超过JVM规定的最大值( Interge.Max_Value-2)。造成该异常的两种最常见原因分别是:

  • 表列太宽(几十万列或者上百万列),并且scan返回没有对列数量做任何限制,导致一行数据就可能因为包含大量列而数据超过array大小阈值
  • KeyValue太大,并且scan返回没有对返回结果大小做任何限制,导致返回数据结果大小超过array大小阈值

有的童鞋就要提问啦,说如果已经对返回结果大小做了限制,在表列太宽的情况下是不是就可以不对列数量做限制呢。这里需要澄清一下,如果不对列数据做限制,数据总是一行一行返回的,即使一行数据大小大于设置的返回结果限制大小,也会返回完整的一行数据。在这种情况下,如果这一行数据已经超过array大小阈值,也会触发OOM异常。

解决方案:目前针对该异常有两种解决方案,其一是升级集群到1.0,问题都解决了。其二是要求客户端访问的时候对返回结果大小做限制(scan.setMaxResultSize(210241024))、并且对列数量做限制(scan.setBatch(100)),当然,0.98.13版本以后也可以对返回结果大小在服务器端进行限制,设置参数hbase.server.scanner.max.result.size即可

2.2 写异常问题检查点

上述几点主要针对写性能优化进行了介绍,除此之外,在一些情况下还会出现写异常,一旦发生需要考虑下面两种情况(GC引起的不做介绍):

1) Memstore设置是否会触发Region级别或者RegionServer级别flush操作?

问题解析:以RegionServer级别flush进行解析,HBase设定一旦整个RegionServer上所有Memstore占用内存大小总和大于配置文件中upperlimit时,系统就会执行RegionServer级别flush,flush算法会首先按照Region大小进行排序,再按照该顺序依次进行flush,直至总Memstore大小低至lowerlimit。这种flush通常会block较长时间,在日志中会发现“Memstore is above high water mark and block 7452 ms”,表示这次flush将会阻塞7s左右。

问题检查点

  • Region规模与Memstore总大小设置是否合理?如果RegionServer上Region较多,而Memstore总大小设置的很小(JVM设置较小或者upper.limit设置较小),就会触发RegionServer级别flush。集群规划相关内容可以参考文章《HBase最佳实践-集群规划》
  • 列族是否设置过多,通常情况下表列族建议设置在1~3个之间,最好一个。如果设置过多,会导致一个Region中包含很多Memstore,导致更容易触到高水位upperlimit

2) Store中HFile数量是否大于配置参数blockingStoreFile?

问题解析:对于数据写入很快的集群,还需要特别关注一个参数:hbase.hstore.blockingStoreFiles,此参数表示如果当前hstore中文件数大于该值,系统将会强制执行compaction操作进行文件合并,合并的过程会阻塞整个hstore的写入。通常情况下该场景发生在数据写入很快的情况下,在日志中可以发现"Waited 3722ms on a compaction to clean up ‘too many store files"

问题检查点

  • 参数设置是否合理?hbase.hstore.compactionThreshold表示启动compaction的最低阈值,该值不能太大,否则会积累太多文件,一般建议设置为5~8左右。hbase.hstore.blockingStoreFiles默认设置为7,可以适当调大一些。

相关文章:

HBase客户端、服务器端、列簇设计、HDFS相关优化,HBase写性能优化切入点,写异常问题检查点

HBase客户端、服务器端、列簇设计、HDFS相关优化&#xff0c;HBase写性能优化切入点&#xff0c;写异常问题检查点HBase读优化1.1 HBase客户端优化1) scan缓存是否设置合理&#xff1f;2) get请求是否可以使用批量请求&#xff1f;3) 请求是否可以显示指定列簇或者列&#xff1…...

DINO-DETR在COCO缩减数据集上实验结果分析

博主在进行DINO-DETR模型实验时&#xff0c;使用缩减后的COCO数据集进行训练&#xff0c;发现其mAP值只能达到0.27作用&#xff0c;故而修改了下pycocotool的代码&#xff0c;令其输出每个类别的AP值&#xff0c;来看看是由于什么原因导致这个问题。 之所以这样是因为博主认为各…...

语聊房app源码及架构设计

语音社交产品技术架构设计 语音社交产品的技术架构设计是产品开发中非常重要的一环。在设计时需要考虑产品的功能、性能、可靠性等多个方面&#xff0c;同时也需要与产品策划与设计相协调。以下是语音社交产品技术架构设计的主要内容。 架构设计原则 在设计语音社交产品的技…...

什么是软件测试?5分钟带你快速了解!

经常有人问我&#xff0c;你的公司是做什么的&#xff1f;我回答“软件测试”&#xff0c;看着对方一脸的迷茫。何为软件测试&#xff1f;软件测试究竟测试什么&#xff1f;一、软件测试的定义和意义软件测试是伴随着软件工程的重要组成部分&#xff0c;是软件质量保证的重要前…...

[3D游戏开发实践] Cocos Cyberpunk 源码解读-手把手教你新增一个后效Shader

Cocos Cyberpunk 是 Cocos 引擎官方团队以展示引擎重度 3D 游戏制作能力&#xff0c;提升社区学习动力而推出的完整开源 TPS 3D游戏&#xff0c;支持 Web, IOS, Android 多端发布。 本系列文章将从各个方面对源码进行解读&#xff0c;提升大家的学习效率。希望能够帮助大家在 …...

构建产品帮助中心,促进SaaS企业的进步

长期来看&#xff0c;保留现有客户比获取新客户更为关键&#xff0c;因此建立良好的客户服务质量需要着重关注客户心理状态。 什么是 SaaS SaaS是软件即服务&#xff08;Software as a Service&#xff09;的缩写。它是一种软件交付模式&#xff0c;其中软件应用程序托管在云计…...

【Qt】Qt单元测试详解(四):Google Test

1、创建测试工程 【Qt】Qt单元测试详解(一):通过QtCreator创建测试工程 2、添加测试代码 2.1 默认生成的代码 1)项目工程pro include(gtest_dependency.pri)TEMPLATE = app CONFIG += console c++14 CONFIG -= app_bundle CONFIG += thread CONFIG -= qtHEADERS += \t…...

容器引擎Docker的常用命令

一.镜像相关命令 1.搜索镜像 可使用 docker search命令搜索存放在 Docker Hub中的镜像。执行该命令后&#xff0c; Docker就会在Docker Hub中搜索含有 java这个关键词的镜像仓库 docker search java以上列表包含五列&#xff0c;含义如下&#xff1a; NAME:镜像仓库名称。D…...

vue尚品汇商城项目-day01【3.项目路由的分析】

文章目录本人其他相关文章链接安装命令&#xff1a;cnpm install --save vue-router vue-router 前端所谓路由&#xff1a;kv键值对 key:URL(地址栏中的路径) value:相应的路由组件 注意&#xff1a;本项目是上中下结构 路由组件&#xff1a; Home首页路由组件、Search路由组件…...

详解--高级IO

文章目录前言一、五种IO模型阻塞IO非阻塞IO信号驱动IOIO多路转接:异步IO二、高级IO同步通信和异步通信阻塞 VS 非阻塞其他高级IO三、非阻塞IOfcntl实现函数SetNoBlock总结前言 理解五种IO模型的基本概念.重点是IO多路转接. 正文开始! 一、五种IO模型 IO: 等 数据拷贝 read/…...

Android自定义闹钟

google推荐方式3种&#xff1a; 一、AlarmManager setRepeating() 重复闹钟。1、Android 4.4&#xff08;API 级别 19&#xff09;开始&#xff0c;所有重复闹钟都是不精确的&#xff0c;延时2分钟左右。2、闹钟触发的待定 Intent。当您设置使用同一待定 Intent 的第二个闹钟…...

第02章_MySQL环境搭建

第02章_MySQL环境搭建 &#x1f3e0;个人主页&#xff1a;shark-Gao &#x1f9d1;个人简介&#xff1a;大家好&#xff0c;我是shark-Gao&#xff0c;一个想要与大家共同进步的男人&#x1f609;&#x1f609; &#x1f389;目前状况&#xff1a;23届毕业生&#xff0c;目前…...

java使用线程池和Future接口实现异步的实例

线程池可以提供线程的复用和管理&#xff0c;避免线程频繁创建和销毁的开销。而Future接口则可以获取异步任务的执行结果和状态&#xff0c;避免了阻塞等待异步任务完成的情况。下面是一个简单的示例代码&#xff1a; import java.util.concurrent.*;public class AsyncExample…...

cocosCreator 事件系统

概述&#xff1a; DOM的输入事件通过CCInputManager转化成cocos的输入事件&#xff0c;由CCEventManager 分发给监听器。 监听器在通过回调函数(begin/move/end/cancel)告知事件派发对象&#xff08;eventTarget&#xff09;派发事件。 重要类&#xff1a; event&#xff1…...

刷题_20:字符串反转 and 公共子串计算

一.字符串反转 题目链接&#xff1a; 字符串反转 题目描述&#xff1a; 接受一个只包含小写字母的字符串&#xff0c;然后输出该字符串反转后的字符串。&#xff08;字符串长度不超过1000&#xff09; 输入描述&#xff1a; 输入一行&#xff0c;为一个只包含小写字母的字符串…...

如何在 Linux 命令行中比较两个目录,我教你五个命令!

在 Linux 命令行中比较两个目录是一项常见的任务&#xff0c;特别是当你需要确保两个目录之间的文件完全相同时。在本文中&#xff0c;我们将介绍一些在 Linux 命令行中比较两个目录的方法。 方法一&#xff1a;使用 diff 命令比较两个目录 diff 命令可以比较两个文件或目录之…...

多元算力如何满足万千本土化场景需求,解析第四代至强核心加速器设计

作者 | 宋慧 出品 | CSDN 云计算 2023 年初&#xff0c;英特尔重磅发布了企业级芯片领域重要的产品——第四代英特尔 至强 可扩展处理器。当时报道中&#xff0c;我们就重点提到了其中重要的七大内置加速器&#xff0c;这也是英特尔为千行百业多种创新场景去提供算力支持的底气…...

SPI主模式切换为从模式

一、SPI主模式切换为从模式在SPI总线上&#xff0c;要将主设备转换为从设备或者将从设备转换为主设备&#xff0c;需要通过改变SPI控制寄存器的配置来实现。下面分别介绍SPI主模式切换为从模式的步骤&#xff1a;配置从设备的SPI控制寄存器首先需要配置从设备的SPI控制寄存器。…...

IMX6ULL学习笔记(21)——MMDC接口使用(DDR3测试)

一、MMDC简介 MMDC 接口与 STM32 的 FSMC 接口类似&#xff0c;只不过 MMDC 接口专用于外接 DDR&#xff0c;并且 MMDC 外部引脚不复用。MMDC 是一个多模的 DDR 控制器&#xff0c;可以连接 16 位宽的 DDR3/DDR3L、16 位宽的 LPDDR2。 MMDC 是一个可配置、高性能的 DDR 控制器。…...

机器学习——无监督学习

机器学习的分类一般分为下面几种类别&#xff1a;监督学习( supervised Learning )无监督学习( Unsupervised Learning )强化学习( Reinforcement Learning&#xff0c;增强学习)半监督学习( Semi-supervised Learning )深度学习(Deep Learning)Python Scikit-learn. http: // …...

利用最小二乘法找圆心和半径

#include <iostream> #include <vector> #include <cmath> #include <Eigen/Dense> // 需安装Eigen库用于矩阵运算 // 定义点结构 struct Point { double x, y; Point(double x_, double y_) : x(x_), y(y_) {} }; // 最小二乘法求圆心和半径 …...

web vue 项目 Docker化部署

Web 项目 Docker 化部署详细教程 目录 Web 项目 Docker 化部署概述Dockerfile 详解 构建阶段生产阶段 构建和运行 Docker 镜像 1. Web 项目 Docker 化部署概述 Docker 化部署的主要步骤分为以下几个阶段&#xff1a; 构建阶段&#xff08;Build Stage&#xff09;&#xff1a…...

Xshell远程连接Kali(默认 | 私钥)Note版

前言:xshell远程连接&#xff0c;私钥连接和常规默认连接 任务一 开启ssh服务 service ssh status //查看ssh服务状态 service ssh start //开启ssh服务 update-rc.d ssh enable //开启自启动ssh服务 任务二 修改配置文件 vi /etc/ssh/ssh_config //第一…...

【Linux】C语言执行shell指令

在C语言中执行Shell指令 在C语言中&#xff0c;有几种方法可以执行Shell指令&#xff1a; 1. 使用system()函数 这是最简单的方法&#xff0c;包含在stdlib.h头文件中&#xff1a; #include <stdlib.h>int main() {system("ls -l"); // 执行ls -l命令retu…...

Day131 | 灵神 | 回溯算法 | 子集型 子集

Day131 | 灵神 | 回溯算法 | 子集型 子集 78.子集 78. 子集 - 力扣&#xff08;LeetCode&#xff09; 思路&#xff1a; 笔者写过很多次这道题了&#xff0c;不想写题解了&#xff0c;大家看灵神讲解吧 回溯算法套路①子集型回溯【基础算法精讲 14】_哔哩哔哩_bilibili 完…...

大数据零基础学习day1之环境准备和大数据初步理解

学习大数据会使用到多台Linux服务器。 一、环境准备 1、VMware 基于VMware构建Linux虚拟机 是大数据从业者或者IT从业者的必备技能之一也是成本低廉的方案 所以VMware虚拟机方案是必须要学习的。 &#xff08;1&#xff09;设置网关 打开VMware虚拟机&#xff0c;点击编辑…...

抖音增长新引擎:品融电商,一站式全案代运营领跑者

抖音增长新引擎&#xff1a;品融电商&#xff0c;一站式全案代运营领跑者 在抖音这个日活超7亿的流量汪洋中&#xff0c;品牌如何破浪前行&#xff1f;自建团队成本高、效果难控&#xff1b;碎片化运营又难成合力——这正是许多企业面临的增长困局。品融电商以「抖音全案代运营…...

c++ 面试题(1)-----深度优先搜索(DFS)实现

操作系统&#xff1a;ubuntu22.04 IDE:Visual Studio Code 编程语言&#xff1a;C11 题目描述 地上有一个 m 行 n 列的方格&#xff0c;从坐标 [0,0] 起始。一个机器人可以从某一格移动到上下左右四个格子&#xff0c;但不能进入行坐标和列坐标的数位之和大于 k 的格子。 例…...

Java 加密常用的各种算法及其选择

在数字化时代&#xff0c;数据安全至关重要&#xff0c;Java 作为广泛应用的编程语言&#xff0c;提供了丰富的加密算法来保障数据的保密性、完整性和真实性。了解这些常用加密算法及其适用场景&#xff0c;有助于开发者在不同的业务需求中做出正确的选择。​ 一、对称加密算法…...

从零实现STL哈希容器:unordered_map/unordered_set封装详解

本篇文章是对C学习的STL哈希容器自主实现部分的学习分享 希望也能为你带来些帮助~ 那咱们废话不多说&#xff0c;直接开始吧&#xff01; 一、源码结构分析 1. SGISTL30实现剖析 // hash_set核心结构 template <class Value, class HashFcn, ...> class hash_set {ty…...