今天，我們來聊聊“阿里云內(nèi)存數(shù)據(jù)庫 Tair ”，我先介紹下自己，我的真名叫朱國(guó)云，花名宗岱，2008年加入阿里。在阿里主要從事存儲(chǔ)數(shù)據(jù)庫相關(guān)，包括文件存儲(chǔ)、緩存、內(nèi)存數(shù)據(jù)庫等。一開始參與過阿里云飛天操作系統(tǒng)的研發(fā)，后來主要負(fù)責(zé)Tair的研發(fā)。

1.Tair的發(fā)展歷程

接下來，我們正式進(jìn)入Tair 相關(guān)的交流。整體包括Tair的發(fā)展歷程、重大節(jié)點(diǎn)、技術(shù)難點(diǎn)以及相關(guān)實(shí)踐展開。我們先來看看“Tair的歷史和發(fā)展”，可以看下面這張圖：

Tair的歷史和發(fā)展

• 2009年，Tair1.0在淘寶孵化。
• 2014-2015年，阿里云剛起步不久，淘寶的一些基礎(chǔ)服務(wù)和阿里云整合在一起，所以在阿里云上也提供了云的緩存服務(wù)，包括云Memcache和云Redis。從Tair1.0到Tair2.0，兩者之間的核心區(qū)別就是一個(gè)是純KV，一個(gè)兼容了Redis。
• 2018年，阿里內(nèi)部有非常多高度連接數(shù)據(jù)的場(chǎng)景，如數(shù)據(jù)的存儲(chǔ)、查詢和計(jì)算。這個(gè)過程中誕生了TairGraph。
• 2019年后，我們把Tair的這些能力推出到了公共云上。包括，在云Redis里面包含了Tair，這一版即Tair3.0。
• 今年，我們把Tair產(chǎn)品在阿里云上獨(dú)立了出來，客戶能夠直接從Tair產(chǎn)品購(gòu)買和管理。在跟客戶交流中，他們有一個(gè)會(huì)經(jīng)常會(huì)問到的疑問：為什么Tair這個(gè)系統(tǒng)能夠做13年？從淘寶這個(gè)時(shí)代就開始誕生的系統(tǒng)與產(chǎn)品，今天還在阿里內(nèi)部依然大規(guī)模運(yùn)行的其實(shí)是比較少了，Tair就是其中的一個(gè)。當(dāng)然這里面經(jīng)歷了非常多的系統(tǒng)迭代和架構(gòu)的演進(jìn)。

接下來，我們來看看Tair在阿里內(nèi)部的應(yīng)用。

現(xiàn)在在阿里集團(tuán)內(nèi)部，絕大部分BU的核心在線業(yè)務(wù)都使用了Tair，包括最開始淘寶、天貓電商的交易導(dǎo)購(gòu)廣告，到菜鳥的電子面單物流送貨軌跡，再到釘釘消息的推送、優(yōu)酷的視頻播放列表等，這些在線業(yè)務(wù)都是用了Tair。

今天在一些偏 TP 類的在線業(yè)務(wù)場(chǎng)景，業(yè)務(wù)主要核心依賴的就是Tair加數(shù)據(jù)庫。Tair在這里面的核心定位就是承載超大的流量和高速的存儲(chǔ)，且并不僅僅是一個(gè)緩存，有非常多業(yè)務(wù)直接把它作為內(nèi)存的存儲(chǔ)去用。

從上文可以了解到，Tair在阿里支撐著大部分的項(xiàng)目，且不斷進(jìn)行優(yōu)化，在這過程中，Tair也遇到過很多的技術(shù)挑戰(zhàn)，接下來我們看看Tair發(fā)展過程中的重要節(jié)點(diǎn)和技術(shù)挑戰(zhàn)。

2.Tair的重要節(jié)點(diǎn)和技術(shù)挑戰(zhàn)

2.1 重要節(jié)點(diǎn)

在淘寶電商交易剛起步的時(shí)候，和現(xiàn)在的系統(tǒng)架構(gòu)比，當(dāng)時(shí)的業(yè)務(wù)架構(gòu)相對(duì)來說是比較簡(jiǎn)單的。

在Tair誕生之前，我們內(nèi)部有一個(gè)TDBM系統(tǒng)，這是一個(gè)獨(dú)立的、單機(jī)緩存服務(wù)，容量是很有限的，所支撐的訪問量也有限。最關(guān)鍵的是它是一個(gè)單點(diǎn)，在高可用上是沒有的。所以在 2009 年的時(shí)候，開發(fā)了Tair 1.0。

Tair 1.0是一個(gè)獨(dú)立的、分布式的緩存服務(wù)，是集群模式的，也完整實(shí)現(xiàn)了節(jié)點(diǎn)的擴(kuò)縮容，這是區(qū)別于TDBM系統(tǒng)的。在Tair 1.0形成基礎(chǔ)的技術(shù)架構(gòu)后，基于這條路線上Tair演進(jìn)了很多年。

隨著移動(dòng)互聯(lián)網(wǎng)誕生，整個(gè)應(yīng)用場(chǎng)景變得更豐富了。電商變得更繁榮、搜索廣告推薦用得越來越多、社交網(wǎng)絡(luò)的興起、手游的發(fā)展、 LBS的應(yīng)用，在這些行業(yè)的在線場(chǎng)景中，對(duì)緩存和高速存儲(chǔ)系統(tǒng)的需求變得越來越大，從下圖可以看到，Tair 1.0也是隨著這些行業(yè)不斷演進(jìn)和發(fā)展。

數(shù)據(jù)量的變大，對(duì)Tair的內(nèi)存存儲(chǔ)提出了新的挑戰(zhàn)，如何低成本的解決面向互聯(lián)網(wǎng)在線數(shù)據(jù)的存儲(chǔ)和查詢。正恰SSD固態(tài)硬盤的成熟，Tair基于 SSD存儲(chǔ)介質(zhì)，實(shí)現(xiàn)了Tair LDB持久存儲(chǔ)引擎，提供了一個(gè)高性能大容量的解決方案，而在2018 年之后持久內(nèi)存的出現(xiàn)，新的存儲(chǔ)介質(zhì)，也給Tair提供了一個(gè)新的演進(jìn)契機(jī)。

整體來說，在這個(gè)階段，Tair從1.0的緩存定位逐步演進(jìn)到了NoSQL的存儲(chǔ)系統(tǒng)。接口層面，它也從一個(gè)最簡(jiǎn)單的 KV 接口演進(jìn)到提供了更復(fù)雜更豐富的數(shù)據(jù)接口。

那么Tair的技術(shù)架構(gòu)是怎樣的呢？在當(dāng)時(shí)是比較典型的架構(gòu)：SDK、管理節(jié)點(diǎn)和數(shù)據(jù)DB節(jié)點(diǎn)，集群內(nèi)部通過類一致性哈希的算法，通過哈希把數(shù)據(jù)切分到多個(gè)分片上去。同時(shí)通過主從機(jī)制來實(shí)現(xiàn)數(shù)據(jù)DB節(jié)點(diǎn)的高可用。

整體系統(tǒng)除了數(shù)據(jù)流之外，還有一整套的泰斗（Tiddo）來配合完成系統(tǒng)的管理。例如宕機(jī)的自動(dòng)切換，集群擴(kuò)縮容后的自動(dòng)遷移平衡數(shù)據(jù)。除此之外，也可以選擇帶Proxy的架構(gòu)，Proxy可以實(shí)現(xiàn)更豐富的訪問聚合、連接收斂、QueryCache等高級(jí)功能。

圖上右邊其實(shí)是單個(gè) DB 進(jìn)程，它是統(tǒng)一的服務(wù)技術(shù)框架，它可以支持多個(gè)存儲(chǔ)引擎在里面。譬如，我們?cè)瓉矶x的 Tai1.0 MDB 那它就是一個(gè) KV 內(nèi)存的，就我們上面的這個(gè)進(jìn)程框架是一模一樣的，下面的存儲(chǔ)引擎是可以替換的。

2.2 技術(shù)挑戰(zhàn)

接下來，我會(huì)講三個(gè)我們就在阿里集團(tuán)這幾年面臨的這一些技術(shù)挑戰(zhàn)，就是阿里集團(tuán)做單元化、熱點(diǎn)、性能與成本。

• 技術(shù)挑戰(zhàn)--單元化

單元化這個(gè)項(xiàng)目其實(shí)非常宏大，相當(dāng)于要從整個(gè)應(yīng)用層開始，到中間件，譬如 MQ、TTDL這一層，再到Tair跟數(shù)據(jù)庫這一層。Tair當(dāng)時(shí)的三大塊包括MDB、RDB和LDB。對(duì)于MDB，我們是作為緩存去用的。所以在做單元化的時(shí)候，并不會(huì)主動(dòng)去做數(shù)據(jù)同步，而是由數(shù)據(jù)庫這一層做數(shù)據(jù)同步之后到另外單元來做一個(gè)反向的失效。對(duì)于 RDB和LDB，很多業(yè)務(wù)是拿來作為數(shù)據(jù)最終的存儲(chǔ)去用的，所以這兩大塊我們相當(dāng)于做了自己的數(shù)據(jù)同步方案。

這里面比較難解的問題是，怎么能夠確保源端寫入的能夠快速地在目的端所消費(fèi)掉？這個(gè)問題會(huì)和源端的寫入速度目的端的消費(fèi)速度、兩個(gè)集群間機(jī)房的距離、網(wǎng)絡(luò)速度都是相關(guān)的。第一是要做好容量規(guī)劃，第二是在進(jìn)程上面，我們要更多地做批量的、合并的處理，流式地去發(fā)送。

另外，我們?nèi)魏我粋€(gè)系統(tǒng)，特別是在線處理類的，沒有辦法確保沒有問題產(chǎn)生。無論是新發(fā)版還是觸發(fā)了一個(gè)很久之前有 bug 的情況，往往是很難定位的，可能在幾分鐘里面定位不出來或者半小時(shí)都定位不出來。那這個(gè)時(shí)候可以快速地把流量切到另外一個(gè)機(jī)房去，這樣對(duì)業(yè)務(wù)整體基本上沒影響。這也是單元化帶來了一個(gè)非常大的好處。

• 技術(shù)挑戰(zhàn)--熱點(diǎn)

2016年雙十一的一個(gè)小插曲，我們Tair的一臺(tái)機(jī)器流量特別大，最高大概到了70%+左右，該服務(wù)器的 QPS 在當(dāng)時(shí)幾十萬次每秒，但是value size特別大。當(dāng)時(shí)一看就是一個(gè)火熱的手機(jī)商品，也是那幾年雙十一最熱的商品項(xiàng)之一，它的訪問量最大，而流量都到了一臺(tái)服務(wù)器上。當(dāng)時(shí)平穩(wěn)度過了，如果訪問量再大一點(diǎn)，流量再大一點(diǎn)，那可能服務(wù)器流量真會(huì)跑到一個(gè)非常高的水位，對(duì)穩(wěn)定性產(chǎn)生影響。

目前絕大部份存儲(chǔ)系統(tǒng)和數(shù)據(jù)庫系統(tǒng)，對(duì)于一份數(shù)據(jù)都是單節(jié)點(diǎn)訪問，這個(gè)問題其實(shí)是很難避免的。而單個(gè)數(shù)據(jù)節(jié)點(diǎn)訪問量大，造成該現(xiàn)象的原因很多，例如有熱點(diǎn)的商品反問，還是業(yè)務(wù)寫了個(gè)死循環(huán)之類，這些都可能造成某一個(gè)節(jié)點(diǎn)的訪問量特別大。

在那年雙十一，Tair最新的SDK 其實(shí)具備本地緩存的功能，可以通過推送開啟。但是有的業(yè)務(wù)升級(jí)到了新版的Tair SDK，有的還沒有，所以很難全部控制住，這也是系統(tǒng)復(fù)雜之后應(yīng)用復(fù)雜之后常見的現(xiàn)象，很難確保版本統(tǒng)一。同時(shí)，SDK側(cè)的本地緩存，占用應(yīng)用服務(wù)器的資源，內(nèi)存是非常寶貴的，這個(gè)緩存可能會(huì)對(duì)業(yè)務(wù)產(chǎn)生影響。既然SDK側(cè)的方案并不是最合適的，所以我們考慮通過服務(wù)端來解決。

最終討論的方案是，每一個(gè)DB 節(jié)點(diǎn)上開一個(gè)熱點(diǎn)區(qū)域，然后實(shí)時(shí)監(jiān)測(cè)到有熱點(diǎn)發(fā)生。熱點(diǎn)發(fā)生之后，會(huì)把熱點(diǎn)推送到一個(gè)集群里面的 N 臺(tái)機(jī)器數(shù)，譬如 10 臺(tái)左右。在有熱點(diǎn)發(fā)生情況下，我們可以用集群里面 10 臺(tái)機(jī)器來扛，而不是像原來一臺(tái)機(jī)器去扛。

這里面最核心的關(guān)鍵是如何快速精準(zhǔn)地發(fā)現(xiàn)，然后推送到其他數(shù)據(jù)節(jié)點(diǎn)上。這個(gè)時(shí)候我們可能會(huì)有在可失效的時(shí)間里面讀到臟數(shù)據(jù)，對(duì)于絕大部分業(yè)務(wù)來說基本上都是可接受的。無法接受的，我們就不開啟這個(gè)特性。

• 技術(shù)挑戰(zhàn)--性能與成本

2017 年產(chǎn)生了一個(gè)新問題，就是隨著Tair在阿里內(nèi)部的規(guī)模越來越大，對(duì)成本降低有了要求，比如成本降低10%、20%，甚至更多。

成本優(yōu)化，最直接的一個(gè)工作就是提升單機(jī)單節(jié)點(diǎn)的服務(wù)能力。下圖左邊可以看到我們?nèi)魏蔚姆?wù)進(jìn)程基本上都會(huì)有鎖，因?yàn)殒i的存在，使得整個(gè)進(jìn)程的性能沒有辦法跑得非常高，所以我們對(duì)整個(gè)MDB包括今天的Tair都進(jìn)行了改造。改造之后把每一個(gè)操作盡量在單個(gè)線程里面做下去，相當(dāng)于盡量把鎖去掉，然后再用上了DPDK加用戶態(tài)協(xié)議棧技術(shù)。通過一系列優(yōu)化之后，在下圖可以看到鎖只占了1%。在32c的機(jī)器上極限可以跑到 500萬QPS ，如果是64c的話可以達(dá)到上千萬，這個(gè)吞吐基本上是線性的當(dāng)然，真正線上運(yùn)行的時(shí)候，并不是運(yùn)行到這么高負(fù)載，而是確保高吞吐、低延時(shí)和穩(wěn)定的一個(gè)權(quán)衡值。這個(gè)工作中的成果之一——Tair HotRing，我們也將之發(fā)布在FAST會(huì)議上。

以上是阿里集團(tuán)內(nèi)部Tair近幾年面臨的一些重要技術(shù)挑戰(zhàn)，穩(wěn)定性、單元化和性能成本等等。

3.云原生內(nèi)存數(shù)據(jù)庫Tair產(chǎn)品形態(tài)

阿里云的內(nèi)存數(shù)據(jù)庫Tair經(jīng)過多年演進(jìn)，已經(jīng)完整兼容了Memcache&Redis，還有一部分是我們的圖引擎，兼容了開源的 Gremlin和Neo4j的 Cypher。我們還有一個(gè)支持標(biāo)準(zhǔn) SQL 的引擎，這個(gè)我們用來作為高性能的實(shí)時(shí)數(shù)據(jù)處理。所以，我們今天 Tair 內(nèi)存數(shù)據(jù)庫的定義是一個(gè)緩存，加上高性能數(shù)據(jù)庫及數(shù)據(jù)實(shí)時(shí)處理的定義。

Tair產(chǎn)品的架構(gòu)形態(tài)，與我們今天在阿里云上售賣的 Redis 其實(shí)是一樣的，分為標(biāo)準(zhǔn)的主從版、雙副本主從版，也有一個(gè)集群版。所以最大可以從1個(gè) G 擴(kuò)展到數(shù)個(gè) T ，那么它跟社區(qū)托管的 Redis 不一樣的是什么呢？我們基于持久內(nèi)存，基于云盤，推出了持久內(nèi)存型和容量存儲(chǔ)型，這兩個(gè)其實(shí)能夠滿足客戶對(duì)訪問量與容量不同要求的情況與場(chǎng)景。性能增強(qiáng)型，它的整體性能比開源 Redis 會(huì)高兩倍及以上，包括我們?cè)诶锩孀隽朔浅６嗥髽I(yè)級(jí)的功能，來面向客戶的關(guān)鍵業(yè)務(wù)場(chǎng)景。

我們今天主推的是兩種形態(tài)，一種是Tair 性能增強(qiáng)，這個(gè)相當(dāng)于在客戶業(yè)務(wù)的核心關(guān)鍵場(chǎng)景，我們建議客戶去選。相比開源 Redis，首先是它的性能更強(qiáng)，能夠支持因運(yùn)營(yíng)活動(dòng)或業(yè)務(wù)變化所帶來的流量突高，訪問連接數(shù)也會(huì)更多。開源的Redis其實(shí)支持活躍的上萬連接數(shù)比較困難，而Tair性能增強(qiáng)其實(shí)是可以支持?jǐn)?shù)萬的。

例如我們其實(shí)看到有很多客戶用社區(qū)版Redis，它就是用了讀寫分離一主五從。這個(gè)架構(gòu)可以看到整個(gè)可擴(kuò)展性非常低，它從從節(jié)點(diǎn)上讀，其實(shí)讀到的一致性也會(huì)比較弱。所以我們給客戶推薦Tair的集群版，最終價(jià)格比社區(qū)版貴了 1.2 倍，但是總體容量是社區(qū)版的 4 倍，包括總吞吐它也是 4 倍。所以Tair的性能增強(qiáng)版比開源版在很多場(chǎng)景下對(duì)客戶的整個(gè) TCO 來說相對(duì)更有優(yōu)勢(shì)一些。

2018年之后我們花了非常多的經(jīng)歷在是持久內(nèi)存形態(tài)上，有兩個(gè)核心目標(biāo)，第一是提供一個(gè)比社區(qū) Redis成本更低的系統(tǒng)，性能和Redis差不多。吞吐大概是社區(qū)版redis的90%+，成本大概是社區(qū)版的70%。它比社區(qū)版好的是每一個(gè)操作都能夠做到持久化，落到持久內(nèi)存上。

下面這一頁是我們的持久內(nèi)存性能對(duì)比。左邊是 Redis 6.0，然后右邊是 Tair 持久內(nèi)存版。我們可以看到寫跟讀的性能總吞吐大概都是 90% +。右邊這張圖，客戶端延遲 P95（us），我們把Redis 里面的 AOF 重寫機(jī)制給去掉了，所以這個(gè)毛刺抖動(dòng)是更低的，讀的話確實(shí)比全內(nèi)存版本慢一點(diǎn)，因?yàn)楸旧沓志脙?nèi)存的訪問延遲會(huì)高一點(diǎn)。

接下來我們看看第4部分，這部分其實(shí)是講前面支撐我們 Tair 產(chǎn)品形態(tài)的關(guān)鍵能力，就包括跟開源的 Redis 的核心區(qū)別是什么、關(guān)鍵技術(shù)點(diǎn)是什么？先看看客戶用 Redis 的一些痛點(diǎn)。

4.云原生內(nèi)存數(shù)據(jù)庫Tair關(guān)鍵能力

4.1 Redis的一些痛點(diǎn)

我們可以看一下左邊跟右邊的痛點(diǎn)為什么會(huì)是這樣的情況？

其實(shí)總結(jié)下來就是開源的 Redis 在超多訪問鏈接下，它的性能會(huì)下降。但是在容器化的時(shí)代下，應(yīng)用的服務(wù)器變得越來越多，每一臺(tái)應(yīng)用它的訪問連接數(shù)也會(huì)越來越多，幾千上萬是很常見的。

另外，在延時(shí)&抖動(dòng)上， Redis 其實(shí)是一個(gè)單線程的，那在這種情況下，它只要有一個(gè)慢查詢，譬如 Hgetall 之類的，它往往會(huì)帶來整體變慢，其他的短查詢也得不到很好地處理。

HA 高可用會(huì)出現(xiàn)誤判，跟前面一樣，一個(gè) Hgetall比較大的情況下，處理線程會(huì)把CPU 全占住， HA 的判活就有可能得不到處理，所以它的整個(gè)數(shù)據(jù)操作與控制操作都是在一個(gè)工作線程內(nèi)處理的。還有整體的內(nèi)存統(tǒng)計(jì)是沒有區(qū)分開的，所以用戶往往發(fā)現(xiàn)配了實(shí)例內(nèi)存，還沒有用滿的情況下就發(fā)生了數(shù)據(jù)淘汰。

然后，我們從內(nèi)核的技術(shù)上來講一下 Redis 與 Tair 的一個(gè)區(qū)別。

4.2 Redis vs Tair

上圖左邊是開源的 Redis 在6.0之前，它是一個(gè)單線程的。在 6.0 之后，它號(hào)稱是一個(gè)多線程的，但是從右圖也能夠看到，它只是在 IO 處理這塊搞成多線程了，但是在內(nèi)部真正的數(shù)據(jù)操作這一塊，它依然是單線程在做。

為什么它很難做成多線程呢？一是因?yàn)樵谠瓉淼?nbsp;Redis 內(nèi)部，所有都是單線程的，大部分操作是沒有鎖的，所以想改成多線程是非常困難的；二是代碼是在10年前寫的，并沒有進(jìn)行重構(gòu)過，在歷史代碼上去做優(yōu)化是相對(duì)困難的。

對(duì)于Tair來說，我們脫離Redis，從頭自研，我們把網(wǎng)絡(luò)接收線程跟工作處理線程獨(dú)立開了，都可以用 N x M 的方式靈活地去配；這樣 Tair 就可以處理數(shù)十萬的活躍的連接數(shù)，因?yàn)榫W(wǎng)絡(luò)線程足夠多，單機(jī)的處理引擎可以提升得足夠高，甚至可以跑到百萬級(jí)。

在業(yè)內(nèi)也有一種討論，到底是搞成分布式好還是搞成單機(jī)好？

在我看來，非常多情況下，單機(jī)的形態(tài)會(huì)有不少優(yōu)勢(shì)。如今業(yè)務(wù)越來越復(fù)雜，如果把它搞成分布式，往往會(huì)有一些跨節(jié)點(diǎn)的計(jì)算，甚至要求這些計(jì)算要有事務(wù)。搞成集群后，跨節(jié)點(diǎn)的計(jì)算和事務(wù)會(huì)變得越來越復(fù)雜，很難去處理。在這種情況下，能夠給客戶一個(gè)大規(guī)格、大訪問處理量的單機(jī)引擎其實(shí)是最合適的。

當(dāng)然，在多線程內(nèi)部我們也做了一些慢查詢請(qǐng)求，把它實(shí)時(shí)監(jiān)測(cè)出來，并且分離到慢查詢請(qǐng)求池里面。這一類的工作，我們盡量確保用戶的請(qǐng)求能夠在一個(gè)比較確定的訪問延時(shí)里面返回給用戶。

接下來我們看看Tair引擎的高可用，前面我們講了社區(qū)版的 Redis ，它的探活跟數(shù)據(jù)操作其實(shí)是在一個(gè)工作線程里面，因?yàn)閿?shù)據(jù)操作慢了之后，會(huì)產(chǎn)生一些誤判，所以我們把所有的管控請(qǐng)求放到獨(dú)立的處理系統(tǒng)里面；就把這些 HA 把這些訪問、統(tǒng)計(jì)信息等完全隔離，包括用戶的數(shù)據(jù)訪問跟系統(tǒng)的高可用統(tǒng)計(jì)都是隔離開的，確保質(zhì)量更好。

接下來我們講講Tair的集群架構(gòu)。

4.3Tair的集群架構(gòu)

Tair的集群架構(gòu)，包括搬遷的擴(kuò)縮容，與開源的社區(qū)版是完全不一樣的。開源的社區(qū)都是用 Gossip ，相當(dāng)于是P2P 來做信息的同步與探活。另外它的節(jié)點(diǎn)變得越來越多的時(shí)候，想在集群里面達(dá)到信息的一致性也會(huì)變得越來越慢。社區(qū)版的遷移擴(kuò)縮容是按 Key 級(jí)別的，所以在大 Key 的時(shí)候往往會(huì)出現(xiàn)一些遷移卡頓等，這個(gè)時(shí)候也會(huì)有一些 HA 的誤判。我們?nèi)缃裨谶@一方面也做了一些改進(jìn)，相當(dāng)于是由中心節(jié)點(diǎn)對(duì)整個(gè)集群做 HA 的判活，包括集群管理。整個(gè)數(shù)據(jù)搬遷是按slot去搬遷的，所以整個(gè)搬遷速度會(huì)比按key快很多。

4.4 特定重要場(chǎng)景的優(yōu)化

Pubsub相當(dāng)于是 Tair 與 Redis 里面做消息處理用的。原來的單線程，如果是掛載的客戶端多的話，其實(shí)推送起來會(huì)比較慢。它的單線處理，相當(dāng)于在Tair 里面把它作為一個(gè)多線程處理，所以這是一個(gè)并發(fā)的處理操作。

4.5 TairStack：豐富的數(shù)據(jù)模型

TairStack有著豐富的數(shù)據(jù)模型，這其實(shí)是在阿里內(nèi)部實(shí)踐中積累出的常用數(shù)據(jù)結(jié)構(gòu)，目的就是讓業(yè)務(wù)開發(fā)更容易。從上圖可以看到，我們有些是對(duì)外開源了，包括：TairHash、TairString等，這些結(jié)構(gòu)也是可以放到開源的 Redis 里面去用，跟開源的 Redis 是完全兼容的，這些module在公共云上也被非常多客戶使用了。

接下來我們看看Tair的企業(yè)級(jí)能力。

4.6 Tair的企業(yè)級(jí)能力

Tair的企業(yè)級(jí)能力這里我主要講3部分，包括全球多活、安全能力和 Tair引擎可觀測(cè)性。

• 全球多活

如今的一些客戶，特別是中大型的客戶，他希望在多個(gè)地域做多活。所以我們今天是可以做到三地域多活的同步。它的原理是通過 Binlog 來做 3地的多活。我們更建議應(yīng)用在做多活的時(shí)候，能夠在應(yīng)用層面按 key 分布到多個(gè)單元，這樣會(huì)更容易避免沖突。

• 安全能力

安全能力部分在公有云上也是比較重要的一個(gè)地方。我們提供給客戶的實(shí)例是在VPC內(nèi)部，整個(gè)安全網(wǎng)絡(luò)上面是有確保的，客戶可以通過 SSL來加密訪問Tair，這個(gè)上面可以進(jìn)行更高層次的訪問通信的加密。

我們有一個(gè)功能叫 PITR，可以幫助客戶把數(shù)據(jù)恢復(fù)到客戶指定的任意時(shí)間點(diǎn)，可以到秒級(jí)別。還有一個(gè)重要的功能就是用戶的審計(jì)。經(jīng)常會(huì)有一些客戶說，我的訪問量怎么這么大？這個(gè)訪問源是從哪里過來的？或者是我的數(shù)據(jù)被清理掉了，是哪里被刪的，通過這個(gè)是能夠看得到的。所以從整個(gè)技術(shù)實(shí)現(xiàn)上來說，我們其實(shí)做了一些高頻的快照，大家可以認(rèn)為是一個(gè)全量的快照，再加上增量的 Binlog 來幫助客戶恢復(fù)到那個(gè)時(shí)間點(diǎn)去。

• Tair引擎可觀測(cè)性

在可觀測(cè)性上我們投入的也比較多，當(dāng)然還是有一些沒有做得特別好，譬如集群級(jí)別的聚合工作其實(shí)一直在探索。我們能夠把有熱 Key 的、有訪問量比較大 key 的實(shí)時(shí)地看到，包括在引擎級(jí)別，每一個(gè)操作的訪問延時(shí)是能夠看得到的。一旦慢了的話，我們可以看到在哪一塊操作上慢了。

5.Tair 應(yīng)用

• 電商方面：

Tair在電商方面，主要是用做緩存與內(nèi)存存儲(chǔ)，一般就用在登陸系統(tǒng)、用戶系統(tǒng)、商品系統(tǒng)、購(gòu)物車、個(gè)性化推薦上面。

• 游戲方面：

游戲客戶最重要的除了低延遲、彈性伸縮、高可用之外，還有備份回檔、無感擴(kuò)容。我們今天在主動(dòng)擴(kuò)容下，它的業(yè)務(wù)并不會(huì)掉線。這個(gè)是通過我們整體的集群方案，包括數(shù)據(jù)的遷移方案來提供給客戶的。

• 金融、安全風(fēng)控方面：

在金融、安全風(fēng)控方面，Tair里面做了一些計(jì)算的算值，可以在某一個(gè)時(shí)間段里面譬如購(gòu)買商品的數(shù)量，這一類的計(jì)算來做防黃牛反作弊。

• 生活服務(wù)方面：

LBS 生活服務(wù)，主要通過即時(shí)的功能來完成。它與 Redis Geohash的核心區(qū)別是 Geohash只能做點(diǎn)對(duì)點(diǎn)關(guān)系的鄰近的查詢，譬如它只能搜最近10km的人或者是離我最近的店。

6.總結(jié)

第一部分講了Tair從阿里集團(tuán)經(jīng)過 13 年，發(fā)展到阿里云上推出給客戶使用。從單一緩存發(fā)展到幫助客戶構(gòu)建多樣化實(shí)時(shí)場(chǎng)景。

第二部分是前幾年在阿里集團(tuán)內(nèi)部所面臨的一些重要技術(shù)挑戰(zhàn)，包括熱點(diǎn)、多活、性能、成本等問題的解決和優(yōu)化。

第三、第四部分關(guān)于通過Tair自研引擎充分利用云基礎(chǔ)設(shè)施上面不同的存儲(chǔ)介質(zhì)來給客戶提供更合適的選擇和更高的服務(wù)SLA。最后關(guān)于Tair的應(yīng)用解讀，助力客戶構(gòu)建在線實(shí)時(shí)場(chǎng)景。