## 1.简介

* 确保预期的pod副本数量
* 无状态应用部署
* 有状态应用部署
* 确保所有的node运行同一个pod
* 一次性任务和定时任务



## 2. 什么是controller？
* 在集群上管理和运行容器的对象

## 3. Pod和Controller关系
* Pod是通过Controller实现应用的运维：比如 伸缩，滚动升级等等
* Pod和Controller之间通过label标签建立关系（selector）


![image.png](/static/img/63c2c2afdf568d3585cabc3e94a67872.image.png)

## 4. Deployment控制器应用场景
* 部署无状态应用
* 管理Pod和ReplicaSet
* 部署，滚动升级等功能

比如说：web服务、微服务中

## 5. yaml文件字段说明
```shell

kubectl create deployment web --image=nginx # 命令行方式只适合做测试

# 第一步导出yaml文件
kubectl create deployment web --image=nginx  --run-dry -o yaml >web.yaml  # 导出yaml的配置文件
```
通过label来进行操作

![image.png](/static/img/2ee7571bbfec2cc4881478cc9371dfdc.image.png)

```shell
# 查看yaml文件
vim web.yaml

# 第二步：使用yaml文件部署应用
kubectl apply -f web.yaml

kubectl get pods

# 第三步：对外发布（暴露端口号）
kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml >web1.yaml

# web1.yaml发布
kubectl apply -f web1.yaml

```
## 6. Deployment控制器部署应用
### 1.无状态
* 认为Pod都是一样的
* 没有顺序要求
* 不用考虑在哪个node上运行
* 随意进行伸缩和扩展

### 2. 有状态
* 上面因素都需要考虑到
* 让每个pod独立的，保持启动顺序和唯一性【通过唯一的网络标识符、持久化存储；有序（比如：mysql主从）】


### 3. 部署有状态应用
* 无头service
    
    ClusterIP：none
     
![image.png](/static/img/f11ae9a8a401eb9c7ae6eedfe83f5ec1.image.png)

1. SatefulSet部署有状态应用

![image.png](/static/img/554ef0b2ae40f42564c959523d10e3a6.image.png)

查看pod ，有三个pod，每个都是唯一的名称

![image.png](/static/img/577b304f1e1659c5ebaee5ec652441d3.image.png)

查看创建无头的service

![image.png](/static/img/95ab11b5a4d18e06fdcffc26067a21a7.image.png)

deployment和statefulset区别：有身份的（唯一标识的）

根据主机名+按照一定规则生产域名

* 每一个pod有唯一主机名
* 唯一域名：
    
    格式：主机名称.service名称.名称空间.svc.cluster.local
    例如：nginx-statefulset-0.nginx.default.svc.cluster.local
    
    
### 4. 部署守护进程DaemonSet



## 7. 升级回滚
1. 指定nginx的版本

![image.png](/static/img/2aace27c33899eb58bc10841dd40f6dc.image.png)
```shell
kubectl apply -f web.yaml
kubectl get pods
```

2. 镜像升级
```shell
kubectl set image deployment web nginx=nginx:1.15

```
升级的过程：
1.14会创建一个副本，其中原来的不会停止，1.15在下载中

然后，1.15替换1.14 副本，同时删除1.14

![image.png](/static/img/adcf40f40864972d7a5ff400bda9a600.image.png)
```shell
# 查看升级状态
kubect rollout status deployment web
```

![image.png](/static/img/9bae70228d84bc090f39b59163d5fb83.image.png)
3. 回滚版本
```
# 查看历史版本
kubectl rollout history deployment web
```

![image.png](/static/img/da9fcf71529ee433ded70bfda07b6e70.image.png)

**回滚到上一个版本**
```
kubectl rollout undo deployment web
```

**回滚到指定版本**
```
kubectl rollout undo deployment web --to-revision=2
```


## 8. 弹性伸缩

添加更多的服务,添加更多的副本

```
kubectl scale deployment web --replicas=10
```

06 kubernetes 核心技术-Controller

## 如何用分布式锁保护队列的操作和状态转换



使用分布式锁可以确保在多个进程或节点同时对队列进行操作时的互斥性，以保护队列的操作和状态转换。

以下是一个基于 Redis 的分布式锁实现示例：

1. 定义一个全局唯一的锁名称，例如 "queue_lock"。

2. 当要对队列进行操作时，获取分布式锁。

3. 使用 Redis 的 SETNX 命令尝试将锁键设置为当前进程或节点的标识符，并设置一个过期时间，确保即使锁的释放有问题，也不会永久占用锁。

4. 如果 SETNX 命令返回成功，则表示当前进程或节点成功获得了锁，可以继续对队列进行操作。

5. 如果 SETNX 命令返回失败，则表示锁已被其他进程或节点占用。当前进程或节点可以选择等待一段时间后重新尝试获取锁，或者放弃操作。

6. 当操作完成后，释放分布式锁。可以使用 Redis 的 DEL 命令删除锁键。

以下是一个简单的伪代码示例：

```python
def acquire_lock(lock_name, identifier, expire_time):
    # 尝试获取锁
    if redis.setnx(lock_name, identifier):
        # 设置锁的过期时间
        redis.expire(lock_name, expire_time)
        return True
    else:
        return False

def release_lock(lock_name, identifier):
    # 检查锁是否属于当前进程或节点
    if redis.get(lock_name) == identifier:
        # 删除锁
        redis.delete(lock_name)

# 示例使用
lock_name = "queue_lock"
identifier = generate_unique_identifier()
expire_time = 60  # 锁的过期时间，单位为秒

if acquire_lock(lock_name, identifier, expire_time):
    try:
        # 执行队列操作
        process_queue()
    finally:
        release_lock(lock_name, identifier)
else:
    # 未获取到锁，进行相应处理
```

需要注意的是，分布式锁并不能解决所有并发问题，比如死锁和竞态条件。因此，在实际使用时，还需要考虑其他方面，如超时处理、重试机制和异常处理，以确保系统的稳定性和可靠性。

以上示例提供了一个基本的分布式锁实现思路，具体实现方式可能因编程语言、框架和技术栈而有所不同。您可以根据自己的需求选择适合的分布式锁库或组件，如 Redlock、Zookeeper 等，来实现分布式锁的功能。

## redis队列的超时处理
## redis队列的重试机制
## redis队列的异常处理
## redis队列

redis分布式队列的设计

# 基础架构：一条SQL查询语句执行的过程
[思维导图](https://www.mubu.com/doc/vC-hwU8myv)



## ICP的讲解
### 1. 概念
MySQL中的ICP（Index Condition Pushdown）是一种查询优化技术，它可以通过将部分WHERE条件下推到索引层级来提高查询性能。具体来说，当查询语句包含索引列和WHERE条件时，MySQL会首先根据索引列进行搜索，找到匹配的行后再应用WHERE条件过滤。如果使用ICP，MySQL就可以将部分WHERE条件在索引层级进行处理，减少了需要被MySQL服务器处理的数据量，从而提升了查询效率。

ICP技术适用于B+树索引结构，在MySQL 5.6之后的版本中支持InnoDB存储引擎的二级索引中使用ICP优化。在查询过程中，如果发现部分WHERE条件可以在索引层级进行处理，则MySQL会生成一个新的查询计划，将这些条件下推到索引层级进行处理。如果ICP技术可以有效地减少被MySQL服务器处理的数据量，就可以明显提升查询性能。

需要注意的是，ICP技术并非在所有情况下都能起到优化作用。一般来说，如果索引列的基数较小，ICP可能不会有太大的优化效果，反而会增加额外的查询成本。因此，在实际应用中需要仔细评估ICP技术对查询性能的影响，选择最适合的查询优化方案。
### 2. 什么情况下适用ICP？
ICP（Index Condition Pushdown）技术适用于满足以下条件的查询：

1. 使用了B+树索引结构。

2. 查询语句包含索引列和WHERE条件。

3. WHERE条件可以在索引层级进行处理，即包含索引列以及与其他条件的逻辑运算为AND的简单查询。


### 3. 在python中的使用
在Python中，ICP（Index Condition Pushdown）是MySQL数据库的一种查询优化技术，可以通过调整MySQL的配置来启用或禁用ICP。具体的步骤如下：

确保你已经安装了Python的MySQL驱动程序，比如mysql-connector-python或pymysql。

连接到MySQL数据库，可以使用如下代码示例创建连接：
```python
python
import mysql.connector

# 建立数据库连接
cnx = mysql.connector.connect(
  host="localhost",
  user="your_username",
  password="your_password",
  database="your_database"
)

# 创建游标对象
cursor = cnx.cursor()
```
执行修改MySQL配置的语句，启用或禁用ICP。可以使用ALTER SESSION SET optimizer_switch语句设置index_condition_pushdown参数的值，将其设为on表示启用ICP，设为off表示禁用ICP。例如：
```python
# 启用ICP
cursor.execute("ALTER SESSION SET optimizer_switch='index_condition_pushdown=on'")

# 禁用ICP
cursor.execute("ALTER SESSION SET optimizer_switch='index_condition_pushdown=off'")
完成操作后，最后不要忘记关闭游标和数据库连接：
python
# 关闭游标和连接
cursor.close()
cnx.close()
```
请注意，ICP的启用和禁用是在会话级别的，只对当前会话中的查询起效，并不是全局性的设置。如果需要持续保持ICP的状态，需要确保在每次会话中都进行相应的配置。

另外，具体的MySQL版本和驱动程序可能会有所不同，以上代码仅作为示例供参考，实际使用时请根据具体情况进行相应调整。
### 4. 什么叫索引的基数
索引列的基数（Cardinality）是指该列中不同值的个数。在一个包含 n 个行的表中，如果一列有 m 个不同的取值，那么该列的基数为 m。索引列的基数会直接影响到查询优化器的决策以及使用ICP（Index Condition Pushdown）优化的效果。

当索引列的基数较小时，说明该列的取值较少，很可能大部分数据都重复出现，这样就不能充分利用索引来过滤数据。在这种情况下，使用ICP技术可能并没有太大的优化效果，反而会增加额外的查询成本。

相反地，当索引列的基数较大时，说明该列的取值分布较均匀，可以充分利用索引来过滤数据。此时使用ICP技术可能会带来较好的优化效果，因为可以通过扫描更小的数据集来减少查询的磁盘IO次数，从而提高查询性能。

因此，在设计和优化索引时，需要考虑索引列的基数，并根据实际情况选择最合适的索引策略。

### 5. 是不是有的sql不需要分析器，可以绕过分析器直接执行？

是的，有些SQL语句确实可以绕过分析器直接执行。这通常发生在一些特殊情况下，比如使用存储过程或者动态SQL等。

存储过程是预先编译、存储在数据库中的一系列SQL语句和控制逻辑。当调用存储过程时，数据库引擎会直接执行其中的SQL语句，而不需要再进行解析和优化。

动态SQL是在运行时动态生成的SQL语句。因为它的内容在运行时才确定，所以无法在编译阶段进行解析和优化。在这种情况下，可以直接执行动态SQL语句，而不需要经过分析器。

需要注意的是，绕过分析器直接执行SQL语句可能会带来一些安全风险，比如SQL注入攻击。因此，在使用这种方式时，一定要谨慎处理用户输入，并采取相应的安全措施来防止潜在的攻击。

1.简介

如何用分布式锁保护队列的操作和状态转换

基础架构：一条SQL查询语句执行的过程

什么是 Redis？它的特点和优势是什么？