目錄

• 第一天：LRU 緩存淘汰策略 | Code - Github
• 第二天：單機(jī)并發(fā)緩存 | Code - Github
• 第三天：HTTP 服務(wù)端 | Code - Github
• 第四天：一致性哈希(Hash) | Code - Github
• 第五天：分布式節(jié)點(diǎn) | Code - Github
• 第六天：防止緩存擊穿 | Code - Github
• 第七天：使用 Protobuf 通信 | Code - Github

談?wù)劮植际骄彺?/h2>

第一次請(qǐng)求時(shí)將一些耗時(shí)操作的結(jié)果暫存，以后遇到相同的請(qǐng)求，直接返回暫存的數(shù)據(jù)。我想這是大部分童鞋對(duì)于緩存的理解。在計(jì)算機(jī)系統(tǒng)中，緩存無處不在，比如我們?cè)L問一個(gè)網(wǎng)頁，網(wǎng)頁和引用的 JS/CSS 等靜態(tài)文件，根據(jù)不同的策略，會(huì)緩存在瀏覽器本地或是 CDN 服務(wù)器，那在第二次訪問的時(shí)候，就會(huì)覺得網(wǎng)頁加載的速度快了不少；比如微博的點(diǎn)贊的數(shù)量，不可能每個(gè)人每次訪問，都從數(shù)據(jù)庫中查找所有點(diǎn)贊的記錄再統(tǒng)計(jì)，數(shù)據(jù)庫的操作是很耗時(shí)的，很難支持那么大的流量，所以一般點(diǎn)贊這類數(shù)據(jù)是緩存在 Redis 服務(wù)集群中的。

商業(yè)世界里，現(xiàn)金為王；架構(gòu)世界里，緩存為王。

緩存中最簡(jiǎn)單的莫過于存儲(chǔ)在內(nèi)存中的鍵值對(duì)緩存了。說到鍵值對(duì)，很容易想到的是字典(dict)類型，Go 語言中稱之為 map。那直接創(chuàng)建一個(gè) map，每次有新數(shù)據(jù)就往 map 中插入不就好了，這不就是鍵值對(duì)緩存么？這樣做有什么問題呢？

1）內(nèi)存不夠了怎么辦？

那就隨機(jī)刪掉幾條數(shù)據(jù)好了。隨機(jī)刪掉好呢？還是按照時(shí)間順序好呢？或者是有沒有其他更好的淘汰策略呢？不同數(shù)據(jù)的訪問頻率是不一樣的，優(yōu)先刪除訪問頻率低的數(shù)據(jù)是不是更好呢？數(shù)據(jù)的訪問頻率可能隨著時(shí)間變化，那優(yōu)先刪除最近最少訪問的數(shù)據(jù)可能是一個(gè)更好的選擇。我們需要實(shí)現(xiàn)一個(gè)合理的淘汰策略。

2）并發(fā)寫入沖突了怎么辦？

對(duì)緩存的訪問，一般不可能是串行的。map 是沒有并發(fā)保護(hù)的，應(yīng)對(duì)并發(fā)的場(chǎng)景，修改操作(包括新增，更新和刪除)需要加鎖。

3）單機(jī)性能不夠怎么辦？

單臺(tái)計(jì)算機(jī)的資源是有限的，計(jì)算、存儲(chǔ)等都是有限的。隨著業(yè)務(wù)量和訪問量的增加，單臺(tái)機(jī)器很容易遇到瓶頸。如果利用多臺(tái)計(jì)算機(jī)的資源，并行處理提高性能就要緩存應(yīng)用能夠支持分布式，這稱為水平擴(kuò)展(scale horizontally)。與水平擴(kuò)展相對(duì)應(yīng)的是垂直擴(kuò)展(scale vertically)，即通過增加單個(gè)節(jié)點(diǎn)的計(jì)算、存儲(chǔ)、帶寬等，來提高系統(tǒng)的性能，硬件的成本和性能并非呈線性關(guān)系，大部分情況下，分布式系統(tǒng)是一個(gè)更優(yōu)的選擇。

4）…

關(guān)于 GeeCache

設(shè)計(jì)一個(gè)分布式緩存系統(tǒng)，需要考慮資源控制、淘汰策略、并發(fā)、分布式節(jié)點(diǎn)通信等各個(gè)方面的問題。而且，針對(duì)不同的應(yīng)用場(chǎng)景，還需要在不同的特性之間權(quán)衡，例如，是否需要支持緩存更新？還是假定緩存在淘汰之前是不允許改變的。不同的權(quán)衡對(duì)應(yīng)著不同的實(shí)現(xiàn)。

groupcache 是 Go 語言版的 memcached，目的是在某些特定場(chǎng)合替代 memcached。groupcache 的作者也是 memcached 的作者。無論是了解單機(jī)緩存還是分布式緩存，深入學(xué)習(xí)這個(gè)庫的實(shí)現(xiàn)都是非常有意義的。

GeeCache 基本上模仿了 groupcache 的實(shí)現(xiàn)，為了將代碼量限制在 500 行左右（groupcache 約 3000 行），裁剪了部分功能。但總體實(shí)現(xiàn)上，還是與 groupcache 非常接近的。支持特性有：

• 單機(jī)緩存和基于 HTTP 的分布式緩存
• 最近最少訪問(Least Recently Used, LRU) 緩存策略
• 使用 Go 鎖機(jī)制防止緩存擊穿
• 使用一致性哈希選擇節(jié)點(diǎn)，實(shí)現(xiàn)負(fù)載均衡
• 使用 protobuf 優(yōu)化節(jié)點(diǎn)間二進(jìn)制通信
• …

GeeCache 分7天實(shí)現(xiàn)，每天完成的部分都是可以獨(dú)立運(yùn)行和測(cè)試的，就像搭積木一樣，每天實(shí)現(xiàn)的特性組合在一起就是最終的分布式緩存系統(tǒng)。每天的代碼在 100 行左右。

附 推薦閱讀

• Go 語言簡(jiǎn)明教程
• Go Test 單元測(cè)試簡(jiǎn)明教程
• Go Protobuf 簡(jiǎn)明教程

原文地址：7天用Go從零實(shí)現(xiàn)分布式緩存GeeCache | 極客兔兔

知乎專欄：Go語言 - 極客兔兔

關(guān)注微博：@極客兔兔

關(guān)聯(lián)答案：

怎么學(xué)習(xí) Golang？?www.zhihu.com有哪些值得學(xué)習(xí)的 Go 語言開源項(xiàng)目？?www.zhihu.com

總結(jié)

以上是生活随笔為你收集整理的go操作网页元素_7天用Go动手写/从零实现分布式缓存GeeCache的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。