分布式緩存介紹

原文出處：http://weibo.com/p/1001643872772421209951
作者：賴佳俊@LierD

微博作為目前最大的中文社交媒體平臺(tái)，擁有著上億的日活用戶。我們每天都會(huì)面臨各種非常具有挑戰(zhàn)性的業(yè)界技術(shù)難題。其中最具挑戰(zhàn)性的幾類問題是：

1. 海量數(shù)據(jù)存儲(chǔ)。微博總量已經(jīng)超過千億數(shù)據(jù)。海量數(shù)據(jù)的存取是一個(gè)非常大的技術(shù)挑戰(zhàn)

2. 巨大的并發(fā)請求。主feed接口的設(shè)計(jì)需要面對(duì)4倍于日常請求峰值的情況。

3. SLA要求高。核心系統(tǒng)需要保證至少4個(gè)9的穩(wěn)定性，核心接口平均響應(yīng)時(shí)間1s內(nèi)需要達(dá)到4個(gè)9

我們在解決上述的幾類挑戰(zhàn)中，結(jié)合自身的業(yè)務(wù)場景以及實(shí)際請求情況，設(shè)計(jì)出了高容量、可擴(kuò)展、具有穩(wěn)定性保障等特點(diǎn)的服務(wù)架構(gòu)。本文主要結(jié)合微博平臺(tái)的業(yè)務(wù)場景以及個(gè)人對(duì)分布式緩存的使用經(jīng)驗(yàn)和體會(huì)來做說明介紹。

文章主要從以下幾個(gè)方面來展開：

（1）緩存介紹，包括緩存的引入，緩存內(nèi)存分配策略，以及淘汰算法等基本要點(diǎn)說明

（2）分布式緩存架構(gòu)，主要結(jié)合平臺(tái)緩存使用中碰到的問題以及一些考慮點(diǎn)，說明緩存系統(tǒng)的變遷。

1.?緩存介紹

1.1?為什么引入緩存

在傳統(tǒng)的后端架構(gòu)中，由于請求量以及響應(yīng)時(shí)間要求不高，我們經(jīng)常采用單一的db的結(jié)構(gòu)。如下圖1?所示，應(yīng)用服務(wù)器直接存取DB。這種架構(gòu)簡單，但也存在著如圖中所描述的問題，即DB存在性能瓶頸，隨著請求量的增加，單DB無法繼續(xù)穩(wěn)定提供服務(wù)。

對(duì)于請求量不大的場景，我們可以通過對(duì)DB進(jìn)行讀寫分離、一主多從、硬件升級(jí)（SSD）等方式提升系統(tǒng)的承載能力以及冗余能力，但這幾種提升方式存在著以下幾個(gè)缺陷：

（1）性能提升有限。很難得到量級(jí)上的提升，而大部分互聯(lián)網(wǎng)產(chǎn)品直接面對(duì)著千萬級(jí)用戶訪問，單一使用db的結(jié)構(gòu)，難以達(dá)到性能要求

（2）成本高昂，為了達(dá)到N倍的承載能力的提升，需要至少N倍以上DB服務(wù)器

圖1?傳統(tǒng)服務(wù)架構(gòu)

?? ?那么我們是否有更好的方式來做呢？

?? ?相信大家在學(xué)習(xí)操作系統(tǒng)的時(shí)候，一定看過如圖2?類似的一組數(shù)據(jù)：

圖2?各類存儲(chǔ)介質(zhì)的訪問速度

從圖2中可以看到，一次內(nèi)存尋址的時(shí)間大概在100ns，順序從內(nèi)存中獲取1MB數(shù)據(jù)的時(shí)間大概在250000ns。對(duì)應(yīng)的，我們可以看到一次磁盤尋址以及順序讀取磁盤的速度大概在千萬ns級(jí)別。這里我們可以得出一個(gè)結(jié)論，也即內(nèi)存數(shù)據(jù)的獲取速度大概在磁盤的獲取速度的兩個(gè)數(shù)量級(jí)。也因此我們可以通過引入緩存中間件，來提高系統(tǒng)整體的承載能力，原有的單層db結(jié)構(gòu)也可以變?yōu)槿鐖D3所示的緩存+db結(jié)構(gòu)。

圖3 DB+緩存

通過在應(yīng)用服務(wù)與DB中間引入緩存層，我們可以得到如下三個(gè)好處：

（1）讀取速度得到提升

（2）系統(tǒng)擴(kuò)展能力得到大幅增強(qiáng)。我們可以通過加緩存，來讓系統(tǒng)的承載能力提升

（3）總成本下降，單臺(tái)緩存即可承擔(dān)原來的多臺(tái)DB的請求量，大大節(jié)省了機(jī)器成本

常見的緩存服務(wù)有本地緩存，memcached，redis等。他們各有自己的特點(diǎn)，本文以下內(nèi)容主要是結(jié)合微博對(duì)于memcached一些使用來做講解

1.2 Memcached

1.2.1 Memcached介紹

Memcached?是一個(gè)高性能的分布式內(nèi)存對(duì)象緩存系統(tǒng)，廣泛應(yīng)用于動(dòng)態(tài)Web應(yīng)用，以減輕數(shù)據(jù)庫負(fù)載。它通過在內(nèi)存中緩存數(shù)據(jù)和對(duì)象來減少讀取數(shù)據(jù)庫的次數(shù)，從而提高網(wǎng)站的訪問速度。

Memcached都有哪些特點(diǎn)呢？

1. 本身是一個(gè)kv存儲(chǔ)系統(tǒng)。存儲(chǔ)的時(shí)候，需要指定key以及對(duì)應(yīng)的value；獲取的時(shí)候，只能通過key獲取

2. 協(xié)議簡單，只支持簡單的命令如：set、get、cas、delete、stats、incr、decr等，而無類似于mysql的select、join等復(fù)雜的sql命令。所有的命令以及數(shù)據(jù)都是以文本的形式傳遞，這也就意味著mc的協(xié)議無需特殊的客戶端解析工具。我們可以通過在終端telnet進(jìn)行命令傳遞以及數(shù)據(jù)獲取。

3. 支持設(shè)定過期時(shí)間

4. 支持LRU等淘汰算法

1.2.2 Memcached的安裝以及使用

Memcached的安裝可以通過在官網(wǎng)上下載源碼的方式安裝：http://memcached.org/

相關(guān)安裝教程可以參考官網(wǎng)安裝步驟，親測有效~：http://code.google.com/p/memcached/wiki/NewInstallFromSource

安裝完成后，可以在linux終端執(zhí)行以下命令啟動(dòng)?./memcached -l 11211

新啟一個(gè)終端，敲入命令telnet localhost 11211，即進(jìn)入命令行模式

下面我們一起來試試Memcached hello world調(diào)用：

圖4 memcached helloworld

因本文篇幅有限，具體命令不再展開描述，大家如果感興趣可以通過官網(wǎng)的鏈接：http://code.google.com/p/memcached/wiki/NewCommands??了解。

1.2.3 Memcached內(nèi)存分配原理介紹

掌握Memcached的安裝、使用命令，其實(shí)對(duì)大部分的同學(xué)來說已經(jīng)足以開展相關(guān)開發(fā)工作了。但當(dāng)碰到一些線上問題的時(shí)候，單純的會(huì)用Memcached是無法快速、合理的分析問題所在的。所以接下來我們將介紹Memcached的內(nèi)存分配管理原理。

Memcached默認(rèn)情況下采用了名為Slab Allocator的機(jī)制分配、管理內(nèi)存。Slab Allocator的基本原理是按照預(yù)先規(guī)定的大小，將分配的內(nèi)存分割成特定長度的塊， 以完全解決內(nèi)存碎片問題。

在介紹memcached的內(nèi)存分配原理之前，需要跟大家說明以下幾個(gè)關(guān)鍵的名詞的概念：

item

一個(gè)待存儲(chǔ)的元素，按字節(jié)計(jì)算大小，可以理解為一個(gè)物品

Chunk

用于緩存item的內(nèi)存空間?？梢岳斫鉃橐粋€(gè)儲(chǔ)物格

Slab Class

特定大小的chunk的組?？梢岳斫鉃閮?chǔ)物格按大小進(jìn)行分類，如80B作為一類，96B作為一類....

Page

分配給Slab class的內(nèi)存空間，默認(rèn)是1MB。分配給Slab之后根據(jù)slab class的大小切分成chunk。可以理解為一個(gè)page是一個(gè)固定大小的柜子，上面可以按slab class進(jìn)行分割，一個(gè)柜子只能按一個(gè)slab class進(jìn)行分割。柜子上的格子數(shù)為柜子大小/?儲(chǔ)物格的大小

介紹完上述的幾個(gè)基本概念后，我們可以來看看mc在分配內(nèi)存的時(shí)候是怎么處理的。

圖5 memcached?初始化示意圖

如圖5為一個(gè)memcached示例在啟動(dòng)的時(shí)候，可以指定的一些參數(shù)，初始大小為slab class的起始大小，增長因子為下一個(gè)slab class是初始因子的倍數(shù)。如圖中所示，初始大小為80B，增長因子為1.5。則mc在啟動(dòng)后，會(huì)按下圖生成slab class表。

圖6 slab分布圖

完成初始后，當(dāng)某一個(gè)請求到來的時(shí)候——如圖中所示由一個(gè)123B大小的元素希望找到存儲(chǔ)空間，memcached會(huì)通過slab class表找到最合適的slab class：比元素大的最少的那個(gè)，在圖中場景下為180B，即使所需的空間只要123B。

?? ? ? ?此時(shí)Memcached示例并沒有分配任何的空間給180B的slab進(jìn)行管理。所以為了能讓請求的元素能存儲(chǔ)上，Memcached實(shí)例會(huì)分配1?個(gè)page給180這個(gè)slab（在默認(rèn)情況下為1MB實(shí)際內(nèi)存）。

圖 7 page分配圖

180B slab class在獲取到1MB的空間后，會(huì)按照自己的大小對(duì)page進(jìn)行分隔，也即1MB/180=5828個(gè)具體的存儲(chǔ)空間（chunk）。此時(shí)，123B的請求就可以被存儲(chǔ)起來了。

隨著時(shí)間的慢慢推移，memcached的內(nèi)存空間會(huì)逐步被分配完，如下圖8所示：

圖 8?內(nèi)存slab分配圖

我們可以看到，memcached劃分給每個(gè)slab的page數(shù)是不均等的，存在部分的slab是可能一個(gè)page都分配不到的。

假設(shè)所有的內(nèi)存都分配完，同時(shí)每個(gè)slab內(nèi)部的chunk也都分配完了。此時(shí)又來了一個(gè)新的元素123B，那么就會(huì)觸發(fā)memcached的淘汰機(jī)制了。

memcached首先會(huì)查看180B的slab是否存在過期的元素，如果存在，則先清理部分，預(yù)留空位。如果180B這個(gè)slab的數(shù)據(jù)都比較熱（沒有過期），則按LRU進(jìn)行淘汰。需要注意的是，淘汰是在slab內(nèi)部進(jìn)行的，也即在上面的場景中只有180Bslab內(nèi)部進(jìn)行淘汰剔除，對(duì)于其他的slab，是沒有受到影響的。memcached也不會(huì)回收比較空余的其他slab的page。也即一個(gè)page被分配給某個(gè)slab后，他將一直被這個(gè)slab所占用，永遠(yuǎn)無法被mc回收，直到memcached重啟。

這個(gè)特性被稱為Memcached的鈣化問題：Memcached在線上跑了一段時(shí)間后，內(nèi)存按原始訪問模式分配內(nèi)存。當(dāng)訪問模式變更后，原有的分配模式可能導(dǎo)致緩存頻繁出現(xiàn)數(shù)據(jù)剔除問題。最典型的場景即為內(nèi)存尚有空余，但一直有數(shù)據(jù)被剔除，命中率一直上不去。對(duì)于這種情況，解決方法為重啟緩存。

1.2.4?小結(jié)

上面兩節(jié)中我們主體介紹了Memcached的使用以及內(nèi)部的一些內(nèi)存分布原理。相信大家在自己動(dòng)手操作過后，會(huì)有一個(gè)較深的影響。在實(shí)際的使用中，除了關(guān)注緩存本身的一個(gè)使用外，我們還會(huì)有其他一些關(guān)注點(diǎn)。如高可用、擴(kuò)展性等，這些關(guān)注點(diǎn)的實(shí)現(xiàn)并不是單純依靠單一服務(wù)節(jié)點(diǎn)即可。為了能夠滿足上述的幾個(gè)關(guān)注點(diǎn)，我們需要引入分布式緩存結(jié)構(gòu)。

2. 分布式緩存

2.1?分布式？

考慮之前在緩存引入小節(jié)中所描述的，我們在原有的單層db結(jié)構(gòu)中引入了緩存memcached：

圖 9 DB+緩存

在這種單實(shí)例緩存架構(gòu)下，隨著業(yè)務(wù)規(guī)模的不斷增長，我們發(fā)現(xiàn)存在如下幾個(gè)問題：

（1）容量問題

單一服務(wù)節(jié)點(diǎn)無法突破單機(jī)內(nèi)存上限。目前微博數(shù)據(jù)已經(jīng)超過千億數(shù)據(jù)，雖然無需所有數(shù)據(jù)都放入緩存當(dāng)中，但在保證一定的命中率的情況下（注：微博核心緩存命中率需要達(dá)到99%）緩存部分?jǐn)?shù)據(jù)，也需要以百GB甚至是TB為單位的內(nèi)存容量。而單臺(tái)服務(wù)器的內(nèi)存總有上限（目前微博使用的常用服務(wù)器內(nèi)存上限128G），也即單實(shí)例緩存無法滿足緩存所有數(shù)據(jù)的需要

（2）服務(wù)高可用（HA）

在單實(shí)例場景下，緩存如果因?yàn)榫W(wǎng)絡(luò)波動(dòng)、機(jī)器故障等原因不可用，原來由緩存承擔(dān)的請求會(huì)全部落到DB上，最終系統(tǒng)會(huì)如同雪崩般，全部crash。

（3）擴(kuò)展問題

單一服務(wù)節(jié)點(diǎn)無法突破單實(shí)例請求峰值上限。微博業(yè)務(wù)是存在熱點(diǎn)突發(fā)事件的，也即隨時(shí)會(huì)有可能出現(xiàn)數(shù)倍于日常請求峰值的情況。雖然我們在做資源的評(píng)估的時(shí)候，會(huì)確保資源的冗余度足夠滿足請求翻倍（一般為2~4倍）的情況。但我們也需要后端資源是可以線性擴(kuò)展的

下面我們也會(huì)針對(duì)上面的幾個(gè)問題，一步一步說明相應(yīng)的解決方案。

2.2?分布式緩存實(shí)現(xiàn)

微博線上服務(wù)都是由多個(gè)服務(wù)端節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)。由于memcached本身不支持分布式，所以需要客戶端或者中間層代理實(shí)現(xiàn)分布式節(jié)點(diǎn)獲取。在今天的描述中，為了簡化問題，會(huì)主要以客戶端實(shí)現(xiàn)分布式為主，即應(yīng)用服務(wù)器（客戶端）根據(jù)內(nèi)部的算法，選擇特定的緩存節(jié)點(diǎn)，存取數(shù)據(jù)。

2.2.1 數(shù)據(jù)分片（Sharding）

前面提到單實(shí)例memcached主要會(huì)有以下幾個(gè)問題：

（1）請求量請求量超過單端口可承受極限

（2）數(shù)據(jù)容量超過單實(shí)例內(nèi)存容量。

為了解決以上兩個(gè)問題，我們的做法是從單端口實(shí)例擴(kuò)展為一組實(shí)例。一組memcached由多個(gè)memcached實(shí)例組成，每個(gè)實(shí)例上只緩存數(shù)據(jù)總量的一部分?jǐn)?shù)據(jù)，客戶端在請求的時(shí)候，需要決定從哪個(gè)memcached中獲取數(shù)據(jù)（hash）。

常見的hash算法可以使用：

（1）取模hash

圖 10?取模hash

如圖10所示，客戶端根據(jù)請求的key，做取模，最終根據(jù)結(jié)果選擇對(duì)應(yīng)的memcached節(jié)點(diǎn)。這種方式實(shí)現(xiàn)簡單。易于理解，缺點(diǎn)在于加減節(jié)點(diǎn)的時(shí)候，會(huì)造成較大的震蕩：每加、減一個(gè)節(jié)點(diǎn)，hash方式全部改變，整體命中率會(huì)下降的非常快。

（1）一致性hash

一致性哈希的算法描述可以參考

https://zh.wikipedia.org/wiki/%E4%B8%80%E8%87%B4%E5%93%88%E5%B8%8C

一致性哈希算法的主要優(yōu)點(diǎn)在于加減節(jié)點(diǎn)，對(duì)于服務(wù)整體的震蕩較小。并且在某個(gè)節(jié)點(diǎn)crash后，可以將后續(xù)請求，轉(zhuǎn)移至另一個(gè)節(jié)點(diǎn)中，具備一定的防單點(diǎn)特性。

2.2.2?主從雙層結(jié)構(gòu)

?? ?從單臺(tái)實(shí)例增加到一組緩存后，我們可以解決單端口容量、訪問量不足的問題，但是如果出現(xiàn)某一臺(tái)緩存掛了的情況。請求依然會(huì)落到后端的DB上。

上面也提到了一致性hash的算法，可以通過一致性hash的方式，來減少損失。

但基于一致性哈希策略的分布式實(shí)現(xiàn)在微博業(yè)務(wù)場景下也存在一些問題：

（1）微博線上業(yè)務(wù)對(duì)緩存命中率要求高。某臺(tái)緩存掛了，會(huì)導(dǎo)致緩存整體命中率下降（即使一致性hash會(huì)在一定時(shí)間后將數(shù)據(jù)重新種到另一個(gè)節(jié)點(diǎn)上），對(duì)于命中率要求在99%以上的Feed流核心業(yè)務(wù)場景來說，命中率的下降是難以接受的

（2）一致性hash存在請求漂移的情況，假設(shè)某一段時(shí)間服務(wù)因網(wǎng)絡(luò)因素訪問某個(gè)服務(wù)節(jié)點(diǎn)失敗，則在這時(shí)候，會(huì)將數(shù)據(jù)的更新、獲取都遷移到下一個(gè)節(jié)點(diǎn)上。后續(xù)網(wǎng)絡(luò)恢復(fù)后，應(yīng)用服務(wù)探測到服務(wù)節(jié)點(diǎn)可用，則繼續(xù)從原服務(wù)節(jié)點(diǎn)中獲取數(shù)據(jù)，這就導(dǎo)致了在故障期間所做的更新操作，對(duì)于原服務(wù)節(jié)點(diǎn)不可見了

目前我們對(duì)于這種單點(diǎn)問題主要是通過引入主從緩存結(jié)構(gòu)來解決的。主從結(jié)構(gòu)示意圖如下圖11所示：

圖 11?主從雙層結(jié)構(gòu)緩存

服務(wù)端在上行邏輯中，進(jìn)行雙寫操作——由應(yīng)用服務(wù)負(fù)責(zé)更新master、slave數(shù)據(jù)。

下行獲取數(shù)據(jù)，先獲取master數(shù)據(jù)，當(dāng)master返回空，或者無法取到數(shù)據(jù)的時(shí)候，訪問slave。

在這種模式下，為了避免兩份數(shù)據(jù)帶來的不一致問題，需要以master數(shù)據(jù)為準(zhǔn)。即如果有更新數(shù)據(jù)操作，需要從master中獲取數(shù)據(jù)，再對(duì)master進(jìn)行cas更新。更新成功后，才更新slave。如果cas多次后都失敗，則對(duì)master、slave進(jìn)行delete操作，后續(xù)讓請求穿透回種即可。

2.2.3?橫向線性擴(kuò)展

?? ? ? ?在雙層結(jié)構(gòu)下，我們可以很好的解決單點(diǎn)問題，即某一個(gè)節(jié)點(diǎn)如果crash了，請求可以被slave承接住，請求不會(huì)直接落在DB上。

?? ? ? 但這種架構(gòu)仍然存在一些問題：

（1）帶寬問題。由于存在熱點(diǎn)訪問的情況，線上經(jīng)常出現(xiàn)單個(gè)服務(wù)節(jié)點(diǎn)的帶寬跑滿的情況。

（2）請求量問題。隨著業(yè)務(wù)的不斷發(fā)展，并發(fā)請求數(shù)超過了單個(gè)節(jié)點(diǎn)的機(jī)器上限。數(shù)據(jù)分片、雙層結(jié)構(gòu)都不能解決這種問題。

上面的兩個(gè)問題，其實(shí)總結(jié)起來是如何快速橫向擴(kuò)展系統(tǒng)的支撐能力。對(duì)于這個(gè)問題，我們的解決思路為增加數(shù)據(jù)的副本數(shù)。即讓數(shù)據(jù)副本存在于多個(gè)節(jié)點(diǎn)中，從而平攤原本落在一個(gè)節(jié)點(diǎn)的請求。

從我們經(jīng)驗(yàn)來看，對(duì)于線性擴(kuò)展，可以在原來的master上引入一層L1層緩存。整體示意圖如12所示：

圖12?采用L1的緩存架構(gòu)

上行操作需要對(duì)L1進(jìn)行多寫。寫緩存的順序?yàn)閙aster-slave-L1(所有)，寫失敗則進(jìn)行delete操作，后續(xù)由穿透請求進(jìn)行回種。

L1可以由多組緩存組成，每組緩存相互獨(dú)立。應(yīng)用服務(wù)在獲取數(shù)據(jù)的時(shí)候，先從L1中選取一組資源，然后再進(jìn)行hash選取特定節(jié)點(diǎn)。對(duì)于multiget的場景也是先選取一組緩存，然后才對(duì)這組緩存進(jìn)行multiget操作。如果L1獲取不到數(shù)據(jù)，再依次獲取master、slave數(shù)據(jù)。獲取成功，則回種到L1中。

在采用L1的模式中，數(shù)據(jù)也是以master中數(shù)據(jù)為主的。即如果有更新數(shù)據(jù)的需要，需要從master中獲取數(shù)據(jù)原本，再進(jìn)行cas更新。如果cas更新成功，才同時(shí)更新slave、L1資源。如果對(duì)master的操作失敗，則進(jìn)行delete all操作，讓后續(xù)請求穿透回種。

當(dāng)線上流量、請求量達(dá)到一個(gè)水位的時(shí)候，我們會(huì)進(jìn)行L1的擴(kuò)容——增加一組、或幾組L1緩存，從而提升系統(tǒng)整體的承載能力。此時(shí)系統(tǒng)的整體響應(yīng)請求量是可以做到線性擴(kuò)展的。

可以看到，雙層結(jié)構(gòu)下，slave作為主的備份存在。假設(shè)線上master緩存命中率為99%，則落在slave上的請求只有1%，并且這1%的請求都是很偏、很少人訪問到的?？梢韵胂?，在這種情況下，如果master真的出現(xiàn)問題，請求全部落在slave上，slave也是沒有任何數(shù)據(jù)可供訪問的。Slave作為防單點(diǎn)措施是失敗的。

引入L1后，slave過冷并沒有被解決，同時(shí)，由于master被放置到L1之下，也遇到了slave的問題，master的數(shù)據(jù)也存在過冷的風(fēng)險(xiǎn)。為了解決上面的問題，我們在線上配置的時(shí)候，會(huì)將整組slave做為L1的一組資源進(jìn)行配置，讓slave以L1的身份承擔(dān)部分的熱請求。同時(shí)為了解決master過冷的問題，我們也會(huì)讓應(yīng)用服務(wù)在選擇L1的時(shí)候有一定的概率落空，從而讓master作為L1邏輯分組，去承擔(dān)部分熱請求。整體結(jié)構(gòu)圖如圖13所示：

圖13 slave、master同時(shí)作為L1架構(gòu)

結(jié)尾：

本文主要結(jié)合目前微博平臺(tái)的線上業(yè)務(wù)場景，根據(jù)個(gè)人對(duì)memcached的使用的經(jīng)驗(yàn)，以及分布式架構(gòu)情況做了介紹。行文倉促，肯定有很多細(xì)節(jié)需要繼續(xù)完善，如果有問題或者建議，可以微博私信?@微博平臺(tái)架構(gòu)?或講師?@LierD?一起繼續(xù)探討。

隨著微博業(yè)務(wù)的蓬勃發(fā)展，相信還會(huì)有更多的技術(shù)挑戰(zhàn)在等著我們?nèi)ソ鉀Q，去征服。我們也希望看到本文的小伙伴以及有志于做一些不一樣的互聯(lián)網(wǎng)產(chǎn)品的小伙伴們，能夠加入我們，跟我們一起去攀登技術(shù)高峰~

新兵訓(xùn)練營簡介

微博平臺(tái)新兵訓(xùn)練營活動(dòng)是微博平臺(tái)內(nèi)部組織的針對(duì)新入職同學(xué)的團(tuán)隊(duì)融入培訓(xùn)課程，目標(biāo)是團(tuán)隊(duì)融入，包括人的融入，氛圍融入，技術(shù)融入。當(dāng)前已經(jīng)進(jìn)行4期活動(dòng)，很多學(xué)員迅速成長為平臺(tái)技術(shù)骨干。

具體課程包括《環(huán)境與工具》《分布式緩存介紹》《海量數(shù)據(jù)存儲(chǔ)基礎(chǔ)》《平臺(tái)RPC框架介紹》《平臺(tái)Web框架》《編寫優(yōu)雅代碼》《一次服務(wù)上線》《Feed架構(gòu)介紹》《unread架構(gòu)介紹》

微博平臺(tái)是非常注重團(tuán)隊(duì)成員融入與成長的團(tuán)隊(duì)，在這里有人幫你融入，有人和你一起成長，也歡迎小伙伴們加入微博平臺(tái)，歡迎私信咨詢。

講師簡介

?? ? ? ? 賴佳?。ㄎ⒉╆欠Q：@LierD?），2013年7月畢業(yè)于哈爾濱工業(yè)大學(xué)后，加入新浪微博工作至今，擔(dān)任系統(tǒng)研發(fā)工程師。曾先后參與微博Feed流優(yōu)化、后端服務(wù)穩(wěn)定性建設(shè)等項(xiàng)目。關(guān)注jvm調(diào)優(yōu)，微服務(wù)，分布式存儲(chǔ)系統(tǒng)。微博平臺(tái)新兵訓(xùn)練營二期學(xué)員.

?? 業(yè)余愛好三國殺，dota，喜歡自己做飯下廚希望能在微博的平臺(tái)上認(rèn)識(shí)到更多優(yōu)秀的小伙伴，一起交流，一起成長