新浪、京东golang一面整理-EW帮帮网

在这里插入图片描述

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
在这里插入图片描述

分布式算法知道哪些

一致性算法
Paxos: 用于在不可靠的网络中达成一致。
Raft: 旨在提供更易理解的一致性算法，简化了 Paxos 的实现。
负载均衡算法
轮询（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）	无索引	不支持	日志归档、高压缩比

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

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

新浪、京东golang一面整理

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

微服务治理

实现服务的平滑升级

1. 核心策略

(1) 滚动更新（Rolling Update）

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

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

golang的gmp

分布式算法知道哪些

Raft

Paxos

Mysql了解什么

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

1. InnoDB 引擎

物理存储位置

数据结构中的位置

2. MyISAM 引擎

物理存储位置

数据结构中的位置

3. 其他引擎对比

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

用Go实现一个死锁

网站公告

今日签到

热门文章

最新发布