博客搭建成功，域名申请和反向代理已完成，记录一下域名申请以及DNS解析配置好后，如何反向代理到自己的服务



# 1、需求分析

域名为tao-blog.site，目前DNS解析已在腾讯云进行配置，服务器服务端口为801，为容器部署，需求是访问
wwww.tao-blog.site 或者 tao-blog.site 能访问到我服务器的801端口，也就是博客服务端口。

拆解为：

1. 需求一：反向代理
2. 需求二：证书实现https

# 2、调研实现

经了解Caddy具有自动获取和管理 SSL 证书的功能，支持 HTTPS 的自动配置和续期，相较于nginx少了很多繁杂的操作，故打算使用Caddy实现反向代理，本机试了试拉镜像装包一直报失败，故采用docker部署，需准备三个文件;

Caddyfile

```
www.tao-blog.site, tao-blog.site {
    # 反向代理到前端服务801端口
    reverse_proxy 82.157.16.223:801
}
```

很简单，将www.tao-blog.site, tao-blog.site反向代理到801，记住逗号后面有空格，否则会不生效

Dockerfile

```
FROM caddy:latest
RUN caddy add-package github.com/caddy-dns/cloudflare
```

docker-compose.yml

```
services:
  caddy:
    build: .
    container_name: caddy
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy_data:/data/caddy
```

执行命令

`docker compose up -d`

完成！

不得不说，docker就是好用

【Caddy】Caddy实现反向代理以及自动证书

最近项目要部署，顺便记录一下部署geoserver以及做图层发布相关内容



# 一、需求分析
我们系统需要在线加载小班数据，数据格式为geojson格式，数据量大概三十万条，之前做地图小数据量加载一般用数据库做存储即可，但是涉及到大数据量小班数据，首先在查询、接口传输以及地图渲染等方面如果采用之前的方案，均存在性能问题，故打算采用地图wms图层发布，而经过多种组件的使用，发现geoserver最适合我们的目前的需求。

# 二、前期准备

1. 安装pgsql并安装postgis组件（geoserver对地理数据适配较好并且geoserver可以把pgsql当作数据源）
2. jdk安装，geoserver需要java环境才能运行，服务器已经预装java8，所以需要选择2.22.x以及以下的geoserver版本

# 三、开始部署

## 1、下载

官网地址：https://geoserver.org/download/

下载二进制版本并解压

```sheel
unzip geoserver-2.22.5-bin.zip

```

## 2、设置目录权限

```sheel
sudo chown -R $USER:$USER /usr/geoserver
```

## 3、启动并配置

```sheel
 ./bin/startup.sh
```

## 4、进入系统界面

http://localhost:8080/geoserver

默认初始密码 admin:geoserver

# 四、图层发布

## 1、新建命名空间

注：在服务中勾中wms和wmts

![1.png](/static/img/a67bd1581671aaa51702b3e524364ba9.1.webp)


![2e.png](/static/img/d1f06539644a823726d519dfe2657187.2e.webp)

## 2、新建存储仓库

注：通过pgsql的方式建存储仓库


![3.png](/static/img/17116557fd236350627379fdb8e8dd3b.3.webp)


![4.png](/static/img/755f0cde644472fbc22ebd70babf7073.4.webp)


![5.png](/static/img/9c1112f7ff13fc1fdbb76120f7dbf961.5.webp)

建好后如下图，会把里面对应的表展示出来


![6.png](/static/img/e6eb83fcebe7c8c1aaebf80a8649e5eb.6.webp)

## 3、配置样式

图层可以指定样式，通过SLD格式文件配置



![7e.png](/static/img/e15437e02ab01d0095b4907befcbd776.7e.webp)

## 4、生成图层


![8e.png](/static/img/680184eb25bbac38f224d0eb79d5c3c6.8e.webp)

选择配置新的SQL视图，这里我们为减少数据量，只展示id和经纬度边界即可，如果需要发布全表的直接选中对应表发布即可

![9e.png](/static/img/ae6cb2dbae636d33d880c8afdbb11a70.9e.webp)

参数默认填入，确定字段类型是否对应

![10e.png](/static/img/c511dce732536225095235bcf8495d34.10e.webp)


![11e.png](/static/img/cac4895ff7f45e813c1447bb7bda9c6e.11e.webp)

相关边界选择从数据中生成计算即可


![12.png](/static/img/836ed6ca10ed98bfa0f5022f0120154a.12.webp)

样式选择我们配置好的样式即可


![13.png](/static/img/671bbf4ff33920312f4a92b6dcc19041.13.webp)

【GeoServer】geoserver地图服务部署以及发布图层

干就完了，没啥好说的


# 第一天：胸、三头

## 动作一、器械夹胸

热身：2组*15次

正式组：4组*12次



## 动作二、自由卧推

热身：2组*10次

正式组：5组*8次

## 动作三、器械上斜推胸

热身：2组*10次

正式组：5组*8次

## 动作四、龙门下压（三头）

热身：2组*10次

正式组：4组*12次

## 其余
有氧（爬坡、爬楼机可选）

平板支撑 4组

# 第二天：背、二头

## 动作一：引体向上

4组*10次

## 动作二：高位下拉

热身：2组*15次

正式组：4组*12次

## 动作三：器械划船

热身：2组*15次

正式组：4组*12次

## 动作四：杠铃弯举

热身：2组*15次

正式组：4组*12次

## 其余
有氧（爬坡、爬楼机可选）

平板支撑 4组

# 第三天：腿、肩

## 动作一：杠铃深蹲

6组*8次

## 动作二：.倒蹬器械

4组*12次

## 动作三：器械前束

5组*12次

## 动作四：器械夹大腿内侧

5组*12次

## 动作五：器械推举

正式组：4组*12次

## 动作六：侧平举

正式组：4组*15次

## 动作七：蝴蝶机反向飞鸟

正式组：5组*12次

## 其余
有氧（爬坡、爬楼机可选）

平板支撑 4组

# 关于训练时间

周一、周四、周六（如有意外情况延迟调整）

【健身计划】三分化健身计划

最近要做一个视频系统，目前需求是开发一个编解码服务器，先熟悉一下流媒体一些专有名词。


# 一、流媒体需要解决的两个问题

## 1、多媒体信息的数据量往往很大

标准的PCM编码的立体声音乐(采样速率44.1kHz，采样脉冲16位编码)信号的比特率超过了1.4Mbit/s。分辨率1280×720，每个像素采用24位RGB编码，帧率24fps，则其比特率将超过60Mbit/s。因此网络传输多媒体信息都无一例外地采用各种压缩技术，如MP3(128kbit/s)，MP4(40Mbit/s).

## 2、传输多媒体数据对时延和时延抖动要求较高

数字化后的多媒体数据，在发送端其分组往往是等时地发送的，但互联网本身并非等时的，而接收端只有按照原视频文件的规定速率读取帧才能正常播放，因而又是等时的。解决该问题的一个可行方法是在接收端设置适当大小的缓存。当缓存中的分组达到一定数量时再以恒定速率取出分组进行还原播放。缓存使得所有不定时到达的分组都经受了时延，导致了固定的播放时延，但在很大程度上消除了时延抖动。

互联网传输实时数据的分组有可能差错或丢失，如果利用TCP协议对这些丢失分组进行重传，那么延时就会大大增加。因此实时数据的传输在运输层就当采用用户数据报协议UDP而不是TCP协议。也就是说我们宁可丢失分组，也不要太晚到达的分组。另外，分组到达不一定按序，而分组播放又需要按序，因此分组中应当含有序号。分组还应当增加一个时间戳以使接收端知道分组是何时产生的。这些都需要新的协议支持才行。

# 二、流媒体通信协议
![image.png](/static/img/f8d16686aa690c8ad4d46d4664bc4745.image.webp)

## 1、RTSP(Real-Time Streaming Protocol) 实时流式协议

RTSP是一种应用层协议，用于控制流媒体服务器的多媒体会话，支持播放、暂停等VCR式操作。它不直接传输媒体数据，而是通过RTP/RTCP实现数据传输，默认使用TCP端口554。RTSP在视频监控、点播系统中广泛应用，但移动端浏览器支持较差。

尽管RTSP协议也支持推流/拉流，且支持TCP、UDP切换以及其他诸多优点。但是泛用性不足，特别是现在的浏览器都不支持RTSP的播放。

RTSP一般不用作直播场景，RTSP一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。

RTSP包含以下特色:
- 基于 “客户端 - 服务器” 模型，默认使用TCP 554端口，可扩展使用UDP，客户端与服务器协商媒体参数（如编码格式、传输协议），确定后通过 RTP 传输实际数据。
- 支持VCR式操作（播放、暂停、快进等）
- 适用场景：IP 摄像头、监控系统（用户远程控制摄像头的实时画面播放 / 暂停）、视频点播（VOD）的实时控制（如在线课程的暂停、快进）、安防监控平台（远程调取摄像头实时画面）
- 双向协议


## 2、RTMP（Real-Time Messaging Protocol，实时消息传输协议）

RTMP 是 Adobe 公司开发的用于音视频和数据实时传输的协议，最初用于 Flash 播放器，后成为流媒体领域的常用协议。它既传输控制消息，也直接传输媒体数据，基于 TCP（默认端口 1935）保证可靠性。

RTMP协议是既可以推流、也可以拉流的协议。RTMP地址是rtmp:// 开头的，且推流地址与播放地址是一样的。

RTMP具有以下特色:
- 直接封装音视频数据（如 H.264、AAC）和元数据（如视频分辨率、码率），通过 “消息”（Message）格式传输，支持低延迟（通常 1-3 秒）。数据分为 “消息”（Message）和 “块”（Chunk）：消息是逻辑单元（如一段视频、一条控制指令），块是传输单元（将消息拆分后按固定大小传输，减少开销）
- 支持连接建立、流发布（如主播推流）、流订阅（如观众拉流）等操作，通过 “命令消息”（Command Message）实现。
- RTMP通信是建立在TCP长连接通道上的，在封装音视频数据时会强制切片，限制每个数据包的大小。
- RTMP协议的延迟是比较低的，大概在1-3秒左右。
- 适用场景：直播平台（如早期的 YouTube Live、国内直播平台的推流环节）、互动直播（如游戏直播、电商直播）、实时互动应用（如在线教育的师生互动画面）

## 3、RTP（Real-time Transport Protocol，实时传输协议）

由IETF AVT小组开发，已成为正式标准，同时也是ITU-T的标准[RFC 3550, 3551]。RTP为实时应用提供端到端的运输，但不提供对服务质量的保证，需要RTCP来保证质量。RTP类似于一个协议框架，它只包含实时应用所需的共同功能，其本身并不对多媒体数据做任何处理，而只是在应用层数据前追加了一些附加信息，让应用层知道该如何处理。

另外，应用层数据被封装成的RTP分组只包含RTP数据，而控制是由另一个配套使用的协议RTCP提供的。RTP没有分发机制，它必须与UDP一起使用。RTP必须为偶数端口号，而下一奇数UDP端口留给同一会话中的RTCP使用。

默认情况，RTP端口为5004，RTCP端口为5005。


![image.png](/static/img/11165925f8e72025a082956d53a00e2d.image.webp)

## 4、HTTP-FLV

地址是http:// 开头的，是基于HTTP协议的HTTP-FLV可以简单地理解为RTMP的HTTP协议版本。功能和工作原理上是相似的，上面提到的RTMP切片数据功能HTTP-FLV也是有的。但是，HTTP-FLV协议一般只能用作拉流观看。HTTP-FLV协议的延迟也是比较低的，大概在1-3秒左右，但实际体验下来 HTTP-FLV延迟会略高于RTMP，但是HTTP-FLV相对RTMP适配更多的播放场景。

现在比较流行的方案是，直播源推流是RTMP协议，直播拉流观看是HTTP-FLV协议。

## 5、HLS

HLS协议一般只用作拉流观看，但是从严格意义上讲，HLS协议并不是流式协议。它工作原理很简单，就是通过HTTP协议下载静态文件。不同的是，HLS协议的文件由两部分组成，一是多个只有几秒长度的.ts碎片视频文件，另一个是记录这些视频文件地址的.m3u8索引文件，且这些静态文件都是直接写入磁盘的。更具体的说，HLS观看地址是以http:// 开头、.m3u8结尾的，实际上这个地址就是索引文件的地址，客户端获取到索引文件后，就可以下载对应的碎片视频文件并开始播放了。由于HLS协议实际上是通过HTTP协议请求文件的，且HLS相关文件是直接写入磁盘的，所以并不需要特殊的流媒体服务软件，使用Nginx等HTTP服务就可以了。

点播的场景下，也就是普通网络视频观看的场景下。.m3u8索引文件会记录所有的碎片视频文件地址，HLS在点播的场景下，优势是更加明显的。由于HLS的相关文件是无状态的静态文件，且每个文件的大小是有限的，所以负载均衡、CDN加速的效果更佳明显。HLS协议的点播视频，会比.mp4、.flv的视频更快地播放出来，且在加载中跳转视频也会更加顺滑。

直播的场景下，转码软件可以直接生成HLS相关文件到磁盘，客户端通过HTTP服务下载文件即可。视频流数据每几秒会打包成一个以.ts为后缀的碎片视频文件，每生成一个新的视频文件都会同步更新.m3u8索引文件。且碎片视频文件的个数是有上限的，当达到上限后，默认会将最旧的视频文件删除且更新.m3u8索引文件。所以在直播的场景下，客户端也需要不断定时重新获取.m3u8索引文件。HLS协议在直播的场景下是没什么优势的。虽然HLS协议的直播流也可以适配很多播放场景，但是由于需要生成静态文件，直播延迟很大，大概在**5-30**秒左右，使用直播CDN的话，由于边缘节点同步等问题，直播延迟甚至可能会达到1分钟左右。

当然HLS协议也有一定的优势，在直播时移，也就是直播转点播，或者录播，也就是点播转直播的场景， 理论上只需要修改索引文件就可以了。另外，HLS协议的.m3u8索引文件支持二级索引，就是高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址，大部分网页播放器的“自动”也是因为这个。

## 6、WebRTC

WebRTC协议其实并不是为了直播场景而设计的，WebRTC是一种点对点的视频/语音通话协议。由于WebRTC是基于UDP的，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还要低。在一些交互性较高的直播场景，如直播带货等场景，会使用WebRTC作为推流和观看协议 WebRTC的延迟理论上可以达到1秒内。


![image.png](/static/img/9078477c3b7da9360b8df0dfda541ae5.image.webp)

WebRTC协议支持推流和拉流，地址一般是以webrtc:// 开头的，且推流和拉流地址一般也是一样的。WebRTC虽然是点对点的协议，但是应用在直播场景的话，是需要搭建WebRTC服务器作为流媒体服务的。


## 7、对比

| 流媒体协议 |传输层| 延时 | 优势 | 劣势 | 数据  | 支持H.265 | 适合场景 |
|------------|------|------|------|------|---------|-----------|-----------|
| RTMP       | TCP|中低延时1 - 3s | 实时性好，支持多种编码格式 | 依赖Flash，安全性较差 | 流  | 否 | 直播、游戏流媒体 | 
| HLS(m3u8)  | TCP|中高延时10 - 30s | 跨平台支持好，兼容性强 | 延时相对较高，启动时间长 | 切片 | 是 | 点播、直播（尤其是苹果设备） |
| WebRTC     |UDP| 超低延时0.1 - 0.5s | 实时通信，支持P2P传输 | 浏览器支持不一，网络条件要求高 | 流  | 否 | 视频会议、实时互动 | 
| RTSP       |TCP/RTP/RTCP| 低中延时0.2 - 1s | 适合实时流媒体，支持多种传输协议 | 兼容性较差，防火墙穿透困难  | 流  | 是 | 监控摄像头、实时视频流 | 
| HTTP-FLV   |TCP| 中等延时1 - 3s | 简单易用，基于HTTP协议，兼容性强 | 延时较高，流媒体的实时性不足| 流  | 否 | 直播、点播（尤其是网页应用） | 
| RTP   | UDP|低中延时0.2 - 1s| 支持多路分发、可扩展RTCP | 不提供可靠性（不丢包）保证，不提供顺序性和完整性| 流 | 否 | 直播、单向推送 | 


# 三、其他流媒体概念

## 1、分辨率

图像，大家都知道，是由很多“带有颜色的点”组成的。这个点，就是“像素点”像素是图像显示的基本单位。我们通常说一幅图片的大小，例如是1920×1080，就是长度为1920个像素点，宽度为1080个像素点。乘积是2,073,600，也就是说，这个图片是两百万像素的。1920×1080，这个也被称为这幅图片的分辨率


## 2、帧率

帧率简单地说，帧数就是在1秒钟时间里传输的图片的数量，单位为fps。视频压缩中，每帧代表一幅静止的图像。而在实际压缩时，会采取各种算法减少数据的容量，其中IPB就是最常见的：

- I帧表示关键帧，可以理解为这一帧画面的完整保留;解码时只需要本帧数据就可以完成(因为包含完整画面)
- P帧——前向预测编码帧:表示的是这一帧跟之前的一个关键帧(或P帧)的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。(也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据)
- B帧——双向预测内插编码帧，是双向差别帧，也就是B帧记录的是本帧与前后帧的差别(具体比较复杂，有4种情况)，换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。 网络上的电影很多都采用了B帧，B帧压缩率高，但是解码时CPU会比较累。

在视频编码中，有一个概念叫做GOP，就是帧分组，两个关键帧之间有多少个编码帧（P帧和B帧），两个关键帧之间帧的多少直接影响到对图像的解码和编码。如果两个关键帧之间的帧比较多，那么从P帧和B帧的定义我们知道，解码程序就需要缓冲更多的中间解码帧，内存消耗就会比较多，而且GOP越长，那么B帧的帧数会越来越多，这直接影响到图像失真率，所以，不是GOP越长就会越好。那么，如果GOP越短，B帧就会越小，这种情况下图像的失真率就会越小，但是同时压缩率也会越小，对应的比特率就会越大，在网络上传输需要的带宽就会越多，所以，GOP不是越长越好，也不是越短越好，需要找一个合适位置，这个时候就是关键帧发挥作用的关键了。I帧与I帧之间的间隔便为GOP。那GOP的大小影响了什么呢，其实就是时延、带宽，清晰度等问题

## 3、视频压缩说明

**帧内压缩**:也称为空间压缩(Spatial compression)。当 压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间 的冗余信息，这实际上与静态图像压缩类似。帧内一般采 用有损压缩算法，由于帧内压缩是编码一个完整的图像， 所以可以独立的解码、显示。帧内压缩一般达不到很高的 压缩，跟编码jpeg差不多。帧内压缩是生成I帧的算法。

**帧间压缩**:相邻几帧的数据有很大的相关性，或者说前后 两帧信息变化很小的特点。也即连续的视频其相邻帧之间 具有冗余信 息,根据这一特性，压缩相邻帧之间的冗余量就 可以进一步提高压缩量，减小压缩比。帧间压缩也称为时 间压缩(Temporal compression)，它通过比较时间轴上 不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧 差值(Frame differencing)算法是一种典型的时间压缩 法，它通过比较本帧与相邻帧之间的差异，仅记录本帧与 其相邻帧的差值，这样可以大大减少数据量。 帧间压缩是生成B帧和P帧的算法。


## 4、编码解码及码率

码率就是数据传输时单位时间传送的数据位数,一般我们用的单位是kbps即千位每秒。通俗一点的理解就是取样率，单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件，但是文件体积与取样率是成正比的，所以几乎所有的编码格式重视的都是如何用最低的码率达到最少的失真，围绕这个核心衍生出来的cbr（固定码率）与vbr（可变码率），从音频方面来说，码率越高，被压缩的比例越小，音质损失越小，与音源的音质越接近。

比特率是指每秒传送的比特(bit)数。单位为 bps(Bit Per Second)，比特率越高，传送的数据越大。比特率表示经过编码（压缩）后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；如果比特率越少则情况刚好相反。

码率计算公式，例如1920*1080 分辨率的话 码率=1920*1080*帧率*每个像素的大小,就是对应帧率下1S的码率。

## 5、H264

H.264是MPEG-4标准的第十部分，目前国内使用比较多的视频压缩格式， 与其他编码格式相比，同等画面质量，文件体积最小。电脑及部分便携式视频设备都可播放。常见于高清视频中，压缩率高，图像清晰。H.264最大的优势是高性能，因此目前网络资源中的高清视频格式(即MKV、AVI、 MPG，TS)多采用H.264编码的视频流。

在H264中图像以序列为单位进行组织，一个序列是一段图像编码后的数据流，以I帧开 始，到下一个I帧结束。一个序列的第一个图像叫做 IDR 图像(立即刷新图像)，IDR 图像都是 I 帧图像。 H.264 引入 IDR 图像是为了解码的重同步，当解码器解码到 IDR 图像时，立即将参考 帧队列清空，将已解码的数据全部输出或抛弃，重新查找参数集，开始一个新的序 列。这样，如果前一个序列出现重大错误，在这里可以获得重新同步的机会。IDR图像 之后的图像永远不会使用IDR之前的图像的数据来解码。 一个序列就是一段内容差异不太大的图像编码后生成的一串数据流。

当运动变化比较少时，一个序列可以很长，因为运动变化少就代表图像画面的内容变动很小，所以就 可以编一个I帧，然后一直P帧、B帧了。当运动变化多时，可能一个序列就比较短了， 比如就包含一个I帧和3、4个P帧。

H264 的优点是成熟、稳定、高效、灵活，缺点是需要付费专利费用，并且难以满足超高清（4K/8K）视频的需求。


## 6、H625

H.265是新的编码协议，是H.264的升级版。H.265相比H.264最主要的改变是采用了块的四叉树划分结构，也极大了优化了算法，H.265比H.264占用的存储 空间理论上要少50%。H.265在各方面都碾压了H.264。 H265优点:降低存储空间。比起H.264/AVC，H.265/HEVC提供了更多不同的工具来降低码率，以编码单位来说，H.264中每个宏块(macroblock/MB)大小都是固定的16x16像素，而H.265的编码单位可以选择从最小的8x8到最大的64x64。那么，在相同的图像质量下，相比H.264，通过H.265编码的视频大 小将减少大约39-44%。

**优点：压缩率高**

**缺点：计算复杂，编解码需要更强的计算能力**

## 7、性能对比调研

|  |压缩率  |1080P/24FPS带宽需求|编码延迟/帧|解码延迟/帧|总延迟差/S |
| --- | --- | --- |--- |--- |--- |
| H264 | 150-250倍 | 4.67MBps-7.78MBps|0.5ms |23ms|180ms-432ms|
| H265 |  300-500倍| 2.34MBps-3.89MBps |1.2-1.5ms|30-40ms| |

注：

码率计算：码率（bps） = 分辨率（像素数）× 帧率（fps）× 每像素比特数 × 压缩比；

色深：色深表示每个像素所用的位数，常见的有8位、10位等。色深越高，视频质量越好，但数据量也越大。
RGB三原色中每一个颜色有256个数值，正好是2的8次方，我们知道在计算机里一个数字是1bit，
那么用8位的二进制数来表达，刚好能表达256个数值，那么刚好就是8bit可以表达一个原色，
也就是说RGB三原色每个颜色占用8bit，三个颜色就是24bit，这种方式表达的颜色也被称为24位色。














参考博客：

https://blog.csdn.net/zzhongcy/article/details/131779684

https://blog.csdn.net/qq_25218777/article/details/149755059

https://www.cnblogs.com/yangchin9/p/18153222

https://blog.csdn.net/wtt2020/article/details/131535350

【流媒体】流媒体常见协议与名词

回顾一下这么多年Redis的使用经历，看看源码和底层原理。



# 一、八种数据结构

Redis 共有 5 种基本数据类型：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合）。

这 5 种数据类型是直接提供给用户使用的，是数据的保存形式，其底层实现主要依赖这 8 种数据结构：

- 简单动态字符串（SDS）
- LinkedList（双向链表）
- Dict/HashTable（哈希表/字典）
- SkipList（跳跃表）
- Intset（整数集合）
- ZipList（压缩列表）
- QuickList（快速列表）
- listpack

五种基本数据类型对应的底层数据结构实现如下：

| String | List  |Hash|Set|ZSet|
| --- | --- |--- |--- |--- |
| SDS | LinkedList/Zip List/QuickList | Dict、ZipList | Dict、Intset | ZipList、SkipList |

## 1、SDS
数据结构如下：

```
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len;        // 已使用字节数
    uint8_t alloc;      // 分配的总字节数
    unsigned char flags;// 类型标记
    char buf[];         // 实际存储的字节数组
};
```

SDS（Simple Dynamic Strings）是Redis中用于表示字符串的数据结构之一，它具有以下特点：

1. 灵活性： SDS 可以存储字符串，也可以存储二进制数据，包括空字符，因此在处理二进制数据时更为灵活，不受空字符的限制。
2. 缓存长度信息： SDS 在头部保存了字符串的长度信息，因此可以在 O(1) 的时间复杂度内获取字符串的长度，而不需要遍历整个字符串，提高了获取长度的效率。
3. 动态扩容： SDS 可以根据实际存储的数据动态扩容，当字符串长度变长时，SDS 会自动进行内存的扩展，而不需要手动管理内存，提高了内存管理的便利性。

**特点总结：二进制安全、O(1)复杂度获取长度、自动扩容机制**

## 2、LinkedList

数据结构如下：

```
typedef struct listNode {
    struct listNode *prev;
    struct listNode *next;
    void *value;
} listNode;

typedef struct list {
    listNode *head;
    listNode *tail;
    unsigned long len;
    // ...其他函数指针
} list;
```
Redis中的 List 就是⽤双端链表实现的，双端链表（Doubly Linked List）是一种链表数据结构，每个节点除了包含指向下一个节点的指针外，还包含指向上一个节点的指针，双端链表的链表节点可以保存不同类型的值，⽀持在两端进⾏元素的快速插⼊和删除，并且链表结构提供了表头指针和表尾指针，获取链表的表头节点和表尾节点的时间复杂度只需O(1)；获取链表数量的时间复杂度也只需O(1)。

优点如下;
- 可以在头部和尾部高效地进行插入和删除操作，时间复杂度为 O(1)。
- 可以支持双向遍历，能够从头部和尾部同时进行遍历操作。

缺点如下：
- 链表每个节点之间的内存都是不连续的，意味着⽆法很好利⽤ CPU 缓存
- 保存⼀个链表节点的值都需要⼀个链表节点结构头的分配，内存开销较⼤。

双端链表常被用于需要频繁进行插入和删除操作，并且需要支持双向遍历的场景，比如实现队列、栈、LRU缓存等数据结构和算法

注：Redis3.2之前是用双向列表作为List的底层实现，之后是QuickList。

## 3、Dict/HashTable
数据结构如下：

```
typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    struct dictEntry *next;
} dictEntry;
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

```

哈希表（Hash Table）是一种用于存储键值对（key-value pairs）的数据结构，在 Redis 中被广泛应用于实现各种数据类型，如哈希表（Hashes）和集合（Sets）等。

在哈希表中，每个键都经过哈希函数处理后映射到一个唯一的索引位置，然后将对应的值存储在该位置上。这样，通过键可以快速定位到对应的值，实现了高效的查找操作。

HashTable本身数据结构定义为dictht，由dictEntry数组组成，dictEntry是一个单向链表的节点，代表hashtable种的一条记录，包含key、value以及指向下一个节点的指针（用于处理hash碰撞）

dictht size是hashtable种bucket的数量，sizemask是size的位掩码，用于计算对应的key应该存储在哪个bucket中（位运算的效率高于取模运算），而used存储的是是实际存储的记录的数量

Hash插入的过程：
1、先根据MurmurHash2算法计算除key的hash值
2、根绝sizemask和hash值进行与运算计算出index
3、遍历链表，如果有相同的key值则替换，没有的话则使用头插法（因为只存储了指向下一个节点的指针）

## 4、SkipList
数据结构如下：

```
typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;
```

跳跃表是⼀种在链表基础上改进过来的，实现了⼀种「多层」的有序链表，当数据量很⼤时，跳表的查找复杂度就
是O(logN)。在 Redis 中，有序集合（Sorted Set）就是通过跳表来实现的，因为跳表具有快速的查找和插入操作，非常适合用于实现有序集合类数据结构。

1、多层链表架构：

跳表由多层有序链表组成，最底层（Level 1）包含所有元素，上层每层均为下层的稀疏索引。例如，Level 2可能每隔两个节点抽取一个索引，Level 3每隔四个节点抽取一个索引，形成类似“金字塔”的结构。

2、节点随机层数：

每个节点的层数由随机算法决定（如Redis采用幂次定律），高层节点数量呈指数级减少。例如，50%节点在Level 1，25%在Level 2，以此类推。


![image.png](/static/img/f8f843bad6addc30c7937a9e530d5ea6.image.webp)



**跳表的查找过程如下：**

1. 查找⼀个跳表节点的过程时，跳表会从头节点的最⾼层开始，逐⼀遍历每⼀层。在遍历某⼀层的跳表节点时，会用跳表节点中的 SDS 类型的元素和元素的权重来进⾏判断：
2. 如果当前节点的权重⼩于要查找的权重时，跳表就会访问该层上的下⼀个节点。
3. 如果当前节点的权重等于要查找的权重时，并且当前节点的 SDS 类型数据⼩于要查找的数据时，跳表就会访问该层上的下⼀个节点。
4. 如果上⾯两个条件都不满⾜，或者下⼀个节点为空时，跳表就会使⽤⽬前遍历到的节点的 level 数组⾥的下⼀层指针，然后沿着下⼀层指针继续查找。

结合实例就是这样:

假设跳表包含元素[3,6,7,9,12,17,19,21,25,26,30,35]，其层级分布为：
- Level 2: 3 → 12 → 25（顶层）
- Level 1: 3 → 7 → 12 → 19 → 25 → 30
- Level 0: 3 → 6 → 7 → 9 → 12 → 17 → 19 → 21 → 25 → 26 → 30 → 35（底层完整链表）

查询目标19的过程:

1. 从顶层Level 2开始‌：比较第一个节点3，19>3，继续右移；下一个节点12，19>12，继续右移；遇到25时发现19<25，停止右移并下移到Level 1的12节点
2. 在Level 1继续查找‌：从12出发，右移遇到19（19=目标值），查找成功。若未找到则继续下移到Level 0

若目标为15（不存在）:
1. Level 2: 3 → 12（15>12），下移到Level 1的12节点；
2. Level 1: 12 → 19（15<19），下移到Level 0的12节点；
3. Level 0: 12 → 17（15<17），确认不存在

**跳表插入注意的点：**

1. 调用随机函数（如Redis的zslRandomLevel()）生成层数；
2. 从指定层数开始向下，如果找到节点小于当前值，则更新链表的前后指针的关系，插入，并继续遍历，直到0层

## 5、Intset（整数集合）

数据结构如下：

```
typedef struct intset {
    uint32_t encoding;
    uint32_t length;
    int8_t contents[];
} intset;
```
整数集合（Integers Set）是 Redis 中的一种特殊数据结构，用于高效地存储整数值的集合。它是为了在存储一组整数时，提供更加紧凑和高效的存储方式而设计的。

主要特点包括：
- 紧凑存储：整数集合使用紧凑的数据结构存储整数值，不像普通的数组那样每个元素都需要占用固定的内存空间，而是根据整数的大小动态调整所需的存储空间，节省了内存的使用。
- 快速查找：由于整数集合中的元素是有序的，并且使用了特定的算法进行存储和查找，因此可以在 O(logN) 的时间复杂度内实现查找操作，其中 N 表示整数集合中的元素个数。
- 支持多种整数类型：整数集合可以存储多种整数类型，包括 int16、int32、int64 等，根据存储的整数值的大小自动选择合适的数据类型。
- 动态调整：整数集合在存储整数值的过程中，会根据需要动态调整存储空间，避免了固定大小数组可能带来的空间浪费或溢出问题。

## 6、QuickList

数据结构如下:

```
typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;
    unsigned long len;
    int fill : 16;
    unsigned int compress : 16;
} quicklist;
typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;
    unsigned int sz;
    unsigned int count : 16;
    unsigned int encoding : 2;
    unsigned int container : 2;
    unsigned int recompress : 1;
} quicklistNode;

```

quicklist本质是双链表，里面所有的node分为两类，根据compress区分，如果coompress为0，则该节点存储的就是quicklistNode对象，否则，会类似ziplist一样，对quicklist进行LZF压缩（LZF是种无损压缩算法）。

那么问题来了，为什么不所有全压缩，而是部分压缩呢？

其实从统计而已，list两端的数据变更最为频繁，像lpush,rpush,lpop,rpop等命令都是在两端操作，如果频繁压缩或解压缩会代码不必要的性能损耗。从这里可以看出 redis其实并不是一味追求性能，它也在努力减少存储占用、在存储和性能之间做trade-off。

## 7、ZipList

压缩列表（ziplist）本质上就是一个字节数组，是Redis为了节约内存而设计的一种线性数据结构，可以包含任意多个元素，每个元素可以是一个字节数组或一个整数。


```
总体结构
<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>

节点结构
<prevlen> <encoding> <entry-data>

解压后节点结构
typedef struct zlentry {
    unsigned int prevrawlensize;  // 存储prevrawlen需要的字节数
    unsigned int prevrawlen;      // 前一个节点占用的字节数
    unsigned int lensize;        // 存储len需要的字节数
    unsigned int len;            // 数据长度
    unsigned int headersize;     // 首部长度 = prevrawlensize + lensize
    unsigned char encoding;      // 当前元素编码
    unsigned char *p;           // 当前元素首地址
} zlentry;

```

各个字段的含义如下：

1. zlbytes：压缩列表的字节长度，占4个字节，因此压缩列表最长(2^32)-1字节；
2. zltail：压缩列表尾元素相对于压缩列表起始地址的偏移量，占4个字节；
3. zllen：压缩列表的元素数目，占两个字节；那么当压缩列表的元素数目超过(2^16)-1怎么处理呢？此时通过zllen字段无法获得压缩列表的元素数目，必须遍历整个压缩列表才能获取到元素数目；
4. entryX：压缩列表存储的若干个元素，可以为字节数组或者整数；entry的编码结构后面详述；
5. zlend：压缩列表的结尾，占一个字节，恒为0xFF。


压缩列表节点分为三个部分：

1. previous_entry_length：这个属性记录了压缩列表前一个节点的长度，该属性根据前一个节点的大小不同可以是1个字节或者5个字节。由于压缩列表中的数据以一种不规则的方式进行紧邻，无法通过后退指针来找到上一个元素，而通过保存上一个节点的长度，用当前的地址减去这个长度，就可以很容易的获取到了上一个节点的位置，通过一个一个节点向前回溯，来达到从表尾往表头遍历的操作。
2. encoding：encoding通过以下规则来记录content的类型，一字节、两字节或者五字节长， 值的最高位为 00 、 01 或者 10 的是字节数组编码： 这种编码表示节点的 content 属性保存着字节数组， 数组的长度由编码除去最高两位之后的其他位记录；

![image.png](/static/img/b850677fcd5e9c81e839af1a203f7ba9.image.webp)
4. content：content属性负责保存节点的值，值的具体类型由上一个字段encoding来决定。


## 8、listpack

redis7.0,listpack已经完全取代ziplist

listpack作为ziplist的替代者，它的内存布局、实现原理和listpack非常相似。比如：都是连续的一块内存，前端都有表示内存大小、元素个数；尾部都有终结标志等元数据。但是他们彼此之间又有差异。


![image.png](/static/img/e3739eb0e71e6d049242a40bfc701262.image.webp)

与ziplist的相同点：

1. 头部都用4个字节的无符号整数记录了使用内存的大小；
2. 内存块尾部最后一个字节都用来表示列表的终结，而且内容都是0xFF；
3. 列表元素(entry)都是根据不同的数据内容编码后存储，条目都包含了三部分内容：编码、长度、数据。

与ziplist的区别：

1. 结构组成不同：ziplist内存结构分了四个功能块：ziplist总长度，元素个数，最后元素的偏移和结尾标志；而listpack只有三个功能块：listpack总长度,元素个数和结尾标志，少了最后元素的偏移；
2. 数据长度不同：两者的包含元素个数使用的字节长度不一样ziplist是4个字节的uint32_t类型数据，而listpack则是两个字节的unint16_t类型数据，单从这个数据的长度来看，listpack能存储的数据个数是比ziplist少的。因为uint16_t能容纳的数据比uint32_t要少。
3. 两者元素结构不同：ziplist元素的三个组成部分分别是：前置元素(entry)的长度数据，本条目的编码方案（包含数据长度）和具体的数据内容；而listpack元素的三个组成部分则是：本条目的编码方案(包含数据长度)、具体的数据内容和本条目前面两个条目数据长度编码后需要的字节数。就是说ziplist条目保存了上一个条目的长度信息，而listpack则保存了自己的长度信息。这两者有很明显的区别，而且这个区别，将影响两者操作的完全不同。.

listpack使用1个字节，对其存储的数据制定了11种编码方式。7种用于整数和整数数字组成的字符串编码，内部通过整数的方式压缩存储；3种用户普通字符串数据编码，内部直接使用原字符串的方式进行存储；1种用来表示listpack结束标识的编码。

数字编码主要是用于整数数值和数字组成的字符串。 对于数字组成的字符串，先尝试转换为对应的整数数值，然后根据其大小范围分别采取不同的编码方式和字节长度存储。


![image.png](/static/img/4b8536aec73f71ede67c4e990c44f37b.image.webp)


3种字符串编码，分别根据不同的字符串长度，采取不同的编码方式。使用字符串编码的数据，其内容无法通过整数数字压缩编码：包含非数字、不可打印的二进制字符等。以下图片列出了三种字符编码规则：


![image.png](/static/img/4bc49d8c4f5be6f9cabc17bbff4f373d.image.webp)


listpack作为ziplist替代方案。它实现主要目的是底层数据存储，故实现上更偏向空间换时间。对内存空间的使用可以说是“字(节)字较真”，与此同时规定一个listpack最大内存使用不能超过1GB，所以哪怕有部分函数，操作上来看，时间复杂度是0(N)，但结合Redis内部对该数据结构的使用方式，其实也在可接受范围内。就比如用作hash底层的实现方案之一，在特定元素数量超过一定数量后，该位hash存储结构。那么数量不多的时候采取listpack作为底层数据存储方案，即使是对其数据进行全量搜索，其耗时也不至于不可接受！

参考文献

https://juejin.cn/post/7220950867339247653