首页 > 数据库 >redis_原理

redis_原理

时间：2023-12-23 15:55:42浏览次数：41  
标签：字节 ZipList redis 链表 FD IO 原理 节点

redis_原理

数据结构

1.动态字符串SDS

C语言字符串存在的问题：

  • 获取字符串长度需要通过运算
  • 非二进制安全
  • 不可修改

redis构建了一种新的字符串结构，简单动态字符串Simple Dynamic String SDS

Redis是C语言实现的，其中SDS是一个结构体，属性包括：

  1. uint8_t len：buf已保存的字符串字节数，不包含结束标示。
  2. uint8_t alloc：buf申请的总的字节数，不包含结束结束标示。
  3. unsigned char flags：不同SDS的头类型，用来控制SDS的头大小。
  4. char buf[]

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力

动态扩容：

  • 如果新字符串小于1M，则新空间为扩展后字符串长度的2倍+1（alloc=新字符串长度的2倍）+（结束字符\0的1位）
  • 如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。称为内存预分配。

alloc=新空间大小-1（除去结束标示）

动态字符串优点

  1. 获取字符串长度的时间复杂度为O（1）
  2. 支持动态扩容
  3. 减少内存分配次数
  4. 二进制安全

2.IntSet整数集合

IntSet是redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有效等特征。属性包括：

  1. uint32_t encoding：编码方式，支持存放16位，32位，64位整数（2字节～类似short，4字节～类似int，8字节～类似long）
  2. uint32_t length：元素个数
  3. int8x _t contents[]：整数数组，保存集合数据 （可能变成int16、int32...？）
    为了方便查找，redis会将IntSet中所有的整数按照升序依次保存在content数组中。

IntSet升级
原元素：5、10、20（int16_t)，现在添加一个5000，超过int16_t的范围，intset会自动升级编码方式到合适的大小。流程如下：

  1. 升级编码为INTSET_ENC_INT32。每个整数占4字节，并按照新的编码方式及元素个数扩容数组。
  2. 倒序依次将数组中的元素拷贝到扩容后的正确位置
  3. 将待添加的元素放入数组末尾
  4. 最后，将intset的encoding属性改为INTSET_ENC_INT32，将length属性改为4（3+1）

IntSet可以看做是特殊的整数数组，具备一些特点：

  1. redis会确保intset中的元素唯一、有序
  2. 具备类型升级机制，可以节省内存空间
  3. 底层采用二分查找方式来查询

3.Dict

我们知道redis是一个键值型（key-value pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。
Dict由三部分组成，分别是：哈希表DictHashTable、哈希节点DictEntry、字典Dict
字典dict属性：

  1. dictType *type：dict类型，内置不同的hash函数
  2. void *privdata：私有数据，在做特殊hash运算时使用
  3. dictht ht[2]：一个dict包含2个哈希表，其中一个是当前数据，另一个一般是空，rehash时使用。
  4. long rehashidx：rehash的进度，-1表示未进行
  5. int16_t pauserehash：rehash是否暂停，1则暂停，0则继续

哈希表dictht的属性：

  1. dictEntry **table：entry数组，数组中保存的是指向entry的指针
  2. unsigned long size：哈希表大小
  3. unsigned long sizemask：哈希表大小的掩码，总等于size-1
  4. unsigned long used：entry个数

哈希节点dictEntry的属性：

  1. void *key：键
  2. union{*val,u64,s64,d}v：值
  3. struct dictEntry *next：下一个Entry的指针
    image

dict的扩容
Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。
Dict在每次新增键值对时都会检查负载因子LoadFactor=used/size，满足以下2种情况时会触发哈希表扩容：

  • 哈希表的LoadFactor >=1，并且服务器没有执行BGSAVE或BGREWRITEAOF等后台进程
  • 哈希表的LoadFactor > 5

扩容后：变为used+1，底层会对扩容大小做判断，实际上找的是第一个>=used+1的2^n

Dict的收缩
Dict除了扩容以外，每次删除元素时，也会对负载因子做检查，当LoadFactor < 0.1 时，会做哈希表收缩

收缩后的大小：第一个大于等于used的2^n

Dict的rehash
不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程叫rehash：

  1. 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：
    • 如果是扩容，则新size=第一个大于等于dict.ht[0].used + 1 的2^n
    • 如果是收缩，则新size=第一个大于等于dict.ht[0].used的2^n(不得小于4)
  2. 按照新的realSize申请内存空间，创建dictht，并赋值给dict.ht[1]
  3. 设置dict.rehashidx = 0，标示开始rehash
  4. 将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]
  5. 将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存

渐进式rehash
image

总结
Dict的结构：

  • 类似java的HashTable，底层是数组+链表来解决哈希冲突
  • Dict包含2个哈希表，ht[0]平常用，ht[1]用来rehash

Dict的伸缩：

  • 当LoadFactor>5或者LoadFactor>1且没有子进程任务时，Dict扩容
  • 当LoadFactor小于0.1时，Dict收缩
  • 扩容后大小为第一个大于等于used + 1的2^n
  • 收缩大小为第一个大于等于used的2^n
  • Dict采用渐进式rehash，每次访问Dict时执行一次rehash
  • rehash时ht[0]只减不增，新增操作只在ht[1]执行，其它操作在两个哈希表

4.ZipList

ZipList是一种特殊的“双端链表”，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作，并且该操作的时间复杂度为O（1）
属性：

  1. zlbytes：记录整个压缩列表占用的内存字节数
  2. zltail：记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。
  3. zllen：记录了压缩列表包含的节点数量。最大值为UINT16_MAX(65534)，如果超过这个值，此处会记录为65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。
  4. entry：压缩列表包含的各个节点，节点的 长度由节点保存的内容决定
  5. zlend：特殊值0xFF（十进制255），用于标记压缩列表的末端

ZipListEntry
ZipList中的Entry并不像普通链表那样记录前后节点的指针，因为记录2个指针要占用16个字节，浪费内存，而是采用了下面的结构：
属性：

  1. previous_entry_length：前一节点的长度，占1个或5个字节
    • 如果前一个节点长度小于254字节，则采用1字节
    • 如果前一节点长度大于254字节，则采用5字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
  2. encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1、2或5个字节（00、01、10开头：字符串。11开头：整数，且encoding固定只占用1个字节）
  3. contents：负责保存节点的数据，可以是字符串或整数。

注意：ZipList中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。例如：0x1234->小端0x3412

ZipList这样编码的目的：尽可能减少内存。

ZipList也有限制：遍历只能从前向后或者从后向前（如果长度过长，会出现问题，所以使用时ZipList会限制长度）

ZipList的连锁更新问题
ZipList的每一个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节。

  • 如果前一个节点的长度小于254字节，则采用1字节来保存这个长度值
  • 如果前一个节点的长度大于等于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后4个字节才是真实数据长度。

假设我们有N个连续的、长度为250~253之间的entry，因此entry的previous_entry_length属性用1个字节即可表示。
现在在头部（左端）插入一个254字节的entry，后面节点的previous_entry_length都要依次变成5。ZipList在这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新。新增、删除都可能导致连锁更新的发生。
（目前这个问题，redis的作者并没有解决它，因为它发生的概率非常低）

总结-ZipList特性

  1. 压缩列表可以看做一种连续内存空间的“双向链表”
  2. 列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低。
  3. 如果列表数据过多，导致链表过长，可能影响查询性能。
  4. 增或删较大数据时有可能发生连续更新问题。

QuickList

它是一个双端链表，只不过链表的每个节点都是一个ZipList

为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：list-max-ziplist-size来限制。

  • 如果值为正，则代表ZipList的允许的entry个数的最大值
  • 如果为负，则代表ZipList的最大内存大小（-1:每个ZipList的内存占用不能超过4kb。-2:8kb。-3:16kb。-4:32kb。-5:64kb）
  • （默认-2）

压缩
QuickList还可以对节点的ZipList做压缩。通过配置项list-compress-depth来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。这个参数控制首尾不压缩的节点个数：

  • 0:特殊值，代表不压缩
  • 1:标示QuickList的首尾各有1个节点不压缩，中间节点压缩
  • 2:标示QuickList的首尾各有2个节点不压缩，中间节点压缩
  • 以此类推
  • 默认值0

压缩的原因：一般我们对首尾的操作比较多，中间的节点一般用不到。

quicklist的属性：

  1. *head： 头节点指针
  2. *tail： 尾节点指针
  3. count： 所有ziplist的entry的数量
  4. len： ziplists总数量
  5. QL_FILL_BITS：ziplist的entry上限，默认值-2
  6. QL_COMP_BITS：首尾不压缩的节点数量

quicklistNode的属性：

  1. *prev：前一个节点指针
  2. *next：下一个节点指针
  3. *zl：当前节点的ZipList指针
  4. sz：当前节点的ZipList的字节大小
  5. count：当前节点的ZipList的entry个数
  6. encoding：编码方式（1:ZipList。2:lzf压缩模式）

QuickList的特点

  • 是一个节点为ZipList的双端链表
  • 节点采用ZipList，解决了传统链表的内存占用问题
  • 控制了ZipList大小，解决连续内存空间申请效率问题
  • 中间节点可以压缩，进一步节省了内存

可以这样理解：QuickList兼具了链表和ZipList（压缩列表）的优点（内存不用连续+内存占用小）

SkipList

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：

  • 元素按照升序排列存储
  • 节点可能包含多个指针，指针跨度不同

zskiplist属性：

  1. *head：头节点指针
  2. *tail：尾节点指针
  3. length：节点数量
  4. level：最大的索引层级，默认是1

skiplistNode属性：

  1. ele：节点存储的值
  2. score：节点分数，排序、查找用
  3. *backward：前一个节点指针
  4. level[]：多级索引数组（数组的每一个元素：1*forward：下一个节点指针。2span：索引跨度）

SkipList的特点

  • 跳表是一个双向链表，每个节点都包含score和ele值
  • 节点按照score值排序，score值一样则按照ele字典排序
  • 每个节点都可以包含多层指针，层数是1道32之间的随机数
  • 不同层指针到下一个节点的跨度不同，层级越高，跨度越大
  • 增删改查效率与红黑树基本一致，实现却更简单。

RedisObject

Redis中的任意数据类型的键和值都会被封装成一个RedisObject，也叫redis对象，属性如下：

  1. type：对象类型（string，hash，list，set，zset）占4个bit
  2. encoding：底层编码方式（11种）4bit
  3. LRU_BITS：该对象最后一次被访问的时间，24bit
  4. refcount：对象引用计数器，计数器为0说明对象无人引用，可以被回收。
  5. *ptr：指针，指向存放实际数据的空间。

11种编码方式
0raw，1long，2hash，3已废弃，4双端链表，5压缩列表，6整数集合，7跳表，8embstr的动态字符串，9快速列表，10stream流

5种数据结构

  1. string：编码方式int，embstr，raw
  2. list：编码方式双端链表，快速列表
  3. set：编码方式intset，ht
  4. zset：编码方式压缩列表，ht，跳表
  5. hash：编码方式压缩列表，ht

数据类型

1.String

  • RAW：（type、encoding、lru、refcount、ptr指向SDS）
  • EMBSTR：（type、encoding、lru、refcount、ptr后面紧接着SDS）
  • INT：（typr、encoding、lru、refcount、ptr里面直接存放数值）

2.List

类似于一个双端链表，可以从首尾操作列表中的元素

  • 在3.2版本之前，redis采用ZipList和LinkedList来实现List，当元素数量小于512且越苏大小小于64字节时采用ZipList编码，超过则采用LinkedList编码
  • 在3.2版本之后，redis统一采用QuickList来实现List

3.Set

Set是redis中的单列集合，满足下列特点：

  • 不保证有序性
  • 保证元素唯一（可以判断元素是否存在）
  • 求交集、并集、差集

编码：

  • 为了查询效率和唯一性，set采用HT编码（Dict）。Dict中的key用来存储元素，value统一为null。
  • 当存储的所有数据都是整数，并且元素数量不超过set-max-intset-entries（默认512）时，Set会采用IntSet编码，以节省内存。

4.ZSet

ZSet也就是SortedSet，其中每一个元素都需要指定一个score值和member值

  • 可以根据score值排序
  • member必须唯一
  • 可以根据member查询分数

因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求，之前学的哪种编码结构可以满足？

  • SkipList：可以排序，并且可以同时存储score和ele值（member）
  • HT：可以键值存储，并且可以根据key找value

当元素数量不多时，HT和SkipList的优势不明想，而且更耗内存。因此zset还会采用ZipList结构来节省内存，不过需要同时满足2个条件：

  1. 元素数量小于zset_max_ziplist_entries，默认值128
  2. 每个元素都小于zset_max_ziplist_value字节，默认值64

ziplist本身没有排序功能，而且没有键值对概念，因此需要有zset通过编码实现：

  • ZipList是连续内存，因此score和element是紧挨在一起的2个entry，element在前，score在后
  • score越小越接近队首，越大越接近队尾，按照score升序排列

5.Hash

Hash结构和redis中的zset非常类似：

  • 都是键值存储
  • 都需求根据键获取值
  • 键必须唯一

区别如下：

  • zset的键是member，值是score，hash的键和值都是任意值
  • zset要根据score排序，hash则无需排序

因此Hash底层采用的编码与Zset基本一致，只需要把排序有关的skiplist去掉即可：

  • Hash结构默认采用ZipList编码，用以节省内存，ZipList中相邻的2个entry分别保存field和value
  • 当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发条件有2个：
    1. ziplist中的元素超过了hash-max-ziplist-entry（默认512）
    2. ziplist中的任意entry大小超过了hash-max-ziplist-value（默认64字节）

网络模型

用户空间和内核空间

  • 进程的寻址空间会划分为2部分：内核空间、用户空间
  • 内核空间可以执行特权命令（Ring0），调用一切系统资源
  • 用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问。

缓冲区
Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

  • 写数据时，要把用户缓冲区数据拷贝到内核缓冲区，然后写入设备
  • 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓存区。

阻塞IO
顾名思义，阻塞IO就是2个阶段都必须阻塞等待。

2个阶段：

  1. 等待数据。
  2. 从内核拷贝数据到用户空间。

非阻塞IO
非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。
第一阶段是非阻塞的（进程反复调用recvfrom，并等待返回成功，循环），第二阶段是阻塞状态。
虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

IO多路复用
文件描述符File Descriptor：
简称FD，是从第一个从0开始递增的无符号整数，用来关联Linux中的第一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字Socket。

IO多路复用：
是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。（IO多路复用也是阻塞的？）
监听FD的方式：

  • select
  • poll
  • epoll

差异：

  • select和poll只会通知用户进程有FD就绪，但不确定具体是哪个FD，需要用户进程逐个遍历FD来确认。
  • epoll则会在通知用户进程FD就绪的同时，把已经就绪的FD写入用户空间。

IO多路复用-select
存在的问题：

  • 需要将整个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间
  • select无法得知具体是哪个fd就绪，需要遍历整个fd_set
  • fd_set监听的fd数量不能超过1024

IO多路复用-poll
与select对比：

  • select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
  • 监听FD越多，每次遍历消耗时间也越久，性能反而会下降

poll模式的问题

  • poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

IO多路复用-epoll
epoll如何解决上面的问题：

  • 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高，性能不会锁监听的FD数量增多而下降。
  • 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epoll_wait无需传递任何参数，无需重复拷贝FD到内核空间
  • 内核会将就绪的FD直接拷贝到用户空间的指定位置，用户进程无需遍历所有FD就能知道就绪的FD是谁。

IO多路复用-时间通知机制
当FD有数据可读时，我们调用epoll_wait就可以得到通知，但事件通知的模式有2种：

  • LevelTriggered：简称LT。当FD有数据可读时，会重复通知多次，直至数据处理完成。是Epoll的默认模式
  • EdgeTriggered：简称ET。当FD有数据可读时，只会被通知一次，不管数据是否处理完成。

结论：

  • ET模式避免了LT模式可能出现的惊群现象
  • ET模式最好结合非阻塞IO读取数据，相比LT会复杂一些。

信号驱动IO
信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。
问题：

  • 当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理，可能导致信号队列溢出。
  • 而且内核空间与用户空间的频繁信号交互，性能也较低。

异步IO
异步IO的整个过程（等待&拷贝）都是非阻塞的，用户进程调用完异步API后就可以去做其它事情，内核等待数据就绪并拷贝到用户空间后才会递交信号，通知用户进程。

同步和异步
IO操作是同步还是异步，关键看数据在内核空间和用户空间的拷贝过程（数据读写的IO操作），也就是阶段二是同步还是异步。

阻塞非阻塞：看阶段一。

image

用的较多的是IO多路复用，在一些情况下也会使用异步IO

BIO同步阻塞，NIO同步非阻塞，AIO异步非阻塞

最流行的IO模型：IO多路复用

Redis网络模型
Redis到底是单线程还是多线程：

  • 如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程。
  • 如果是聊整个Redis，那么答案就是多线程

在Redis版本迭代过程中，在2个重要的时间节点上引入了多线程的支持：

  • redis v4.0:引入多线程异步处理一些耗时较长的任务，例如异步删除命令unlink
  • redis v6.0:在核心网络模型中引入多线程，进一步提高对于多核CPU的利用率

Q：为什么redis要选择单线程？

  • 抛开持久性不谈，redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
  • 多线程会导致过多的上下文切换，带来不必要的开销。
  • 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣。

通信协议

内存回收

过期策略-周期删除
周期删除
顾名思义，就是通过一个定时任务，周期性的抽样部分过期的key，然后执行删除。执行周期有2种：

  • redis会设置一个定时任务serverCron()，按照server.hz的频率来执行过期key清理，模式为SLOW
  • redis的每个事件循环前会调用beforeSleep()函数，执行过期key清理，模式为FAST

SLOW模式规则：

  1. 执行频率受server.hz影响，默认为10，即每秒执行10次，每个执行周期100ms
  2. 执行清理耗时不超过一次执行周期的25%
  3. 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期
  4. 如果没达到时间上限25ms，并且过期key比例大于10%，再进行一次抽样，否则结束

FAST模式规则（过期key比例小于10%不执行）：

  1. 执行频率受beforeSleep()调用频率影响，但两次FAST模式间隔不低于2ms
  2. 执行清理耗时不超过1ms
  3. 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期
  4. 如果没达到时间上限1ms，并且过期key比例大于10%，在进行一次抽样，否则结束

RedisKey的TTL记录方式：

  • 在RedisDB中通过一个Dict记录每个Key的TTL时间

过期Key的删除策略

  • 惰性清理：每次查找key时判断是否过期，如果过期则删除。
  • 定期清理：定期抽样部分key，判断是否过期，如果过期则删除。

定期清理的两种模式：

  • SLOW模式执行频率默认为10，每次不超过25ms
  • FAST模式执行频率不固定，但2次间隔不低于2ms，每次耗时不超过1ms

image

标签：字节,ZipList,redis,链表,FD,IO,原理,节点
From： https://www.cnblogs.com/espgod/p/17918351.html

相关文章

  • 布隆过滤器：原理介绍与实战
    布隆过滤器用一句话来说，布隆过滤器是为了解决查询一个元素是否存在于某个集合之中。例如：50亿个用户ID，查询某ID是否在这50亿集合之中。50亿*8字节大约为50GB，内存占用极大。所以一般采用位数组，以及位数组的延伸设计：布隆过滤器。在学习布隆过滤器之前，我们需要有些基础性概念：哈......
  • Redis_高级
    Redis_高级分布式缓存单点Redis的问题：数据丢失问题：实现Redis数据持久化并发能力问题：搭建主从集群，实现读写分离故障恢复问题：利用Redis哨兵，实现健康检测和自动恢复存储能力问题：搭建分片集群，利用插槽机制实现动态扩容数据丢失问题-数据持久化RDB基本流程fork主进程获......
  • Grpc的内部原理、优缺点
    gRPC是一个高性能、开源和通用的RPC框架，面向移动和HTTP/2设计。gRPC默认使用protocolbuffers，这是Google开源的一套成熟的结构数据序列化机制（也可使用其他数据格式如JSON）基于go的一种远程过程调用，RPC框架的目标就是让远程服务调用更加简单、透明，RPC框架负责屏蔽底......
  • redis配置允许远程连接
    1、修改redis.conf#允许访问的地址，127.0.0.1为本机，也就是只允许本机访问，修改为0.0.0.0，则可以在任意IP访问bind0.0.0.0#守护进程，修改为yes后即可后台运行daemonizeyes#密码，设置后访问Redis必须输入密码requirepass111222#关闭防护，允许远程连接protected-modeno#监听......
  • ThreadLocal和InheritableThreadLocal详解,基本原理及注意项 父子线程数据共享
    一、ThreadLocal介绍在多线程环境下访问同一个线程的时候会出现并发问题，特别是多个线程同时对一个变量进行写入操作时，为了保证线程的安全，通常会进行加锁来保证线程的安全，但是加锁又会造成效率的降低；ThreadLocal是jdk提供的除了加锁之外保证线程安全的方法，其实现原理是在Thread类......
  • delphi模拟redis单元
    1unitg_uSdRedis;23interface45uses6Windows,7Messages,8SysUtils,9Variants,10Classes,11Graphics,12Controls,13Forms,14Dialogs,15IniFiles,16StdCtrls,17DateUtils;1819const......
  • 《TVM编译器原理与实践》新书推荐
    《TVM编译器原理与实践》新书推荐作者：吴建明，吴一昊；出版社：机械工业出版社；出版时间：2023年12月 本书已经出版，目前在淘宝天猫，京东，当当上可以购买。谢谢！天猫：https://detail.tmall.com/item.htm?abbucket=8&id=757068341348&ns=1&spm=a21n57.1.0.0.2b9b523ckBk0aH京东：https://it......
  • Hive-mapjoin详解（mapjoin原理）
    笼统的说，Hive中的Join可分为CommonJoin（Reduce阶段完成join）和MapJoin（Map阶段完成join）。本文简单介绍一下两种join的原理和机制。一.CommonJoin如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成CommonJoin，即在Reduce阶段完成join。CommonJoin整个......
  • k8s组件、工作原理详解
    1.k8s组件  Master组件：kube-apiserver（APIServer）:角色：提供集群的唯一入口，处理所有API请求。原理：接收来自客户端（kubectl、UI界面）和其他组件的请求，验证和授权请求，然后将其转发到其他组件或更新etcd中的数据。etcd:角色：分布式键值存储，保存整个集群的状......
  • Manjaro安装Redis和Redis-cli的使用
    一.Redis安装要在Manjaro上安装Redis，可以按照以下步骤进行操作：打开终端。使用以下命令更新系统软件包列表：sudopacman-Syu通过运行以下命令安装Redis：sudopacman-Sredis安装完成后，使用以下命令启动Redis服务：sudosystemctlstartredis可以使用以下命令......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99