一、概述

1.1 業(yè)務(wù)背景

vivo短視頻在視頻推薦時需要對用戶已經(jīng)看過的視頻進(jìn)行過濾去重，避免給用戶重復(fù)推薦同一個視頻影響體驗。在一次推薦請求處理流程中，會基于用戶興趣進(jìn)行視頻召回，大約召回2000~10000條不等的視頻，然后進(jìn)行視頻去重，過濾用戶已經(jīng)看過的視頻，僅保留用戶未觀看過的視頻進(jìn)行排序，選取得分高的視頻下發(fā)給用戶。

1.2 當(dāng)前現(xiàn)狀

當(dāng)前推薦去重基于Redis Zset實現(xiàn)，服務(wù)端將播放埋點上報的視頻和下發(fā)給客戶端的視頻分別以不同的Key寫入Redis ZSet，推薦算法在視頻召回后直接讀取Redis里對應(yīng)用戶的播放和下發(fā)記錄（整個ZSet），基于內(nèi)存中的Set結(jié)構(gòu)實現(xiàn)去重，即判斷當(dāng)前召回視頻是否已存在下發(fā)或播放視頻Set中，大致的流程如圖1所示。

（圖1：短視頻去重當(dāng)前現(xiàn)狀）

視頻去重本身是基于用戶實際觀看過的視頻進(jìn)行過濾，但考慮到實際觀看的視頻是通過客戶端埋點上報，存在一定的時延，因此服務(wù)端會保存用戶最近100條下發(fā)記錄用于去重，這樣就保證了即使客戶端埋點還未上報上來，也不會給用戶推薦了已經(jīng)看過的視頻（即重復(fù)推薦）。而下發(fā)給用戶的視頻并不一定會被曝光，因此僅保存100條，使得未被用戶觀看的視頻在100條下發(fā)記錄之后仍然可以繼續(xù)推薦。

當(dāng)前方案主要問題是占用Redis內(nèi)存非常大，因為視頻ID是以原始字符串形式存在Redis Zset中，為了控制內(nèi)存占用并且保證讀寫性能，我們對每個用戶的播放記錄最大長度進(jìn)行了限制，當(dāng)前限制單用戶最大存儲長度為10000，但這會影響重度用戶產(chǎn)品體驗。

二、方案調(diào)研

2.1 主流方案

第一，存儲形式。視頻去重場景是典型的只需要判斷是否存在即可，因此并不需要把原始的視頻ID存儲下來，目前比較常用的方案是使用布隆過濾器存儲視頻的多個Hash值，可降低存儲空間數(shù)倍甚至十幾倍。

第二，存儲介質(zhì)。如果要支持存儲90天（三個月）播放記錄，而不是當(dāng)前粗暴地限制最大存儲10000條，那么需要的Redis存儲容量非常大。比如，按照5000萬用戶，平均單用戶90天播放10000條視頻，每個視頻ID占內(nèi)存25B，共計需要12.5TB。視頻去重最終會讀取到內(nèi)存中完成，可以考慮犧牲一些讀取性能換取更大的存儲空間。而且，當(dāng)前使用的Redis未進(jìn)行持久化，如果出現(xiàn)Redis故障會造成數(shù)據(jù)丟失，且很難恢復(fù)（因數(shù)據(jù)量大，恢復(fù)時間會很長）。

目前業(yè)界比較常用的方案是使用磁盤KV（一般底層基于RocksDB實現(xiàn)持久化存儲，硬盤使用SSD），讀寫性能相比Redis稍遜色，但是相比內(nèi)存而言，磁盤在容量上的優(yōu)勢非常明顯。

2.2 技術(shù)選型

第一，播放記錄。因需要支持至少三個月的播放歷史記錄，因此選用布隆過濾器存儲用戶觀看過的視頻記錄，這樣相比存儲原始視頻ID，空間占用上會極大壓縮。我們按照5000萬用戶來設(shè)計，如果使用Redis來存儲布隆過濾器形式的播放記錄，也將是TB級別以上的數(shù)據(jù)，考慮到我們最終在主機(jī)本地內(nèi)存中執(zhí)行過濾操作，因此可以接受稍微低一點的讀取性能，選用磁盤KV持久化存儲布隆過濾器形式的播放記錄。

第二，下發(fā)記錄。因只需存儲100條下發(fā)視頻記錄，整體的數(shù)據(jù)量不大，而且考慮到要對100條之前的數(shù)據(jù)淘汰，仍然使用Redis存儲最近100條的下發(fā)記錄。

三、方案設(shè)計

基于如上的技術(shù)選型，我們計劃新增統(tǒng)一去重服務(wù)來支持寫入下發(fā)和播放記錄、根據(jù)下發(fā)和播放記錄實現(xiàn)視頻去重等功能。其中，重點要考慮的就是接收到播放埋點以后將其存入布隆過濾器。在收到播放埋點以后，以布隆過濾器形式寫入磁盤KV需要經(jīng)過三步，如圖2所示：第一，讀取并反序列化布隆過濾器，如布隆過濾器不存在則需創(chuàng)建布隆過濾器；第二，將播放視頻ID更新到布隆過濾器中；第三，將更新后的布隆過濾器序列化并回寫到磁盤KV中。

（圖2：統(tǒng)一去重服務(wù)主要步驟）

整個過程很清晰，但是考慮到需要支持千萬級用戶量，假設(shè)按照5000萬用戶目標(biāo)設(shè)計，我們還需要考慮四個問題：

• 第一，視頻按刷次下發(fā)（一刷5~10條視頻），而播放埋點按照視頻粒度上報，那么就視頻推薦消重而言，數(shù)據(jù)的寫入QPS比讀取更高，然而，相比Redis磁盤KV的性能要遜色，磁盤KV本身的寫性能比讀性能低，要支持5000萬用戶量級，那么如何實現(xiàn)布隆過濾器寫入磁盤KV是一個要考慮的重要問題。
• 第二，由于布隆過濾器不支持刪除，超過一定時間的數(shù)據(jù)需要過期淘汰，否則不再使用的數(shù)據(jù)將會一直占用存儲資源，那么如何實現(xiàn)布隆過濾器過期淘汰也是一個要考慮的重要問題。
• 第三，服務(wù)端和算法當(dāng)前直接通過Redis交互，我們希望構(gòu)建統(tǒng)一去重服務(wù)，算法調(diào)用該服務(wù)來實現(xiàn)過濾已看視頻，而服務(wù)端基于Java技術(shù)棧，算法基于C++技術(shù)棧，那么需要在Java技術(shù)棧中提供服務(wù)給C++技術(shù)棧調(diào)用。我們最終采用gRPC提供接口給算法調(diào)用，注冊中心采用了Consul，該部分非重點，就不詳細(xì)展開闡述。
• 第四，切換到新方案后我們希望將之前存儲在Redis ZSet中的播放記錄遷移到布隆過濾器，做到平滑升級以保證用戶體驗，那么設(shè)計遷移方案也是要考慮的重要問題。

3.1 整體流程

統(tǒng)一去重服務(wù)的整體流程及其與上下游之間的交互如圖3所示。服務(wù)端在下發(fā)視頻的時候，將當(dāng)次下發(fā)記錄通過統(tǒng)一去重服務(wù)的Dubbo接口保存到Redis下發(fā)記錄對應(yīng)的Key下，使用Dubbo接口可以確保立即將下發(fā)記錄寫入。同時，監(jiān)聽視頻播放埋點并將其以布隆過濾器形式存放到磁盤KV中，考慮到性能我們采用了批量寫入方案，具體下文詳述。統(tǒng)一去重服務(wù)提供RPC接口供推薦算法調(diào)用，實現(xiàn)對召回視頻過濾掉用戶已觀看的視頻。

（圖3：統(tǒng)一去重服務(wù)整體流程）

磁盤KV寫性能相比讀性能差很多，尤其是在Value比較大的情況下寫QPS會更差，考慮日活千萬級情況下磁盤KV寫性能沒法滿足直接寫入要求，因此需要設(shè)計寫流量匯聚方案，即將一段時間以內(nèi)同一個用戶的播放記錄匯聚起來一次寫入，這樣就大大降低寫入頻率，降低對磁盤KV的寫壓力。

3.2 流量匯聚

為了實現(xiàn)寫流量匯聚，我們需要將播放視頻先暫存在Redis匯聚起來，然后隔一段時間將暫存的視頻生成布隆過濾器寫入磁盤KV中保存，具體而言我們考慮過N分鐘僅寫入一次和定時任務(wù)批量寫入兩種方式。接下來詳細(xì)闡述我們在流量匯聚和布隆過濾器寫入方面的設(shè)計和考慮。

3.2.1 近實時寫入

監(jiān)聽到客戶端上報的播放埋點后，原本應(yīng)該直接將其更新到布隆過濾器并保存到磁盤KV，但是考慮到降低寫頻率，我們只能將播放的視頻ID先保存到Redis中，N分鐘內(nèi)僅統(tǒng)一寫一次磁盤KV，這種方案姑且稱之為近實時寫入方案吧。

最樸素的想法是每次寫的時候，在Redis中保存一個Value，N分鐘以后失效，每次監(jiān)聽到播放埋點以后判斷這個Value是否存在，如果存在則表示N分鐘內(nèi)已經(jīng)寫過一次磁盤KV本次不寫，否則執(zhí)行寫磁盤KV操作。這樣的考慮主要是在數(shù)據(jù)產(chǎn)生時，先不要立即寫入，等N分鐘匯聚一小批流量之后再寫入。這個Value就像一把“鎖”，保護(hù)磁盤KV每隔N分鐘僅被寫入一次，如圖4所示，如果當(dāng)前為已加鎖狀態(tài)，再進(jìn)行加鎖會失敗，可保護(hù)在加鎖期間磁盤KV不被寫入。從埋點數(shù)據(jù)流來看，原本連續(xù)不斷的數(shù)據(jù)流，經(jīng)過這把“鎖”就變成了每隔N分鐘一批的微批量數(shù)據(jù)，從而實現(xiàn)流量匯聚，并降低磁盤KV的寫壓力。

（圖4：近實時寫入方案）

近實時寫入的出發(fā)點很單純，優(yōu)勢也很明顯，可以近實時地將播放埋點中的視頻ID寫入到布隆過濾器中，而且時間比較短（N分鐘），可以避免Redis Zset中暫存的數(shù)據(jù)過長。但是，仔細(xì)分析還需要考慮很多特殊的場景，主要如下：

第一，Redis中保存一個Value其實相當(dāng)于一個分布式鎖，實際上很難保證這把“鎖”是絕對安全的，因此可能會存在兩次收到播放埋點均認(rèn)為可以進(jìn)行磁盤KV寫操作，但這兩次讀到的暫存數(shù)據(jù)不一定一樣，由于磁盤KV不支持布隆過濾器結(jié)構(gòu)，寫入操作需要先從磁盤KV中讀出當(dāng)前的布隆過濾器，然后將需要寫入的視頻ID更新到該布隆過濾器，最后再寫回到磁盤KV，這樣的話，寫入磁盤KV后就有可能存在數(shù)據(jù)丟失。

第二，最后一個N分鐘的數(shù)據(jù)需要等到用戶下次再使用的時候才能通過播放埋點觸發(fā)寫入磁盤KV，如果有大量不活躍的用戶，那么就會存在大量暫存數(shù)據(jù)遺留在Redis中占用空間。此時，如果再采用定時任務(wù)來將這部分?jǐn)?shù)據(jù)寫入到磁盤KV，那么也會很容易出現(xiàn)第一種場景中的并發(fā)寫數(shù)據(jù)丟失問題。

如此看來，近實時寫入方案雖然出發(fā)點很直接，但是仔細(xì)想來，越來越復(fù)雜，只能另尋其他方案。

3.2.2 批量寫入

既然近實時寫入方案復(fù)雜，那不妨考慮簡單的方案，通過定時任務(wù)批量將暫存的數(shù)據(jù)寫入到磁盤KV中。我們將待寫的數(shù)據(jù)標(biāo)記出來，假設(shè)我們每小時寫入一次，那么我們就可以把暫存數(shù)據(jù)以小時值標(biāo)記。但是，考慮到定時任務(wù)難免可能會執(zhí)行失敗，我們需要有補(bǔ)償措施，常見的方案是每次執(zhí)行任務(wù)的時候，都在往前多1~2個小時的數(shù)據(jù)上執(zhí)行任務(wù)，以作補(bǔ)償。但是，明顯這樣的方案并不夠優(yōu)雅，我們從時間輪得到啟發(fā)，并基于此設(shè)計了布隆過濾器批量寫入的方案。

我們將小時值首尾相連，從而得到一個環(huán)，并且將對應(yīng)的數(shù)據(jù)存在該小時值標(biāo)識的地方，那么同一小時值（比如每天11點）的數(shù)據(jù)是存在一起的，如果今天的數(shù)據(jù)因任務(wù)未執(zhí)行或執(zhí)行失敗未同步到磁盤KV，那么在第二天將會得到一次補(bǔ)償。

順著這個思路，我們可以將小時值對某個值取模以進(jìn)一步縮短兩次補(bǔ)償?shù)臅r間間隔，比如圖5所示對8取模，可見1:00~2:00和9:00~10:00的數(shù)據(jù)都會落在圖中時間環(huán)上的點1標(biāo)識的待寫入數(shù)據(jù)，過8個小時將會得到一次補(bǔ)償?shù)臋C(jī)會，也就是說這個取模的值就是補(bǔ)償?shù)臅r間間隔。

（圖5：批量寫入方案）

那么，我們應(yīng)該將補(bǔ)償時間間隔設(shè)置為多少呢？這是一個值得思考的問題，這個值的選取會影響到待寫入數(shù)據(jù)在環(huán)上的分布。我們的業(yè)務(wù)一般都會有忙時、閑時，忙時的數(shù)據(jù)量會更大，根據(jù)短視頻忙閑時特點，最終我們將補(bǔ)償間隔設(shè)置為6，這樣業(yè)務(wù)忙時比較均勻地落在環(huán)上的各個點。

確定了補(bǔ)償時間間隔以后，我們覺得6個小時補(bǔ)償還是太長了，因為用戶在6個小時內(nèi)有可能會看過大量的視頻，如果不及時將數(shù)據(jù)同步到磁盤KV，會占用大量Redis內(nèi)存，而且我們使用Redis ZSet暫存用戶播放記錄，過長的話會嚴(yán)重影響性能。于是，我們設(shè)計每個小時增加一次定時任務(wù)，第二次任務(wù)對第一次任務(wù)補(bǔ)償，如果第二次任務(wù)仍然沒有補(bǔ)償成功，那么經(jīng)過一圈以后，還可以得到再次補(bǔ)償（兜底）。

細(xì)心一點應(yīng)該會發(fā)現(xiàn)在圖5中的“待寫入數(shù)據(jù)”和定時任務(wù)并不是分布在環(huán)上的同一個點的，我們這樣設(shè)計的考慮是希望方案更簡單，定時任務(wù)只會去操作已經(jīng)不再變化的數(shù)據(jù)，這樣就能避免并發(fā)操作問題。就像Java虛擬機(jī)中垃圾回收一樣，我們不能一邊回收垃圾，一邊卻還在同一間屋子里扔著垃圾。所以，設(shè)計成環(huán)上節(jié)點對應(yīng)定時任務(wù)只去處理前一個節(jié)點上的數(shù)據(jù)，以確保不會產(chǎn)生并發(fā)沖突，使方案保持簡單。

批量寫入方案簡單且不存在并發(fā)問題，但是在Redis Zset需要保存一個小時的數(shù)據(jù)，可能會超過最大長度，但是考慮到現(xiàn)實中一般用戶一小時內(nèi)不會播放非常大量的視頻，這一點是可以接受的。最終，我們選擇了批量寫入方案，其簡單、優(yōu)雅、高效，在此基礎(chǔ)上，我們需要繼續(xù)設(shè)計暫存大量用戶的播放視頻ID方案。

3.3 數(shù)據(jù)分片

為了支持5000萬日活量級，我們需要為定時批量寫入方案設(shè)計對應(yīng)的數(shù)據(jù)存儲分片方式。首先，我們依然需要將播放視頻列表存放在Redis Zset，因為在沒寫入布隆過濾器之前，我們需要用這份數(shù)據(jù)過濾用戶已觀看過的視頻。正如前文提到過，我們會暫存一個小時的數(shù)據(jù)，正常一個用戶一個小時內(nèi)不會播放超過一萬條數(shù)據(jù)的，所以一般來說是沒有問題的。除了視頻ID本身以外，我們還需要保存這個小時到底有哪些用戶產(chǎn)生過播放數(shù)據(jù)，否則定時任務(wù)不知道要將哪些用戶的播放記錄寫入布隆過濾器，存儲5000萬用戶的話就需要進(jìn)行數(shù)據(jù)分片。

結(jié)合批量同步部分介紹的時間環(huán)，我們設(shè)計了如圖6所示的數(shù)據(jù)分片方案，將5000萬的用戶Hash到5000個Set中，這樣每個Set最多保存1萬個用戶ID，不至于影響Set的性能。同時，時間環(huán)上的每個節(jié)點都按照這個的分片方式保存數(shù)據(jù)，將其展開就如同圖6下半部分所示，以played:user:${時間節(jié)點編號}:${用戶Hash值}為Key保存某個時間節(jié)點某個分片下所有產(chǎn)生了播放數(shù)據(jù)的用戶ID。

（圖6：數(shù)據(jù)分片方案）

對應(yīng)地，我們的定時任務(wù)也要進(jìn)行分片，每個任務(wù)分片負(fù)責(zé)處理一定數(shù)目的數(shù)據(jù)分片。否則，如果兩者一一對應(yīng)的話，將分布式定時任務(wù)分成5000個分片，雖然對于失敗重試是更好的，但是對于任務(wù)調(diào)度來說會存在壓力，實際上公司的定時任務(wù)也不支持5000分分片。我們將定時任務(wù)分為了50個分片，任務(wù)分片0負(fù)責(zé)處理數(shù)據(jù)分片0~100，任務(wù)分片1負(fù)責(zé)處理數(shù)據(jù)分片100~199，以此類推。

3.4 數(shù)據(jù)淘汰

對于短視頻推薦去重業(yè)務(wù)場景，我們一般保證讓用戶在看過某條視頻后三個月內(nèi)不會再向該用戶推薦這條視頻，因此就涉及到過期數(shù)據(jù)淘汰問題。布隆過濾器不支持刪除操作，因此我們將用戶的播放歷史記錄添加到布隆過濾器以后，按月存儲并設(shè)置相應(yīng)的過期時間，如圖7所示，目前過期時間設(shè)置為6個月。在數(shù)據(jù)讀取的時候，根據(jù)當(dāng)前時間選擇讀取最近4個月數(shù)據(jù)用于去重。之所以需要讀取4個月的數(shù)據(jù)，是因為當(dāng)月數(shù)據(jù)未滿一個月，為了保證三個月內(nèi)不會再向用戶重復(fù)推薦，需要讀取三個完整月和當(dāng)月數(shù)據(jù)。

（圖7：數(shù)據(jù)淘汰方案）

對于數(shù)據(jù)過期時間的設(shè)置我們也進(jìn)行了精心考慮，數(shù)據(jù)按月存儲，因此新數(shù)據(jù)產(chǎn)生時間一般在月初，如果僅將過期時間設(shè)置為6個月以后，那么會造成月初不僅產(chǎn)生大量新數(shù)據(jù)，也需要淘汰大量老數(shù)據(jù)，對數(shù)據(jù)庫系統(tǒng)造成壓力。所以，我們將過期時間進(jìn)行了打散，首先隨機(jī)到6個月后的那個月任意一天，其次我們將過期時間設(shè)置在業(yè)務(wù)閑時，比如：00:00~05:00，以此來降低數(shù)據(jù)庫清理時對系統(tǒng)的壓力。

3.5 方案小結(jié)

通過綜合上述流量匯聚、數(shù)據(jù)分片和數(shù)據(jù)淘汰三部分設(shè)計方案，整體的設(shè)計方案如圖8所示，從左至右播放埋點數(shù)據(jù)依次從數(shù)據(jù)源Kafka流向Redis暫存，最終流向磁盤KV持久化。

（圖8：整體方案流程）

首先，從Kafka播放埋點監(jiān)聽到數(shù)據(jù)以后，我們根據(jù)用戶ID將該條視頻追加到用戶對應(yīng)的播放歷史中暫存，同時根據(jù)當(dāng)前時間和用戶ID的Hash值確定對應(yīng)時間環(huán)，并將用戶ID保存到該時間環(huán)對應(yīng)的用戶列表中。然后，每個分布式定時任務(wù)分片去獲取上一個時間環(huán)的播放用戶數(shù)據(jù)分片，再獲取用戶的播放記錄更新到讀出的布隆過濾器，最后將布隆顧慮其序列化后寫入磁盤KV中。

四、數(shù)據(jù)遷移

為了實現(xiàn)從當(dāng)前基于Redis ZSet去重平滑遷移到基于布隆過濾器去重，我們需要將統(tǒng)一去重服務(wù)上線前用戶產(chǎn)生的播放記錄遷移過來，以保證用戶體驗不受影響，我們設(shè)計和嘗試了兩種方案，經(jīng)過對比和改進(jìn)形成了最終方案。

我們已經(jīng)實現(xiàn)了批量將播放記錄原始數(shù)據(jù)生成布隆過濾器存儲到磁盤KV中，因此，遷移方案只需要考慮將存儲在原來Redis中的歷史數(shù)據(jù)（去重服務(wù)上線前產(chǎn)生）遷移到新的Redis中即可，接下來就交由定時任務(wù)完成即可，方案如圖9所示。用戶在統(tǒng)一去重服務(wù)上線后新產(chǎn)生的增量數(shù)據(jù)通過監(jiān)聽播放埋點寫入，新老數(shù)據(jù)雙寫，以便需要時可以降級。

（圖9：遷移方案一）

但是，我們忽略了兩個問題：第一，新的Redis僅用作暫存，因此比老的Redis容量小很多，沒法一次性將數(shù)據(jù)遷移過去，需要分多批遷移；第二，遷移到新的Redis后的存儲格式和老的Redis不一樣，除了播放視頻列表，還需要播放用戶列表，咨詢DBA得知這樣遷移比較難實現(xiàn)。

既然遷移數(shù)據(jù)比較麻煩，我們就考慮能不能不遷移數(shù)據(jù)呢，在去重的時候判斷該用戶是否已遷移，如未遷移則同時讀取一份老數(shù)據(jù)一起用于去重過濾，并觸發(fā)將該用戶的老數(shù)據(jù)遷移到新Redis（含寫入播放用戶列表），三個月以后，老數(shù)據(jù)已可過期淘汰，此時就完成了數(shù)據(jù)遷移，如圖10所示。這個遷移方案解決了新老Redis數(shù)據(jù)格式不一致遷移難的問題，而且是用戶請求時觸發(fā)遷移，也避免了一次性遷移數(shù)據(jù)對新Redis容量要求，同時還可以做到精確遷移，僅遷移了三個月內(nèi)需要遷移數(shù)據(jù)的用戶。

（圖10：遷移方案二）

于是，我們按照方案二進(jìn)行了數(shù)據(jù)遷移，在上線測試的時候，發(fā)現(xiàn)由于用戶首次請求的時候需要去遷移老的數(shù)據(jù)，造成去重接口耗時不穩(wěn)定，而視頻去重作為視頻推薦重要環(huán)節(jié)，對于耗時比較敏感，所以就不得不繼續(xù)思考新的遷移方案。我們注意到，在定時批量生成布隆過濾器的時候，讀取到時間環(huán)對應(yīng)的播放用戶列表后，根據(jù)用戶ID獲取播放視頻列表，然后生成布隆過濾器保存到磁盤KV，此時，我們只需要增加一個從老Redis讀取用戶的歷史播放記錄即可把歷史數(shù)據(jù)遷移過來。為了觸發(fā)將某個用戶的播放記錄生成布隆過濾器的過程，我們需要將用戶ID保存到時間環(huán)上對應(yīng)的播放用戶列表，最終方案如圖11所示。

（圖11：最終遷移方案）

首先，DBA幫助我們把老Redis中播放記錄的Key（含有用戶ID）都掃描出來，通過文件導(dǎo)出；然后，我們通過大數(shù)據(jù)平臺將導(dǎo)出的文件導(dǎo)入到Kafka，啟用消費者監(jiān)聽并消費文件中的數(shù)據(jù)，解析后將其寫入到當(dāng)前時間環(huán)對應(yīng)的播放用戶列表。接下來，分布式批量任務(wù)在讀取到播放用戶列表中的某個用戶后，如果該用戶未遷移數(shù)據(jù)，則從老Redis讀取歷史播放記錄，并和新的播放記錄一起更新到布隆過濾器并存入磁盤KV。

五、小結(jié)

本文主要介紹短視頻基于布隆過濾器構(gòu)建推薦去重服務(wù)的設(shè)計與思考，從問題出發(fā)逐步設(shè)計和優(yōu)化方案，力求簡單、完美、優(yōu)雅，希望能對讀者有參考和借鑒價值。由于文章篇幅有限，有些方面未涉及，也有很多技術(shù)細(xì)節(jié)未詳細(xì)闡述，如有疑問歡迎繼續(xù)交流。