Redis

Redis 是一个开源（BSD许可）的，使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库（非关系性数据库），它可以用作数据库、缓存和消息中间件。

# Redis Cluster
Redis 组建成集群的两种模式：哨兵和集群，在不同需求场景下的不同的设计方案。
哨兵模式 - 方案一：
在传统的方案中，有一种方案是，可以基于 haproxy 做 master 检查的能力，这里介绍的就是使用此机制的方案。haproxy 的访问地址，一直保持代理的 Backend 节点的角色是 master 角色。
![](/media/202203/2022-03-24_105331_672221.png)

哨兵模式 - 方案二：
使用 K8s 的 service 的 update endpoint 的方式，来设置自己代理的一直是，master 的那个 Pod 的 IP 地址。
![](/media/202203/2022-03-24_105354_552589.png)
哨兵模式 - 方案三：
有一些 JDK 提供了基于访问哨兵的地址，通过 SDK 本身的能力来发现 master 节点。以下方案就是类似的机制的方案。
![](/media/202203/2022-03-24_105409_970100.png)

集群模式 - 方案一：
在集群模式中，客户端访问的方式，支持设置一组地址，由 SDK 来连接和使用集群。以下方案就是提供了类似的方案，同时这些地址是外部可达的，非容器集群的服务也可以访问这个 Redis 集群。
![](/media/202203/2022-03-24_105429_578971.png)
集群模式 - 方案二：
在有一些特殊的安全场景下，客户会要求访问的入口地址，有代理能力。不能因为集群规模的变化而去改变连接地址，而且连接的地址范围越小越好。以下方案就是完成类似能力的方案，客户的访问地址，永远只有一个地址。类似 envoy 支持的代理能力。新版本 6.0 之后也内置支持了 proxy 的能力。
![](/media/202203/2022-03-24_105449_855552.png)
07 架构设计

# Operator
## 架构设计
整体实现可以基于 Operator SDK 技术框架，Operator 的实质就是，用 CRD+Controller 来完成 K8s 特色的申明式的能力，不断的调整和修复，直到达到期望的状态，如果过程中发现偏离理想状态的，会一直调整和修复。这个过程的入口就是 Operator Controller 中的 Reconcile(req ctrl.Request) (ctrl.Result, error) 接口。

Reconcile 的核心思路：
![](/media/202203/2022-03-24_105633_839616.png)

中间件处理的核心逻辑：
![](/media/202203/2022-03-24_105638_518025.png)

## 模型样例
单点模型
![](/media/202203/2022-03-24_105643_906846.png)

哨兵模型
![](/media/202203/2022-03-24_105648_096243.png)

集群模型
![](/media/202203/2022-03-24_105652_310916.png)

备份模型
![](/media/202203/2022-03-24_105656_332936.png)