Mysql怎么去查询的，什么时候走索引，什么时候不走

微服务治理

我们要做到服务上下线对调用方无感知，熔断限流需要考虑，还要考虑监控和告警，链路追踪，安全，支持灰度发布、蓝绿部署、快速缩容扩容等。

---

1. 定义与背景
“微服务治理是一套保障微服务架构高效、稳定运行的机制和规范。随着单体应用拆分为多个独立服务，服务数量增多、交互复杂，治理成为解决服务间通信、监控、故障处理等问题的关键手段。”

---

2. 核心目标
用关键词概括核心目标，体现结构化思维：

• 可用性：服务注册发现、负载均衡、容错（熔断、降级）。
• 可观测性：日志聚合、链路追踪、监控告警。
• 安全与合规：API鉴权、流量加密、敏感数据保护。
• 高效协作：统一配置管理、API版本控制、开发规范标准化。
• 自动化：服务自愈、弹性扩缩容、CI/CD流水线。

---

3. 关键组件与工具
结合具体技术举例，展现实践经验：

• 服务发现：Consul（分布式）、Kubernetes Service（云原生）。
• 配置中心：Spring Cloud Config（Git集成）、Nacos（动态推送）。
• 流量治理：Istio（服务网格的流量镜像、金丝雀发布）、Sentinel（限流规则可视化）。
• 容错机制：Hystrix（线程隔离）、Resilience4J（重试策略）。
• 监控体系：Prometheus（指标采集）+ Grafana（可视化）+ ELK（日志分析）。

---

4. 治理模式演进
对比不同方案，体现技术选型思考：

• 传统集中式：Spring Cloud全家桶，适合中小规模，强绑定Java生态。
• 服务网格（Service Mesh）：Istio通过Sidecar代理解耦业务代码，支持多语言，适合复杂云环境。
• Serverless延伸：如Knative的事件驱动治理，适应无服务器架构。

---

5. 实际场景举例
用案例说明价值，增强说服力：
“比如在电商系统中，订单服务调用库存服务时，若库存服务宕机，熔断机制可快速失败，避免级联故障；同时，通过链路追踪定位到延迟高的服务节点，优化数据库查询逻辑，提升整体性能。”

---

6. 挑战与趋势
展现深度思考与行业洞察：

• 挑战：分布式事务（Saga模式）、多环境配置漂移、服务依赖图谱管理。
• 趋势：AIOps（智能告警降噪）、混沌工程主动测试、GitOps驱动治理策略版本化。

实现服务的平滑升级

在微服务架构中，实现服务的平滑升级（Zero Downtime Deployment）是保障系统高可用的关键需求。以下是完整的技术实现方案，结合策略、工具和最佳实践：

---

1. 核心策略

(1) 滚动更新（Rolling Update）

• 原理：逐步替换旧版本实例，新实例启动并健康后再销毁旧实例。
• 工具实现：

  # Kubernetes Deployment 配置示例
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-service
  spec:
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 25%        # 允许临时超出副本数的比例
        maxUnavailable: 25%  # 升级过程中最大不可用比例
    replicas: 4
    template:
      spec:
        containers:
        - name: my-service
          image: my-service:v2.0  # 新版本镜像
          readinessProbe:         # 就绪探针确保新实例可用
            httpGet:
              path: /health
              port: 8080
  

(2) 蓝绿部署（Blue-Green Deployment）

• 原理：同时运行新旧两套环境，通过流量切换实现瞬间切换。
• 实现步骤：
  1. 部署新版本环境（Green）并验证。
  2. 通过负载均衡器（如Nginx、Istio）将流量从旧环境（Blue）切换到Green。
  3. 确认无问题后下线Blue环境。
• 工具示例：

  # Istio VirtualService 流量切换
  apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    name: my-service
  spec:
    hosts:
    - my-service
    http:
    - route:
      - destination:
          host: my-service
          subset: green  # 指向新版本
  

(3) 金丝雀发布（Canary Release）

• 原理：先让少量用户请求到新版本，逐步扩大范围。
• 实现方式：
  • 流量比例控制：如将5%的流量导向新版本。
  • 按用户特征灰度：如特定Header、用户ID范围。
• 工具示例：

  # Istio 金丝雀发布配置
  apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    name: my-service
  spec:
    hosts:
    - my-service
    http:
    - route:
      - destination:
          host: my-service
          subset: v1  # 旧版本
        weight: 95    # 95%流量
      - destination:
          host: my-service
          subset: v2  # 新版本
        weight: 5     # 5%流量
  

---

golang的gmp

参考：https://www.cnblogs.com/MelonTe/p/18550611

分布式算法知道哪些

1. 一致性算法
   Paxos: 用于在不可靠的网络中达成一致。
   Raft: 旨在提供更易理解的一致性算法，简化了 Paxos 的实现。
2. 负载均衡算法
   轮询（Round Robin）: 将请求依次分配给每个节点。
   最少连接数（Least Connections）: 将请求分配给当前连接数最少的节点。

Raft

Paxos

Mysql了解什么

• 关系型
• A 原子性 事务 undo log
• C 一致性
• I 隔离性 MVCC next-key lock
• D 持久性 redo log
• 锁 ：全局锁、表级锁（表锁、元数据锁、意向锁）、行锁（记录锁、间隙锁）
• 高可用架构 主从复制 集群
  
  

Mysql数据放在什么地方？分引擎讨论，指数据结构的什么位置

在 MySQL 中，数据的物理存储位置和逻辑结构因存储引擎而异。以下是分引擎讨论的详细解析：

---

1. InnoDB 引擎

物理存储位置

• 表空间（Tablespace）：
  • 系统表空间（ibdata1）：存储数据字典（元数据）、Undo Log（回滚日志）等全局信息（默认路径：/var/lib/mysql/ibdata1）。
  • 独立表空间（.ibd 文件）：每个表的数据和索引存储在独立的 .ibd 文件中（默认路径：/var/lib/mysql/<database>/<table>.ibd）。
  • 通用表空间（General Tablespace）：用户可自定义的表空间，可包含多个表（需手动创建）。
• 日志文件：
  • Redo Log（重做日志）：ib_logfile0、ib_logfile1，记录事务修改（保证持久性）。
  • Undo Log（回滚日志）：默认在系统表空间，也可配置独立存储。

数据结构中的位置

• 数据行（Row）：
  • 存储于 .ibd 文件的**数据页（Page，默认 16KB）**中，页内按主键顺序组织（聚集索引）。
  • 每行数据包含隐藏字段：事务ID（DB_TRX_ID）、回滚指针（DB_ROLL_PTR）、行ID（DB_ROW_ID）。
• 索引（Index）：
  • 主键索引（聚集索引）：叶子节点直接存储行数据。
  • 二级索引：叶子节点存储主键值（非数据行本身），需回表查询。
• 内存结构：
  • 缓冲池（Buffer Pool）：缓存数据页和索引页，加速读写（内存中）。
  • Change Buffer：缓存非唯一二级索引的变更，减少磁盘随机IO。

---

2. MyISAM 引擎

物理存储位置

• 数据文件（.MYD）：存储表的所有行数据（默认路径：/var/lib/mysql/<database>/<table>.MYD）。
• 索引文件（.MYI）：存储表的索引结构（默认路径：/var/lib/mysql/<database>/<table>.MYI）。
• 表结构文件（.frm）：存储表定义（所有引擎通用，MySQL 8.0 后改为数据字典）。

数据结构中的位置

• 数据行：
  • 按插入顺序存储在 .MYD 文件中，无聚集索引，数据与索引分离。
  • 行记录为堆表（Heap Table），通过行号（ROWID）定位。
• 索引：
  • B-Tree 索引：存储在 .MYI 文件中，叶子节点指向 .MYD 文件中的行地址（物理偏移量）。
  • 全文索引：基于倒排表实现，独立于 B-Tree 索引。

3. 其他引擎对比

引擎	数据存储位置	索引结构	事务支持	适用场景
InnoDB	表空间（.ibd）	B+Tree（聚集索引）	支持	OLTP、高并发写入
MyISAM	数据文件（.MYD）+ 索引文件(.MYI)	B-Tree（非聚集索引）	不支持	读多写少、全文搜索
Memory	内存	哈希/B-Tree	不支持	临时表、缓存
Archive	压缩文件（.ARZ）	无索引	不支持	日志归档、高压缩比

系统设计：微信设计（消息和用户，消息具体设计）

1. 用户管理
   用户模型
   用户 ID: 唯一标识符。
   用户名: 显示名称。
   头像: 用户头像 URL。
   状态: 在线/离线状态。
   好友列表: 存储好友关系（可用图数据库或关系数据库）。
   用户注册与登录
   注册: 通过手机号码或邮箱进行注册，发送验证码以验证身份。
   登录: 支持密码和第三方登录（如微信、QQ）。
2. 消息管理
   消息模型
   消息 ID: 唯一标识符。
   发送者 ID: 发送消息的用户。
   接收者 ID: 接收消息的用户。
   消息内容: 文本、图片、视频等。
   时间戳: 消息发送时间。
   消息类型: 文本、图片、视频、语音等。
   状态: 已发送、已接收、已读等。
   消息存储
   即时消息: 使用 Redis 进行短期存储，实现快速访问。
   持久化存储: 将消息存储在关系型数据库中，便于查询和历史记录管理。
3. 消息发送与接收
   发送流程
   用户发送消息请求。
   服务器验证用户状态和接收者状态。
   消息存储到 Redis 作为缓存，持久化到数据库。
   通过 WebSocket 或推送服务将消息推送给接收者。
   接收流程
   接收者通过长连接（WebSocket）或轮询获取新消息。
   消息到达后更新 UI，标记为已读。
   

用Go实现一个死锁

• 互斥条件
• 占有并等待条件
• 不可剥夺条件
• 环路等待条件

package main

import (
	"fmt"
	"sync"
	"time"
)

func main() {
	var m1, m2 sync.Mutex
	go func() {
        fmt.Println("a等待1，，，")
		m1.Lock()
		time.Sleep(time.Second)
        fmt.Println("a等待2，，，")
		m2.Lock()
		time.Sleep(time.Second)
		m2.Unlock()
		m1.Unlock()
	}()
	go func() {
        fmt.Println("b等待2，，，")
		m2.Lock()
		time.Sleep(time.Second)
        fmt.Println("b等待1，，，")
        m1.Lock()
		time.Sleep(time.Second)
		m1.Unlock()
		m2.Unlock()
	}()
    select{}
}