# 理解session、token、cookie、JWT

Tags: 鉴权, 项目内容

Published: 2024年6月22日

# Cookie

- cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
- cookie 由服务器生成，发送给浏览器，浏览器把 cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。由于 cookie 是存在客户端上的，所以浏览器加入了一些限制确保 cookie 不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的 cookie 数量是有限的。

# Session

## **概念**

Session（会话）是在客户端和服务器之间保持状态的机制，通常用来存储用户会话信息，如登录状态。

## **工作机制**

- 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
- 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
- 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
- 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

**优点：**

- 简单易用，适合单机应用。
- 服务器端存储会话信息，便于管理和控制。

**缺点：**

- 依赖服务器存储，无法跨服务器或跨数据中心共享会话状态（除非使用共享存储）。
- 对于大型分布式系统，扩展性较差。

# Token

## 工作机制

- 客户端使用用户名和密码请求登录。
- 服务端收到请求，验证用户名和密码。
- 验证成功后，服务端会签发一个token，再把这个token返回给客户端。
- 客户端收到token后可以把它存储起来，比如放到cookie中。
- 客户端每次向服务端请求资源时需要携带服务端签发的token，可以在cookie或者header中携带。
- 服务端收到请求，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求数据。

**优点：**

- 无状态，客户端持有 Token，不依赖服务器存储会话信息，适合分布式系统。
- 易于扩展，Token 可以在不同服务之间共享认证信息。

**缺点：**

- Token 一旦泄露，可能被滥用。
- Token 的管理和刷新需要额外的机制。

# JWT

## **概念**

JWT 是一种基于 JSON 的开放标准（RFC 7519），用于在各方之间传递声明信息。通常用于身份认证和信息交换。

## 工作机制

JWT由三部分组成:头部(Header)、载荷(Payload)和签名(Signature)。它们通过点号"."分隔。

1. 头部(Header):头部通常由两部分组成，声明使用的加密算法和类型。例如:{"alg":"HS256","typ":"JWT"}

> 这个头部使用Base64编码后会成为JWT的第一部分
> 
1. 载荷(Payload):载荷是]WT的第二部分，包含了需要传输的用户信息和其他声明。例如:{"sub":"1234567890""name": "John Doe","admin": true}。

> 载荷也会经过Base64编码，
> 
1. 签名(Sianature):签名是JWT的第三部分，用于验证JWT的真实性和完整性。签名使用头部和载荷，以及预先约定的密钥(只有服务器知道)进行加密。

> 加密后的签名会与头部和载荷一起组成JWT的第三部分。
> 

当客户端发送请求时，将JWT放在请求的头部(通常是"Authorization"字段)，服务器收到请求后，会对]WT进行解析和验证。通过对比签名和验证密钥，服务器可以确定JWT是否被篡改过，从而判断请求的合法性。这就是JWT的简单原理，它通过在客户端和服务器之间传递可信的JSON令牌来进行身份验证和授权。

## JWT与其他认证技术的比较比如cookie和session相比有什么优势?

JWT 天然具有完美的水平扩缩能力，JWT令牌是多方系统中一种优秀的凭证载体，它不需要任何一个服务节点保留任何一点状态信息，就能够保障认证服务与用户之间的承诺是双方当时真实意图的体现，是准确、完整、不可改、且不可抵赖的。同时，由于 JWT本身可以携带少量信息，这十分有利于 RESTfUI API 的设计，能够较容易地做成无状态服务，在做水平扩展时就不需要像前面 Cookie-Session 方案那样考虑如何部署的问题。

## JWT有哪些缺点

- **令牌难以主动失效:**JWT 令牌一旦签发，理论上就和认证服务器再没有什么瓜葛了，在到期之前就会始终有效，除非服务器部署额外的逻辑去处理失效问题，这对某些管理功能的实现是很不利的。譬如一种颇为常见的需求是:要求一个用户只能在一台设备上登录，在 B设备登录后，之前已经登录过的 A 设备就应该自动退出。如果采用 JWT，就必须设计一个"黑名单”的额外的逻辑，用来把要主动失效的令牌集中存储起来，而无论这个黑名单是实现在 Session、Redis 或者数据库中，都会让服务退化成有状态服务，降低了JT 本身的价值，但黑名单在使用 JT 时依然是很常见的做法，需要维护的黑名单一般是很小的状态量，许多场景中还是有存在价值的。
- **只能携带相当有限的数据:**HTTP 协议并没有强制约束 Header 的最大长度，但是，各种服务器、浏览器都会有自己的约束，譬如 Tomcat 就要求 Header 最大不超过 8KB，而在 Nginx 中则默认为 4KB，因此在令牌中存储过多的数据不仅耗费传输带竞，还有额外的出错风险。

理解session、token、cookie、JWT

# 值类型和引用类型的区别

Tags: Golang

# 简介

在 Go 语言中，类型可以分为引用类型和值类型。这两类类型在内存分配、效率和使用方式上有不同的特点和性能表现。



## 值类型

值类型通常直接存储其值，并在赋值或传递时创建其副本。

**常见的值类型**

- **基本类型：`int`, `float64`, `bool`, `string`**
- **结构体类型（`struct`）**
- **数组类型（`array`）**

**行为特点**

- **赋值：**赋值或传递时，会复制整个值，生成独立的副本。
- **存储位置：**通常存储在栈上，但是大型值类型（如大数组）可能会存储在堆上（由编译器决定*escape analysis*）。
- **变化彼此不影响：**副本的变化不会影响原值，反之亦然。

## 引用类型

引用类型存储的是指向值的指针，因此赋值或传递时复制的是指针，而不是值本身。

**常见的引用类型**

- **指针类型（`pointer`）**
- **切片类型（`slice`）**
- **映射类型（`map`）**
- **通道类型（`chan`）**
- **函数类型（`func`）**

**行为特点**

- **赋值：赋值或传递时，只复制指针，因此多个引用可以指向同一个底层数据。**
- **存储位置：通常存储在堆上。**
- **变化会相互影响：一个引用的变化会影响到所有指向同一对象的引用。**

# 性能方面的区别

## 内存和速度

- **值类型**由于直接存储值，不需要间接寻址，所以在读取和写入时性能更高，尤其对于小型数据结构。但由于赋值和传递时会复制整个值，如果值类型的大小很大，可能会导致较高的内存开销和性能开销。
- **引用类型**由于只存储指针，赋值和传递时开销较低，适用于大型复合数据结构。但是，访问引用类型需要间接寻址，可能会略微增加访问时间。

## 内存分配

- **值类型**在赋值时会在栈上创建副本，常用于较小的数据结构。当值类型很大时，可能会因为栈空间不足被分配到堆上。
- **引用类型**储存在堆上，使用垃圾回收机制管理内存，因而在内存分配和回收时有一定的开销。但由于只传递指针，减少了数据复制的开销。


![Untitled.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/ef3ff88248e280834c2f10149aec8c01.Untitled.webp)

## 使用场景

- **值类型**适用于数据较小且需要频繁复制的场景，例如基本类型和简单的结构体。
- **引用类型**适用于大型数据结构或需要共享状态的场景，例如切片、映射和通道。

## 选择的考量因素

在实际开发中，选择值类型还是引用类型应根据具体的性能需求和用例场景：

- **性能：**如果传递的单位数据非常大，应考虑使用引用类型以节省内存和提升性能。
- **数据共享：**如果需要多个实例共享同一个数据，应使用引用类型以确保数据一致性。
- **安全性：**如果不希望数据被意外修改，可以使用值类型，以确保每个副本都是独立的。

了解值类型和引用类型的特性及其在性能上的差异，有助于选择适合的方案，从而优化代码的内存和执行效率。

值类型和引用类型的区别

# golang 设计模式

Tags: Golang

Published: 2024年6月19日

概要: 本文介绍了Go语言中的设计模式，包括创建型模式、结构型模式和行为型模式，并提供了各种模式的示例代码和解析。




# **1 设计模式概述**

设计模式是啥呢？简单来说，就是将软件开发中需要重复性解决的编码场景，按最佳实践的方式抽象成一个模型，模型描述的解决方法就是设计模式。使用设计模式，可以使代码更易于理解，保证代码的重用性和可靠性。


![Untitled.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/b946125f9605ba1b606b29740d919852.Untitled.webp)

# **2 创建型模式**

创建型模式（Creational Patterns），它提供了一种**在创建对象的同时隐藏创建逻辑**的方式，而不是使用 new 运算符直接实例化对象。

这种类型的设计模式里，单例模式和工厂模式（具体包括简单工厂模式、抽象工厂模式和工厂方法模式三种）在Go项目开发中比较常用。

## **2.1 单例模式**

单例模式的目的是为了保证一个类仅有一个实例，并提供一个访问它的全局访问点.

> 单例模式的两种表现形式。
> 
- 饿汉式：类加载时，就进行实例化。
- 懒汉式，第一次引用类时才进行实例化。

### **2.1.1 饿汉式**

> 单例对象是在包加载时立即被创建，所以这个方式叫作饿汉式
> 

`singleton` 包在被导入时会自动初始化 `instance` 实例，使用时通过调用 `singleton.GetSingleton()` 函数即可获得 `singleton` 这个结构体的单例对象。

```
package singleton

type singleton struct{}

var instance = &singleton{}

func GetSingleton() *singleton {
    return instance
}

```

### **2.1.2 懒汉式**

> 懒汉式模式下实例只有在第一次被使用时才被创建。
> 

```
package singleton

type singleton struct{}

var instance *singleton

func GetSingleton() *singleton {
    if instance == nil {
        instance = &singleton{}
    }
    return instance
}

```

### **2.1.3 并发安全**

> 懒汉式单例模式并发安全问题，比如在创建实例时，如果多个线程同时进行，则会出现并发问题。
> 

为了解决并发往问题，可以使用以下三种方法：

- 使用锁
- 使用sync/atomic包，原子化加载并设置一个标志，表明是否已初始化实例
- 使用sync.Once
    
    ```
    package singleton
    
    import "sync"
    
    type singleton struct{}
    
    var instance *singleton
    
    var once sync.Once
    
    func GetSingleton() *singleton {
        once.Do(func() {
            instance = &singleton{}
        })
        return instance
    }
    
    ```
    

`Once` 是一个结构体，在执行 `Do` 方法的内部通过 `atomic` 操作和加锁机制来保证并发安全，且 `once.Do` 能够保证多个 `goroutine` 同时执行时 `&singleton{}` 只被创建一次。

## **2.2 工厂模式**

工厂模式是创建型模式之一。由于创建类的代码和使用类的代码分离，符合单一职责和开闭原则，代码扩展性高.

> 按实际业务场景划分，工厂模式有 3 种不同的实现方式，俗称工厂三兄弟。
> 
- 简单工厂模式
- 工厂方法模式
- 抽象工厂模式

### **2.2.1 简单工厂模式**

> 简单工厂模式（Simple Factory Pattern）又称为静态工厂方法（Static Factory Method）模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
> 

> 优点
> 
- 创建类的代码和使用类的代码分离，符合单一职责和开闭原则，代码扩展性高。
- 客户端无需知道所创建具体产品的类名，只需知道参数即可。
- 也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。

> 缺点
> 
- 简单工厂模式的工厂类单一，职责过重，一旦异常，整个系统将受影响。且违背开闭原则。
- 使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度。
- 系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂。

### **2.2.2 工厂方法模式**

> 工厂方法模式（Factory method pattern）是一种实现了工厂概念的面向对象设计模式。工厂方法模式定义一个用于创建对象的接口，但让实现这个接口的子类来决定实例化哪个类。工厂方法让类的实例化延迟到子类中进行。
> 

从工厂方法模式来看，工厂类不再单一，我们解耦了对产品的操作，每种操作都作为一种工厂类，做到了工厂隔离，后续如果需要新的产品，则只需要根据抽象的类来定义产品即可，再设计新的工厂生产产品，不会改动之前的任何代码，符合开闭原则思想。

> 优点
> 
- 不需要记住具体类名，甚至连具体参数都不用记忆。
- 系统的可扩展性也就变得非常好，无需修改接口和原类。
- 符合开闭原则。

> 缺点
> 
- 增加系统中类的个数，复杂度和理解度增加。
- 增加了系统的抽象性和理解难度。

### **2.2.3 抽象工厂模式**

> 抽象工厂模式（Abstract factory pattern）引出了产品族和产品等级结构概念，其目的是为了更加高效的生产同一个产品组产品。
> 

**产品等级结构：** 产品的等级结构就是产品的继承结构，如一个模型工厂，可以画出圆形，长方形和正方形的模型。这里抽象的模型工厂和具体的模型构成了产品等级结构。
**产品族：** 在抽象工厂模式中，产品族指的是同一个工厂生产的，位于不同产品等级结构的一组产品。如模具厂生产的红色圆形模具，圆形模型属于模型产品等级结构中，红色属于颜料产品等级结构中。


![Untitled 1.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/af4660a5793972816783aa49aa3dfb80.Untitled%201.webp)
> 优点
> 
- 拥有工厂方法模式的优点。
- 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。
- 增加新的产品族很方便，无须修改已有系统，符合开闭原则。

> 缺点
> 
- 增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了开闭原则。

# **3 结构型模式**

特点是**关注类和对象的组合**。

## **3.1 策略模式**

策略模式（Strategy Pattern）定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。

在什么时候，我们需要用到策略模式呢？

在项目开发中，我们经常要根据不同的场景，采取不同的措施，也就是不同的**策略**。比如，假设我们需要对a、b 这两个整数进行计算，根据条件的不同，需要执行不同的计算方式。我们可以把所有的操作都封装在同一个函数中，然后通过 `if ... else ...` 的形式来调用不同的计算方式，这种方式称之为**硬编码**。

在实际应用中，随着功能和体验的不断增长，我们需要经常添加/修改策略，这样就需要不断修改已有代码，不仅会让这个函数越来越难维护，还可能因为修改带来一些bug。所以为了解耦，需要使用策略模式，定义一些独立的类来封装不同的算法，每一个类封装一个具体的算法（即策略）。

```
package strategy

// 策略模式

// 定义一个策略类
type IStrategy interface {
  do(int, int) int
}

// 策略实现：加
type add struct{}

func (*add) do(a, b int) int {
  return a + b
}

// 策略实现：减
type reduce struct{}

func (*reduce) do(a, b int) int {
  return a - b
}

// 具体策略的执行者
type Operator struct {
  strategy IStrategy
}

// 设置策略
func (operator *Operator) setStrategy(strategy IStrategy) {
  operator.strategy = strategy
}

// 调用策略中的方法
func (operator *Operator) calculate(a, b int) int {
  return operator.strategy.do(a, b)
}
```

在上述代码中，我们定义了策略接口 IStrategy，还定义了 add 和 reduce 两种策略。最后定义了一个策略执行者，可以设置不同的策略，并执行，例如：

```
func TestStrategy(t *testing.T) {
  operator := Operator{}

  operator.setStrategy(&add{})
  result := operator.calculate(1, 2)
  fmt.Println("add:", result)

  operator.setStrategy(&reduce{})
  result = operator.calculate(2, 1)
  fmt.Println("reduce:", result)
}
```

## **3.2 模板模式**

模板模式 (Template Pattern)定义一个操作中算法的骨架，而将一些步骤延迟到子类中。这种方法让子类在不改变一个算法结构的情况下，就能重新定义该算法的某些特定步骤。

简单来说，模板模式就是将一个类中能够公共使用的方法放置在抽象类中实现，将不能公共使用的方法作为抽象方法，强制子类去实现，这样就做到了将一个类作为一个模板，让开发者去填充需要填充的地方。

```
package template

import "fmt"

type Cooker interface {
  fire()
  cooke()
  outfire()
}

// 类似于一个抽象类
type CookMenu struct {
}

func (CookMenu) fire() {
  fmt.Println("开火")
}

// 做菜，交给具体的子类实现
func (CookMenu) cooke() {
}

func (CookMenu) outfire() {
  fmt.Println("关火")
}

// 封装具体步骤
func doCook(cook Cooker) {
  cook.fire()
  cook.cooke()
  cook.outfire()
}

type XiHongShi struct {
  CookMenu
}

func (*XiHongShi) cooke() {
  fmt.Println("做西红柿")
}

type ChaoJiDan struct {
  CookMenu
}

func (ChaoJiDan) cooke() {
  fmt.Println("做炒鸡蛋")
}
```

```
func TestTemplate(t *testing.T) {
  // 做西红柿
  xihongshi := &XiHongShi{}
  doCook(xihongshi)

  fmt.Println("\n=====> 做另外一道菜")
  // 做炒鸡蛋
  chaojidan := &ChaoJiDan{}
  doCook(chaojidan)

}
```

# **4 行为型模式**

特点是关注**对象之间的通信**。

## **4.1 代理模式**

代理模式 (Proxy Pattern)，可以为另一个对象提供一个替身或者占位符，以控制对这个对象的访问。

```
package proxy

import "fmt"

type Seller interface {
  sell(name string)
}

// 火车站
type Station struct {
  stock int //库存
}

func (station *Station) sell(name string) {
  if station.stock > 0 {
    station.stock--
    fmt.Printf("代理点中：%s买了一张票,剩余：%d \n", name, station.stock)
  } else {
    fmt.Println("票已售空")
  }

}

// 火车代理点
type StationProxy struct {
  station *Station // 持有一个火车站对象
}

func (proxy *StationProxy) sell(name string) {
  if proxy.station.stock > 0 {
    proxy.station.stock--
    fmt.Printf("代理点中：%s买了一张票,剩余：%d \n", name, proxy.station.stock)
  } else {
    fmt.Println("票已售空")
  }
}
```

上述代码中，StationProxy代理了Station，代理类中持有被代理类对象，并且和被代理类对象实现了同一接口。

## **4.2 选项模式**

在Python语言中，创建一个对象时，可以给参数设置默认值，这样在不传入任何参数时，可以返回携带默认值的对象，并在需要时修改对象的属性。这种特性可以大大简化开发者创建一个对象的成本，尤其是在对象拥有众多属性时。

而在Go语言中，因为不支持给参数设置默认值，为了既能够创建带默认值的实例，又能够创建自定义参数的实例，不少开发者会通过以下两种方法来实现：

第一种方法，我们要分别开发两个用来创建实例的函数，一个可以创建带默认值的实例，一个可以定制化创建实例。

使用这种方式，创建同一个Connection实例，却要实现两个不同的函数，实现方式很不优雅。

另外一种方法相对优雅些。我们需要创建一个带默认值的选项，并用该选项创建实例：

```
package options

import (
  "time"
)

const (
  defaultTimeout = 10
  defaultCaching = false
)

type Connection struct {
  addr    string
  cache   bool
  timeout time.Duration
}

type ConnectionOptions struct {
  Caching bool
  Timeout time.Duration
}

func NewDefaultOptions() *ConnectionOptions {
  return &ConnectionOptions{
    Caching: defaultCaching,
    Timeout: defaultTimeout,
  }
}

// NewConnect creates a connection with options.
func NewConnect(addr string, opts *ConnectionOptions) (*Connection, error) {
  return &Connection{
    addr:    addr,
    cache:   opts.Caching,
    timeout: opts.Timeout,
  }, nil
}
```

使用这种方式，虽然只需要实现一个函数来创建实例，但是也有缺点：为了创建Connection实例，每次我们都要创建ConnectionOptions，操作起来比较麻烦。

那么有没有更优雅的解决方法呢？答案当然是有的，就是使用选项模式来创建实例。以下代码通过选项模式实现上述功能：

```
package options

import (
  "time"
)

type Connection struct {
  addr    string
  cache   bool
  timeout time.Duration
}

const (
  defaultTimeout = 10
  defaultCaching = false
)

type options struct {
  timeout time.Duration
  caching bool
}

// Option overrides behavior of Connect.
type Option interface {
  apply(*options)
}

type optionFunc func(*options)

func (f optionFunc) apply(o *options) {
  f(o)
}

func WithTimeout(t time.Duration) Option {
  return optionFunc(func(o *options) {
    o.timeout = t
  })
}

func WithCaching(cache bool) Option {
  return optionFunc(func(o *options) {
    o.caching = cache
  })
}

// Connect creates a connection.
func NewConnect(addr string, opts ...Option) (*Connection, error) {
  options := options{
    timeout: defaultTimeout,
    caching: defaultCaching,
  }

  for _, o := range opts {
    o.apply(&options)
  }

  return &Connection{
    addr:    addr,
    cache:   options.caching,
    timeout: options.timeout,
  }, nil
}
```

在上面的代码中，首先我们定义了`options`结构体，它携带了timeout、caching两个属性。接下来，我们通过`NewConnect`创建了一个连接，`NewConnect`函数中先创建了一个带有默认值的`options`结构体变量，并通过调用

for _, o := range opts {

o.apply(&options)

}

来修改所创建的`options`结构体变量。

需要修改的属性，是在`NewConnect`时，通过Option类型的选项参数传递进来的。可以通过`WithXXX`函数来创建Option类型的选项参数：WithTimeout、WithCaching。

Option类型的选项参数需要实现`apply(*options)`函数，结合WithTimeout、WithCaching函数的返回值和optionFunc的apply方法实现，可以知道`o.apply(&options)`其实就是把WithTimeout、WithCaching传入的参数赋值给options结构体变量，以此动态地设置options结构体变量的属性。

这里还有一个好处：我们可以在apply函数中自定义赋值逻辑，例如`o.timeout = 100 * t`。通过这种方式，我们会有更大的灵活性来设置结构体的属性。

选项模式有很多优点，例如：支持传递多个参数，并且在参数发生变化时保持兼容性；支持任意顺序传递参数；支持默认值；方便扩展；通过WithXXX的函数命名，可以使参数意义更加明确，等等。

不过，为了实现选项模式，我们增加了很多代码，所以在开发中，要根据实际场景选择是否使用选项模式。选项模式通常适用于以下场景：

- 结构体参数很多，创建结构体时，我们期望创建一个携带默认值的结构体变量，并选择性修改其中一些参数的值。
- 结构体参数经常变动，变动时我们又不想修改创建实例的函数。例如：结构体新增一个retry参数，但是又不想在NewConnect入参列表中添加`retry int`这样的参数声明。

如果结构体参数比较少，可以慎重考虑要不要采用选项模式。

# **5 总结**


![Untitled 2.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/b946125f9605ba1b606b29740d919852.Untitled.webp)

golang 设计模式

分布式事务Seata

字节面试总结

在这里，我记录学习后端技术、实习经验和个人思考，也会随性分享一些生活琐事和吐槽。如果你和我有相似的兴趣或经历，欢迎随时交流！