主要内容：

1. Day6 防止缓存击穿



### 1 Day6 防止缓存击穿

还是拿昨天的图说明。

![aa203d2d34545afb6afb03262027c2a.jpg](https://www.misaka19327.cc/static/img/670e495a95cd3ea279dfc5e976ed3eca.aa203d2d34545afb6afb03262027c2a.jpg)

在这套流程里，如果一次性对同一个接口请求多次，那么这些请求也会一直到缓存里甚至是数据库里，有可能引发缓存击穿，毕竟这套流程里并没有对请求和调用进行限制。

对此，可以在GeeCache里通过实现一个singleflight的包来进行并发保护。

``` go
// src/geecache/singleflight/singleflight.go
package singleflight

import "sync"

// call 含义为正在进行中 或者是已经结束的请求
type call struct {
	wg sync.WaitGroup // 避免重入
	val interface{}
	err error
}

// Group 对call进行管理
type Group struct {
	mu sync.Mutex // 互斥锁 这个锁是保护下面的m的
	m map[string]*call
}

// DoFunc 要保护的方法调用入口 针对同样的key 传入的fn只会被调用一次 直到第一次fn的调用完成
func (g *Group) DoFunc (key string, fn func() (interface{}, error)) (interface{}, error) {
	g.mu.Lock() // 加锁
	
	if g.m == nil { // 如果没初始化的话先初始化
		g.m = make(map[string]*call)
	}
	
	if c, ok := g.m[key]; ok { // 已经存在之前的请求 则等待之前的请求完成 直接返回之前的请求结果
		g.mu.Unlock() // 读m完成 解锁
		c.wg.Wait() // 等待信号量归零
		return c.val, c.err
	}
	
	// 如果不存在相同的请求 则新增请求
	c := new(call)
	c.wg.Add(1) // 开始调用 信号量+1
	g.m[key] = c // 写入m
	g.mu.Unlock() // 读写m完成 解锁
	
	c.val, c.err = fn() // 实际调用
	c.wg.Done() // 调用已完成 信号量-1
	
	g.mu.Lock() // 加锁
	delete(g.m, key) // 请求结束 删除
	g.mu.Unlock() // 写入m完成 解锁
	
	return c.val, c.err
}
```

之后再融合进Group中：

``` go
// src/geecache/geecache.go
// 仅展示修改的三个部分

// Group 缓存对外交互的核心数据结构
type Group struct {
	name string // 该缓存的标识
	getter Getter // 缓存未能命中时的回调函数 类型是Getter接口
	mainCache cache // 缓存主体 是具有并发保护的LRU缓存
	peers PeerPicker // 这是实现了PeerPicker的HTTPPool
	// attention 为什么要将远程节点集成进HTTPPool 而不是节点本身？ 是否可以优化？
	
	loader *singleflight.Group // 非本地缓存的并发请求管理
}

// NewGroup 构造函数
func NewGroup(name string, cacheBytes int64, getter Getter) *Group {
	if getter == nil {
		panic("nil getter")
	}
	mu.Lock()
	defer mu.Unlock()
	group := &Group{
		name: name,
		getter: getter,
		mainCache: cache{cacheBytes: cacheBytes},
		loader: &singleflight.Group{},
	}
	groups[name] = group
	return group
}

// load 缓存未命中时 从别的地方加载缓存
func (g *Group) load(key string) (value ByteView, err error) {
	viewi, err := g.loader.DoFunc(key, func() (interface{}, error) {
		if g.peers != nil {
			if peer, ok := g.peers.PickPeer(key); ok { // 先从存储着远程节点信息的HTTPPool中选出具体的远程节点
				if value, err := g.getFromPeer(peer, key); err != nil { // 再根据这个具体的远程节点开始请求
					return value, nil
				}
				log.Println("[GeeCache] Failed to get from peer", err)
			}
		}
		return g.getFromLocal(key)
	})
	
	if err == nil {
		return viewi.(ByteView), err
	}
	return
}
```

GeeCache分布式缓存 | 第六天记录

主要内容：

1. 分布式节点 节点间通讯



### 1 Day5 分布式节点

想要实现分布式节点，先要明白GeeCache整体的服务过程，它的工作过程应该大致是这样的：

![224d301f6fa4b8b8784c4b9c0ce20f8.jpg](https://www.misaka19327.cc/static/img/ccc745d6a3a4bc5b293a0d4e8fe06c5b.224d301f6fa4b8b8784c4b9c0ce20f8.jpg)

要想要实现图中这个流程，就意味着一个缓存就得配一个HTTP服务端+客户端，这个客户端要有三个功能：第一、存储所有可用的节点；第二、对于给定的key，要能通过一致性哈希找到对应的远程节点，同时这个远程节点不能是自己；第三、请求这个远程节点。这三个功能完成之后，主缓存就可以直接调用函数来访问远程节点，而不用关心具体是哪个远程节点了。

#### 1 HTTP客户端

先抽象出两个接口：

``` go
// src/geecache/peer.go
package geecache

// PeerPicker 接口 根据key挑选远程节点
type PeerPicker interface {
	PickPeer(key string) (peerGetter PeerCacheValueGetter, ok bool)
}

// PeerCacheValueGetter 接口 根据key和给定的group获取缓存值
type PeerCacheValueGetter interface {
	GetCacheFromPeer(group string, key string) ([]byte, error)
}
```

> 第二个接口，原来的名字PeerGetter和方法Get实在太过于不明确了，我给改了个名字，之前的一些方法，接口也是，有一些实在容易分不清的也改名了。~~感觉作者是不是对Get这个词有点太喜欢了。~~

:::tip{title="提示"}
我曾想过这里的这两个接口是否有一些多余，不过Github上的讨论区里作者的回复比较合理：

> Q：第一步就抽象出接口，感觉不是很好理解。根据这篇文章https://blog.chewxy.com/2018/03/18/golang-interfaces/ ，是否可以考虑延迟定义接口。即首先定义类型/struct，在会使用到接口的时候再定义接口。
>
> A：一般抽象出接口是为了扩展性，很多场景下需要优先抽象接口。比如 RPC 通信需要支持不同的编解码方式，那首先想到的是一个支持编解码的结构体需要支持哪些方法，即接口。GeeRPC第一天 服务端与消息编码 在这篇文章中体现了这种思考方式。
> 
> 我觉得你说的也是有道理的，如果是比较确定的业务，优先 struct，需要扩展时再抽象接口更符合直觉一些。不过对于实现框架的童鞋来说，可扩展性是第一位的，所以一般都会优先设计接口。比如 go-micro 这个微服务框架，所有的参数都是接口类型的，这个框架是完全可插拔的，允许用户替换任意的类，只要 struct 实现了接口就行。
:::

之后就是实现HTTP客户端的功能，并在原有的HTTPPool上追加功能。

``` go
// src/geecache/http.go
// httpClient HTTP客户端 向远程节点发送请求 一个远程节点对应一个客户端
type httpClient struct {
	baseURL string
}

// GetCacheFromPeer 实现PeerCacheValueGetter接口 从远程节点获得缓存
func (h *httpClient) GetCacheFromPeer(group string, key string) (result []byte, err error) {
	url := fmt.Sprintf("%v%v/%v", h.baseURL, url.QueryEscape(group), url.QueryEscape(key))
	
	resp, err := http.Get(url)
	if err != nil {
		result = nil
		return
	}
	defer resp.Body.Close()
	
	if resp.StatusCode != http.StatusOK {
		result = nil
		err = fmt.Errorf("server returned error: %v", resp.Status)
	}
	
	bytes, err := io.ReadAll(resp.Body) // 读取响应体 原有的ioutil.ReadAll方法被弃用
	if err != nil {
		result = nil
		err = fmt.Errorf("reading response body error: %v", err)
	}
	
	result = bytes
	err = nil
	return
}

var _ PeerCacheValueGetter = (*httpClient)(nil) // 检查接口是否被完整实现
```

``` go
// src/geecache/http.go
package geecache

import (
	"GeeCache/src/geecache/consistenthash"
	"fmt"
	"io"
	"log"
	"net/http"
	"net/url"
	"strings"
	"sync"
)

const (
	defaultBasePath = "/_geecache/" // 默认资源地址
        // New
	defaultReplicas = 50 // 默认真实节点和虚拟节点倍数
)

// HTTPPool 一个缓存对应一个HTTP池 记录自身的地址和URL
type HTTPPool struct {
	selfAddr string // 记录缓存自身的地址 包括端口
	basePath string // 记录URL
        // New
	mu sync.Mutex // 锁
        // New
	peers *consistenthash.Map // 记录所有远程节点
        // New
	httpGetters map[string]*httpClient // 集成一个HTTP客户端
}

// NewHTTPPool HTTPPool的构造方法
func NewHTTPPool(selfAddr string) (result *HTTPPool) {
	result = &HTTPPool{
		selfAddr: selfAddr,
		basePath: defaultBasePath,
	}
	return
}

// Log 记录信息 参数v可传多个值 这些值会按format来进行格式化 再进入log
func (pool *HTTPPool) Log(format string, v ...interface{}) {
	log.Printf("[Server %s] %s", pool.selfAddr, fmt.Sprintf(format, v...))
}

// ServeHTTP HTTP服务端的Handler方法 对有效的缓存请求进行响应
func (pool *HTTPPool) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	if !strings.HasPrefix(r.URL.Path, pool.basePath) { // 检查请求是否有效
		panic("HTTPPool is serving unexpected path: " + r.URL.Path)
	}
	pool.Log("%s %s", r.Method, r.URL.Path) // log记录该次请求的信息
	
	parts := strings.SplitN(r.URL.Path[len(pool.basePath):], "/", 2)
	if len(parts) != 2 { // 检查请求是否有效
		http.Error(w, "bad request", http.StatusBadRequest) // 400
		return
	}
	
	groupName := parts[0]
	key := parts[1]
	
	group := GetGroup(groupName)
	if group == nil { // 请求的缓存不存在
		http.Error(w, "no such group:" + groupName, http.StatusNotFound) // 404
		return
	}
	view, err := group.GetFromCache(key)
	if err != nil { // 缓存请求失败
		http.Error(w, err.Error(), http.StatusInternalServerError) // 500
		return
	}
	
	w.Header().Set("Content-Type", "application/octet-stream")
	_, err = w.Write(view.GetByteCopy())
	if err != nil { // 写入响应失败
		http.Error(w, "write into responseWriter error: " + err.Error(), http.StatusInternalServerError) // 500
		return
	}
}

// New
// SetNewPeer 在本节点初始化远程节点信息
func (p *HTTPPool) Set(peers ...string) {
	p.mu.Lock() // attention 加锁必要性？
	defer p.mu.Unlock()
	
	p.peers = consistenthash.NewMap(nil, defaultReplicas)
	p.peers.AddRealNode(peers...)
	p.httpGetters = make(map[string]*httpClient, len(peers))
	for _, peer := range peers {
		p.httpGetters[peer] = &httpClient{baseURL: peer + p.basePath}
	}
}

// New
// PickPeer 根据一致性哈希挑选合适的远程节点
func (p *HTTPPool) PickPeer(key string) (PeerCacheValueGetter, bool) {
	p.mu.Lock()
	defer p.mu.Unlock()
	if peer := p.peers.GetRealNodeByKey(key); peer != "" && peer != p.selfAddr { // 注意这里 这里排除了自身节点
		p.Log("PickPeer picked %s", peer)
		return p.httpGetters[peer], true
	}
	return nil, false
}

var _ PeerPicker = (*HTTPPool)(nil) // 检查PeerPicker接口是否已完全实现
```

#### 2 集成进geecache中

``` go
// src/geecache/geecache.go
package geecache

import (
	"fmt"
	"log"
	"sync"
)

// Getter 接口 规定了一个Get方法 该方法用于规定缓存未命中时从哪里获得新的缓存
type Getter interface {
	Get(key string) ([]byte, error)
}

// GetterFunc 函数类型 专门用来实现Getter接口的函数类型
type GetterFunc func(key string) ([]byte, error)

// Get GetterFunc类下的 从Getter接口的Get函数实现而来的函数
func (function GetterFunc) Get(key string) ([]byte, error) {
	return function(key)
}

// Group 缓存对外交互的核心数据结构
type Group struct {
	name string // 该缓存的标识
	getter Getter // 缓存未能命中时的回调函数 类型是Getter接口
	mainCache cache // 缓存主体 是具有并发保护的LRU缓存
        // New
	peers PeerPicker // 这是实现了PeerPicker的HTTPPool
        // attention 为什么要将远程节点集成进HTTPPool 而不是节点本身？ 是否可以优化？
}

// 全局变量
var (
	mu sync.RWMutex // 互斥锁的高级版本 读写锁 在原有的锁功能上 增加读写特性 当读锁锁定时 只会阻止写 同理当写锁锁定时 会同时阻止读写
	groups = make(map[string]*Group) // 保存多个Group缓存
)

// NewGroup 构造函数
func NewGroup(name string, cacheBytes int64, getter Getter) *Group {
	if getter == nil {
		panic("nil getter")
	}
	mu.Lock()
	defer mu.Unlock()
	group := &Group{
		name: name,
		getter: getter,
		mainCache: cache{cacheBytes: cacheBytes},
	}
	groups[name] = group
	return group
}

// GetGroup 获取Group缓存
func GetGroup(name string) *Group {
	mu.RLock()
	g := groups[name]
	mu.RUnlock()
	return g
}

// GetFromCache 从缓存中获取值
func (g *Group) GetFromCache(key string) (ByteView, error) {
	if key == "" {
		return ByteView{}, fmt.Errorf("key is required")
	}
	if v, isOk := g.mainCache.get(key); isOk { // 缓存命中
		log.Println("[GeeCache] hit")
		return v, nil
	}
	// 缓存未命中 调用load函数
	return g.load(key)
}

// load 缓存未命中时 从别的地方加载缓存
func (g *Group) load(key string) (value ByteView, err error) {
        // New
	if g.peers != nil {
		if peer, ok := g.peers.PickPeer(key); ok { // 先从存储着远程节点信息的HTTPPool中选出具体的远程节点
			if value, err := g.getFromPeer(peer, key); err != nil { // 再根据这个具体的远程节点开始请求
				return value, nil
			}
			log.Println("[GeeCache] Failed to get from peer", err)
		}
	}
	return g.getFromLocal(key)
}

// getFromLocal 从本地加载缓存 在这里调用Getter的Get函数 并且通过populateCache存入缓存
func (g *Group) getFromLocal(key string) (ByteView, error) {
	bytes, err := g.getter.Get(key)
	if err != nil {
		return ByteView{}, err
	}

	value := ByteView{cacheBytes: cloneBytes(bytes)}
	g.populateCache(key, value)
	return value, nil
}

// populateCache 新的缓存值 存入缓存
func (g *Group) populateCache(key string, value ByteView) {
	g.mainCache.add(key, value)
}

// New
// RegisterPeers 将初始化完成的HTTPPool注入到group中 仅一次
func (g *Group) RegisterPeers(peers PeerPicker) {
	if g.peers == nil {
		panic("RegisterPeerPicker called more than once")
	}
	g.peers = peers
}

// New
// getFromPeer 从远程节点获得缓存
func (g *Group) getFromPeer(peer PeerCacheValueGetter, key string) (ByteView, error) {
	bytes, err := peer.GetCacheFromPeer(g.name, key)
	if err != nil {
		return ByteView{}, err
	}
	return ByteView{cacheBytes: bytes}, nil
}
```

到此，GeeCache主体部分就完成了，之后几天的内容就是对GeeCache进行改进。

### 2 项目整体示意&流程图

![aa203d2d34545afb6afb03262027c2a.jpg](https://www.misaka19327.cc/static/img/670e495a95cd3ea279dfc5e976ed3eca.aa203d2d34545afb6afb03262027c2a.jpg)

### 3 测试文件

``` go
package main

import (
	"GeeCache/src/geecache"
	"flag"
	"fmt"
	"log"
	"net/http"
)

var db = map[string]string{
	"Tom":  "630",
	"Jack": "589",
	"Sam":  "567",
}

func createGroup() *geecache.Group {
	return geecache.NewGroup("scores", 2<<10, geecache.GetterFunc(
		func(key string) ([]byte, error) {
			log.Println("[SlowDB] search key", key)
			if v, ok := db[key]; ok {
				log.Printf("[SlowDB] searched key: %s", v)
				return []byte(v), nil
			}
			return nil, fmt.Errorf("%s not exist", key)
		}))
}

func startCacheServer(addr string, addrs []string, gee *geecache.Group) {
	peers := geecache.NewHTTPPool(addr)
	peers.SetNewPeer(addrs...)
	gee.RegisterPeers(peers)
	log.Println("geecache is running at", addr)
	log.Fatal(http.ListenAndServe(addr[7:], peers))
}

func startAPIServer(apiAddr string, gee *geecache.Group) {
	http.Handle("/api", http.HandlerFunc(
		func(w http.ResponseWriter, r *http.Request) {
			key := r.URL.Query().Get("key")
			view, err := gee.GetFromCache(key)
			if err != nil {
				http.Error(w, err.Error(), http.StatusInternalServerError)
				return
			}
			w.Header().Set("Content-Type", "application/octet-stream")
			w.Write(view.GetByteCopy())
		}))
	log.Println("fontend server is running at", apiAddr)
	log.Fatal(http.ListenAndServe(apiAddr[7:], nil))
}

func main() {
	var port int
	var api bool
	flag.IntVar(&port, "port", 8001, "Geecache server port")
	flag.BoolVar(&api, "api", false, "Start a api server?")
	flag.Parse()
	apiAddr := "http://localhost:9999"
	addrMap := map[int]string{
		8001: "http://localhost:8001",
		8002: "http://localhost:8002",
		8003: "http://localhost:8003",
	}
	
	var addrs []string
	for _, v := range addrMap {
		addrs = append(addrs, v)
	}
	
	gee := createGroup()
	if api {
		go startAPIServer(apiAddr, gee)
	}
	startCacheServer(addrMap[port], []string(addrs), gee)
}
```

测试结果：

![image.png](https://www.misaka19327.cc/static/img/4d38a9acddb5ec8782360a2a24bb77d5.image.png)

> 注意不要让它跑在协程下，会出问题。

GeeCache分布式缓存 | 第五天记录

主要内容：

1. 一致性哈希原理
2. 一致性哈希实现



### 1 一致性哈希原理

对于分布式缓存来说，自己接收到请求后，如果在本地查找缓存找不到，下一步肯定是试图请求远程节点来获得缓存，那么假设现在整个分布式缓存算上本节点一共有10个节点，那么本节点在试图请求远程节点时应该请求谁？随机访问肯定不行，有可能节点1访问了节点2，然后发现节点2也没有缓存，再访问节点3，发现节点3也没有缓存……，可见随机访问的效率一定很低。

自定义哈希呢？比如说根据请求的key来计算哈希然后对10求模，求得的数字作为访问节点的依据。这样确实也可以，但是它仍然有一个问题：缓存雪崩。如果这10个节点中有一个节点失效，或者有一个新的节点加入分布式缓存，那么自定义哈希求模就是对9或者11求模了，绝大部分的缓存都会失效，自然会引发缓存雪崩。

一致性哈希就是解决普通哈希的引发缓存雪崩的隐患替代方案。它的大致原理是将请求的key值映射到一个环上，与其同时环上存储着分布式缓存系统的10个节点。确定了key的映射值之后就在环上往后找，找到的第一个节点就是要远程请求的节点。如果这10个节点中有节点失效了，那么请求也会顺延到下一个节点上，而不会引发缓存雪崩。

![110f0321e2537b85bd021da7a1bf59e.jpg](https://www.misaka19327.cc/static/img/28a354ec6f720b494f430348b06fc917.110f0321e2537b85bd021da7a1bf59e.jpg)

但是一致性哈希也有自己的问题：数据倾斜。还是那个环，还是那10个节点，但是如果这10个节点都只在环的半侧，另外半侧没有节点，这就会造成第一个节点极其繁忙，其余的节点浪费资源。缓解数据倾斜的方法是虚拟节点：为一个节点映射多个虚拟节点，这样减少了节点之间的距离的同时，资源消耗也少：只需要维护节点到虚拟节点的映射关系即可。

![4da1ab8531109accda801992ac83996.jpg](https://www.misaka19327.cc/static/img/995c87adedee2ed99d9a03cb6c2aed35.4da1ab8531109accda801992ac83996.jpg)

### 2 Day4 一致性哈希实现

先明确在Go里实现一致性哈希要维护什么：

1. 哈希函数，用来映射值到环上的
2. 一个数组，用来表示环
3. 一个字典，用来存储虚节点到节点的映射
4. 一个倍数，用来表示一个节点有几个虚节点

一致性哈希能做什么：

1. 添加新的节点
2. 根据传入的key来返回对应的真实节点

``` go
// src/geecache/consistenthash/consistenthash.go
package consistenthash

import (
	"hash/crc32"
	"sort"
	"strconv"
)

// HashFunc 哈希函数类型
type HashFunc func(data []byte) uint32

// Map 一致性哈希的主要数据结构 这里的一致性哈希维护的节点仅为节点名
type Map struct {
	hash HashFunc
	replicasNumber int // 真实节点和虚拟节点的映射倍数
	keys []int // 一致性哈希的环的抽象版
	hashmap map[int]string // 虚拟节点到真实节点的映射
}

// NewMap 一致性哈希的构造函数 默认情况下选择CRC32校验和作为哈希值
func NewMap(hashFunc HashFunc, replicasNumber int) (result *Map) {
	result = &Map{
		hash: hashFunc,
		replicasNumber: replicasNumber,
		hashmap: make(map[int]string),
	}
	if hashFunc == nil {
		result.hash = crc32.ChecksumIEEE
	}
	return
}

// AddRealNode 为一致性哈希添加真实节点（可以一次添加多个真实节点）
func (m *Map) AddRealNode(keys ...string) {
	for _, key := range keys {
		for i := 0; i < m.replicasNumber; i++ {
			hash := int(m.hash([]byte(strconv.Itoa(i) + key))) // 这个strconv.Itoa等效FormatInt 从整型转字符串
			m.keys = append(m.keys, hash)
			m.hashmap[hash] = key // 添加虚拟节点到真实节点的映射
		}
	}
	sort.Ints(m.keys) // 排序
}

// GetRealNodeByKey 根据key来获得真实节点
func (m *Map) GetRealNodeByKey(key string) (result string) {
	if len(m.keys) == 0 { // key检查是否有效
		return ""
	}
	
	keyHash := int(m.hash([]byte(key)))
	index := sort.Search(len(m.keys), func(i int) bool { // 二分查找 如果找不到符合条件的就返回len(m.keys)
		return m.keys[i] >= keyHash
	})
	
	return m.hashmap[m.keys[index % len(m.keys)]] // 去映射里查找真实节点
}
```

注意代码实现的时候并没有真的实现那个环，而是用一个数组代替。这个数组存储着所有真实节点和其虚拟节点的哈希值，并且调用AddRealNode后都会对该数组进行排序。当传入key后，以二分查找的方式寻找比传入的key的哈希更大的哈希，最后根据找到的下标去keys里找到哈希，再根据哈希去hashmap里找到真实节点。

> sort.Search函数，它接收两个参数。第一个是要查找的范围，第二个是一个判断函数，Search函数会根据该函数决定是否继续查找。如果从始至终没有找到一个位置使得判断函数为真，则返回查找范围作为索引。

### 3 测试文件

``` go
package main

import (
	"GeeCache/src/geecache/consistenthash"
	"strconv"
	"testing"
)

func TestHash(t *testing.T) {
	test_map := consistenthash.NewMap(func(data []byte) uint32 {
		i, _ := strconv.Atoi(string(data))
		return uint32(i)
	}, 3)
	
	test_map.AddRealNode("2", "4", "6")
	
	test_case := map[string]string {
		"2": "2",
		"11": "2",
		"23": "4",
		"27": "2",
	}
	
	for k,v := range test_case {
		if r := test_map.GetRealNodeByKey(k); r != v {
			t.Errorf("Asking for %s, should have yielded %s, actually is %s", k, v, r)
		}
	}
	
	test_map.AddRealNode("8")
	test_case["27"] = "8"
	for k,v := range test_case {
		if r := test_map.GetRealNodeByKey(k); r != v {
			t.Errorf("Asking for %s, should have yielded %s, actually is %s", k, v, r)
		}
	}
}
```

GeeCache分布式缓存 | 第四天记录

主要内容：

1. HTTP服务端实现



### 1 HTTP服务端示例

Go语言可以很轻松地实现一个HTTP服务端，示例如下，下例创建了一个在19326端口接收任何HTTP请求的HTTP服务端。

``` go
package main

import (
	"log"
	"net/http"
)

type server int // server类 所有要传到http包里作为Handler的类必须实现ServeHTTP方法

func main() {
	var s server
	http.ListenAndServe("127.0.0.1:19326", &s)
}

// ServeHTTP 自己实现的ServeHTTP方法 在这个类中记录了HTTP请求的路径 并且响应Hello World
func (h *server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	log.Println(r.URL.Path)
	_, err := w.Write([]byte("Hello World!"))
	if err != nil {
		return 
	}
}
```

效果如下：

![image.png](https://www.misaka19327.cc/static/img/4bd0b3dcbf2eb57967b5924c10029c05.image.png)

![image.png](https://www.misaka19327.cc/static/img/61db91d8760845376650bb4dfc84ef33.image.png)

### 2 Day3 HTTP服务端

得益于已经对缓存进行了有效的并发保护，在HTTP服务端这里直接调用函数即可。

``` go
// src/geecache/http.go
package geecache

import (
	"fmt"
	"io"
	"log"
	"net/http"
	"net/url"
	"strings"
)

const defaultBasePath = "/_geecache/" // 默认资源地址

// HTTPPool 一个缓存对应一个HTTP池 记录自身的地址和URL
type HTTPPool struct {
	selfAddr string // 记录缓存自身的地址 包括端口
	basePath string // 记录URL
}

// NewHTTPPool HTTPPool的构造方法
func NewHTTPPool(selfAddr string) (result *HTTPPool) {
	result = &HTTPPool{
		selfAddr: selfAddr,
		basePath: defaultBasePath,
	}
	return
}

// Log 记录信息 参数v可传多个值 这些值会按format来进行格式化 再进入log
func (pool *HTTPPool) Log(format string, v ...interface{}) {
	log.Printf("[Server %s] %s", pool.selfAddr, fmt.Sprintf(format, v...))
}

// ServeHTTP HTTP服务端的Handler方法 对有效的缓存请求进行响应
func (pool *HTTPPool) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	if !strings.HasPrefix(r.URL.Path, pool.basePath) { // 检查请求是否有效
		panic("HTTPPool is serving unexpected path: " + r.URL.Path)
	}
	pool.Log("%s %s", r.Method, r.URL.Path) // log记录该次请求的信息
	
	parts := strings.SplitN(r.URL.Path[len(pool.basePath):], "/", 2) // 切片 按'/'切两段
	if len(parts) != 2 { // 检查请求是否有效
		http.Error(w, "bad request", http.StatusBadRequest) // 400
		return
	}
	
	groupName := parts[0]
	key := parts[1]
	
	group := GetGroup(groupName)
	if group == nil { // 请求的缓存不存在
		http.Error(w, "no such group:" + groupName, http.StatusNotFound) // 404
		return
	}
	view, err := group.GetFromCache(key)
	if err != nil { // 缓存请求失败
		http.Error(w, err.Error(), http.StatusInternalServerError) // 500
		return
	}
	
	w.Header().Set("Content-Type", "application/octet-stream")
	_, err = w.Write(view.GetByteCopy())
	if err != nil { // 写入响应失败
		http.Error(w, "write into responseWriter error: " + err.Error(), http.StatusInternalServerError) // 500
		return
	}
}
```

### 3 今日内容结构图

![3b8b6fc18b75ba1bd79bc5909cce66b.jpg](https://www.misaka19327.cc/static/img/49163fd044aef33c63ea1741193f8406.3b8b6fc18b75ba1bd79bc5909cce66b.jpg)

### 4 测试文件

``` go
package main

import (
	"GeeCache/src/geecache"
	"fmt"
	"log"
	"net/http"
)

var db1 = map[string]string{
	"Tom":  "630",
	"Jack": "589",
	"Sam":  "567",
}

func main() {
	geecache.NewGroup("scores", 2<<10, geecache.GetterFunc(
		func(key string) ([]byte, error) {
			log.Println("[SlowDB] search key", key)
			if v, ok := db1[key]; ok {
				return []byte(v), nil
			}
			return nil, fmt.Errorf("%s not exist", key)
		}))
	
	addr := "localhost:9999"
	peers := geecache.NewHTTPPool(addr)
	log.Println("geecache is running at", addr)
	log.Fatal(http.ListenAndServe(addr, peers))
}
```

测试效果：

![image.png](https://www.misaka19327.cc/static/img/8797cb6beee3129f9d6d2d29871961ce.image.png)

Geecache分布式缓存 | 第三天记录

主要内容：

1. 单机并发缓存



### 1 Day2 单机并发缓存

#### 1.1 互斥锁控制

当多个协程同时读写一个变量时，如果没有并发控制，很容易运行出与预期不一致的结果，甚至触发Panic。`sync.Mutex`是一个互斥锁，可以由不同的协程来加锁和解锁，从而保护并发下程序的安全性和可预期性。

``` go
var m sync.Mutex
var set = make(map[int]bool, 0)

func printOnce(num int) {
	m.Lock()
	if _, exist := set[num]; !exist {
		fmt.Println(num)
	}
	set[num] = true
	m.Unlock()
}

func main() {
	for i := 0; i < 10; i++ {
		go printOnce(100)
	}
	time.Sleep(time.Second)
}
```

另外，这个`m.Unlock()`还有另外一个地方可以去：

``` go
func printOnce(num int) {
	m.Lock()
	defer m.Unlock()
	if _, exist := set[num]; !exist {
		fmt.Println(num)
	}
	set[num] = true
}
```

> defer关键字：defer和go一样，都是Go语言的那25个关键字之一。它的作用是**释放资源，会在函数返回之前调用**。如果有多个defer表达式，调用顺序类似于栈，越后面的defer表达式越先被调用。另外，defer也有个误区在：
>
> ``` go
> func f() (result int) {
>    defer func() {
>        result++
>    }()
>    return 0
>} // 实际返回1
> ```
> 
> 它特别容易认为是返回0，类似的还有：
> 
> ``` go
> func f() (r int) {
>      t := 5
>      defer func() {
>        t = t + 5
>      }()
>      return t
> } // 实际返回5
> ```
> 
> ``` go
> func f() (r int) {
>     defer func(r int) {
>           r = r + 5
>     }(r)
>     return 1
> } // 实际返回1
> ```
> 
> 这个时候，认准这一条：返回的过程是先给返回值赋值，然后执行defer函数，最后回到调用该函数的地方。所以这三段分别可以被改写成这样：
> 
> ![image.png](https://www.misaka19327.cc/static/img/9ece2bb4500371164f6e7b6639905e84.image.png)
> 
> ![image.png](https://www.misaka19327.cc/static/img/4ea84e805512605418030d1909373d5d.image.png)
>
> ![image.png](https://www.misaka19327.cc/static/img/7802933970d75cf82b19ad32b3d62cec.image.png)

##### 1.2 支持并发读写

首先定义只读类ByteView，用于缓存值的抽象和封装，实现lru.go的Value接口：

``` go
// src/geecache/byteview.go
package geecache

// ByteView 只读数据结构 实现了Value接口 用于表示缓存的值 如果想要获取当前缓存的值 一律从GetByteCopy获取
type ByteView struct {
	cacheBytes []byte
}

// GetMemoryUsed 实现Value接口的方法 返回该缓存值的长度/占用内存多少
func (view ByteView) GetMemoryUsed() int {
	return len(view.cacheBytes)
}

// GetByteCopy 返回当前缓存值的一个拷贝 外部程序如果想要获取当前缓存的值 一律从该方法获取 用于防止缓存值被外部程序修改
func (view ByteView) GetByteCopy() []byte {
	return cloneBytes(view.cacheBytes)
}

// ToString 返回当前缓存的字符串表示
func (view ByteView) ToString() string {
	return string(view.cacheBytes)
}

func cloneBytes(b []byte) []byte {
	clone := make([]byte, len(b))
	copy(clone, b)
	return clone
}
```

之后再对昨天的LRU进行封装，并且追加并发保护：

``` go
// src/geecache/cache.go
package geecache

import (
	"GeeCache/src/geecache/lru"
	"sync"
)

// cache 对LRU的一次封装 并且追加并发保护
type cache struct {
	mutex sync.Mutex // 互斥锁
	lru *lru.LRU // 封装的LRU
	cacheBytes int64
}

// add 对LRU.SetValue的封装
func (c *cache) add(key string, value ByteView) {
	c.mutex.Lock() // 互斥锁加锁
	defer c.mutex.Unlock()
	if c.lru == nil {
		c.lru = lru.NewLRU(c.cacheBytes, nil) // 懒加载
	}
	c.lru.SetValue(key, value)
}

// get 对LRU.GetValue的封装
func (c *cache) get(key string) (value ByteView, isOk bool) {
	c.mutex.Lock() // 互斥锁加锁
	defer c.mutex.Unlock()
	if c.lru == nil {
		return
	}

	if v, isOk := c.lru.GetValue(key); isOk {
		return v.(ByteView), isOk
	}
	return
}
```

##### 1.3 主体结构Group

Group是该项目的核心数据结构，它负责和请求交互的部分。

在一个完整的后端服务中，缓存负责响应请求，如果未能命中请求的数据，则尝试从数据库中获取数据。该项目也是如此，暴露给请求的接口只有获取值的Get方法，由缓存自动根据被指定的方式添加新缓存，淘汰旧有缓存。

要想实现缓存自动根据被指定的方式获取新的缓存，首先先规定如何获取新的缓存。为此Group必须要有一个缓存未能命中时的回调函数：

``` go
// src/geecache/geecache.go
// Getter 接口 规定了一个Get方法 该方法用于规定缓存未命中时从哪里获得新的缓存
type Getter interface {
	Get(key string) ([]byte, error)
}

// GetterFunc 函数类型 专门用来实现Getter接口的函数类型
type GetterFunc func(key string) ([]byte, error)

// Get GetterFunc类下的 从Getter接口的Get函数实现而来的函数
func (function GetterFunc) Get(key string) ([]byte, error) {
	return function(key)
}
```

:::tip{title="提示"}
这种，先有一个接口，再有一个函数类型，由这个函数类型实现这个接口的方法，叫做接口型函数。它的用处是，后续的函数如果将这个接口作为参数类型，则调用方可以传入实现这个接口的类，也可以直接传入方法。
:::

之后是Group类的实现，注意Group类对外只有一个获取缓存值的方法。

``` go
// src/geecache/geecache.go
// Group 缓存对外交互的核心数据结构
type Group struct {
	name string // 该缓存的标识
	getter Getter // 缓存未能命中时的回调函数 类型是Getter接口
	mainCache cache // 缓存主体 是具有并发保护的LRU缓存
}

// 全局变量
var (
	mu sync.RWMutex // 互斥锁的高级版本 读写锁 在原有的锁功能上 增加读写特性 当读锁锁定时 只会阻止写 同理当写锁锁定时 会同时阻止读写
	groups = make(map[string]*Group) // 保存多个Group缓存
)

// NewGroup 构造函数
func NewGroup(name string, cacheBytes int64, getter Getter) *Group {
	if getter == nil {
		panic("nil getter")
	}
	mu.Lock()
	defer mu.Unlock()
	group := &Group{
		name: name,
		getter: getter,
		mainCache: cache{cacheBytes: cacheBytes},
	}
	groups[name] = group
	return group
}

// GetGroup 获取Group缓存
func GetGroup(name string) *Group {
	mu.RLock()
	g := groups[name]
	mu.RUnlock()
	return g
}

// GetFromCache 从缓存中获取值
func (g *Group) GetFromCache(key string) (ByteView, error) {
	if key == "" {
		return ByteView{}, fmt.Errorf("key is required")
	}
	if v, isOk := g.mainCache.get(key); isOk { // 缓存命中
		log.Println("[GeeCache] hit")
		return v, nil
	}
	// 缓存未命中 调用load函数
	return g.load(key)
}

// load 缓存未命中时 从别的地方加载缓存
func (g *Group) load(key string) (value ByteView, err error) {
	return g.getFromLocal(key)
}

// getFromLocal 从本地加载缓存 在这里调用Getter的Get函数 并且通过populateCache存入缓存
func (g *Group) getFromLocal(key string) (ByteView, error) {
	bytes, err := g.getter.Get(key)
	if err != nil {
		return ByteView{}, err
	}

	value := ByteView{cacheBytes: cloneBytes(bytes)}
	g.populateCache(key, value)
	return value, nil
}

// populateCache 新的缓存值 存入缓存
func (g *Group) populateCache(key string, value ByteView) {
	g.mainCache.add(key, value)
}
```

:::tip{title="提示"}
读写互斥锁`sync.RWMutex`：互斥锁的高级版本。在原有的基础的加锁解锁功能外，增加了对读写的支持。如果读取锁是上锁状态，它不会阻止其他协程/线程的读取，但是会阻止写入行为，直到读取锁解锁；如果写入锁是上锁状态，它会阻止其他协程/线程的读取和写入行为。
:::

### 2 今日内容结构图

![41fa869e008ea7d8f5163917a4be585.jpg](https://www.misaka19327.cc/static/img/630c3931dec88feb8c636445ca400b09.41fa869e008ea7d8f5163917a4be585.jpg)

### 3 测试文件

``` go
// src/geecache/geecache_test.go
package geecache

import (
	"fmt"
	"log"
	"testing"
)

var db = map[string]string{
	"Tom":  "630",
	"Jack": "589",
	"Sam":  "567",
}

func TestGet(t *testing.T) {
	loadCounts := make(map[string]int, len(db))
	gee := NewGroup("scores", 2<<10, GetterFunc(
		func(key string) ([]byte, error) {
			log.Println("[SlowDB] search key", key)
			if v, ok := db[key]; ok {
				if _, ok := loadCounts[key]; !ok {
					loadCounts[key] = 0
				}
				loadCounts[key] += 1
				return []byte(v), nil
			}
			return nil, fmt.Errorf("%s not exist", key)
		}))

	for k, v := range db {
		if view, err := gee.GetFromCache(k); err != nil || view.ToString() != v {
			t.Fatal("failed to get value of Tom")
		} // load from callback function
		if _, err := gee.GetFromCache(k); err != nil || loadCounts[k] > 1 {
			t.Fatalf("cache %s miss", k)
		} // cache hit
	}

	if view, err := gee.GetFromCache("unknown"); err == nil {
		t.Fatalf("the value of unknow should be empty, but %s got", view)
	}
}
```