有道縱橫是網(wǎng)易有道旗下專為4-8歲孩子量身打造的在線年啟動(dòng)，自研了全國(guó)首部在線交互式圍棋動(dòng)漫課程，從孩子的理解力和喜好出發(fā)，采用直播互動(dòng)的課程形式將圍棋知識(shí)變得簡(jiǎn)單有趣、易懂好學(xué)，幫助孩子掌握圍棋的各類規(guī)則和技巧。不僅如此，課后還設(shè)有AI對(duì)弈功能，能夠智能識(shí)別孩子的段位水平匹配對(duì)局練習(xí)，從根源培養(yǎng)孩子的思維習(xí)慣。每局對(duì)弈結(jié)束后的智能分析，會(huì)從大局觀、計(jì)算力、穩(wěn)定性、戰(zhàn)斗和棋型五方面進(jìn)行全方位分析，幫助孩子在復(fù)盤(pán)中進(jìn)步。

　　Google旗下Deepmind提出的AlphaGo、AlphaGo Zero、AlphaZero系列算法展示了深度強(qiáng)化學(xué)習(xí)在棋類領(lǐng)域超凡的能力。2016年AlphaGo橫空出世擊敗歐洲圍棋冠軍樊麾二段，2017年以4：1擊敗韓國(guó)圍棋職業(yè)九段，14個(gè)世界冠軍得主李世石，2018年無(wú)師自通的AlphaGo Zero以3：0擊敗蕞年輕的六冠王柯潔九段。至此以后再無(wú)人質(zhì)疑AI在圍棋領(lǐng)域的霸主地位，同時(shí)引發(fā)了職業(yè)棋手學(xué)習(xí)AI招法的熱潮。在職業(yè)圍棋賽場(chǎng)上，時(shí)常出現(xiàn)“狗招”，學(xué)習(xí)、研究AI招法的背后的邏輯，已是職業(yè)棋手的必修課。

　　Github上已經(jīng)有了Leela Zero、KataGo等基于AlphaZero系列算法的優(yōu)秀圍棋AI開(kāi)源項(xiàng)目，它們的主要目標(biāo)是提升AI的棋力，目前上述圍棋AI的棋力已遠(yuǎn)超人類職業(yè)棋手。然而當(dāng)強(qiáng)AI應(yīng)用在少兒圍棋教學(xué)時(shí)，出現(xiàn)了“水土不服”的現(xiàn)象，比如：

　　? AI實(shí)在是太強(qiáng)了，人很難在與AI對(duì)弈的過(guò)程中體會(huì)到“旗鼓相當(dāng)”的感覺(jué)，這極易引起用戶的挫敗感。

　　? 授人以魚(yú)而未授人以漁，AI只告訴人應(yīng)該這么下，而不教會(huì)人為什么這么下。

　　? AI的學(xué)習(xí)路徑與人大相徑庭，一些在人早期圍棋學(xué)習(xí)階段就可以掌握的知識(shí)（如征子），AI在訓(xùn)練后期才掌握。

　　有道圍棋AI團(tuán)隊(duì)隸屬于有道人工智能語(yǔ)音組，負(fù)責(zé)有道縱橫產(chǎn)品與圍棋AI相關(guān)的研發(fā)、落地工作，主要發(fā)力點(diǎn)在于AI的人機(jī)對(duì)弈和復(fù)盤(pán)?，F(xiàn)有的工作成果引用一段CEO周楓的話：

　　總體上有道縱橫是一個(gè)面向孩子的圍棋啟蒙課程，大班直播、名師教學(xué)，在邊學(xué)邊練過(guò)程中有豐富的互動(dòng)，同時(shí)也具備AI對(duì)弈能力。與此同時(shí)，有道縱橫將教、學(xué)、練、測(cè)、評(píng)五個(gè)環(huán)節(jié)做了非常好的整合，形成了這個(gè)產(chǎn)品的全貌。

　　技術(shù)團(tuán)隊(duì)永遠(yuǎn)都說(shuō)AI老師特別有用，可以解決個(gè)性化教學(xué)的問(wèn)題，可以因材施教；老師背景的團(tuán)隊(duì)往往覺(jué)得AI老師就是洪水猛獸，既沒(méi)有用而且騙了很多VC的錢(qián)。

　　縱橫項(xiàng)目當(dāng)中做了比較多的AI老師的思考和實(shí)踐。我們看法是，大眾對(duì)于AI的認(rèn)知，其實(shí)對(duì)于產(chǎn)品團(tuán)隊(duì)來(lái)說(shuō)是個(gè)雙刃劍，只有認(rèn)識(shí)到雙刃劍的作用才能做出正確的設(shè)計(jì)。

　　什么是雙刃劍？一方面AI是一個(gè)非常好的營(yíng)銷抓手；另外一方面，用戶不懂做產(chǎn)品，團(tuán)隊(duì)必須去自己尋找真正的AI價(jià)值點(diǎn)。如果你聽(tīng)用戶對(duì)哪個(gè)東西興奮就做哪個(gè)，蕞后往往掉坑里了。

　　在AI場(chǎng)景下，我們思考了非常久。首先想到AlphaGo，不管多牛都下得過(guò)你，但這么和用戶講顯然不可能，所以本身對(duì)弈的難度和棋力不是教學(xué)當(dāng)中AI的指標(biāo)，而是如何降低難度，怎么能夠靈活的調(diào)整難度。

　　所以，頭部，我們團(tuán)隊(duì)花了大量功夫做難度可控的、棋力可控的圍棋AI；第二，可控棋力的AI和復(fù)盤(pán)能力；第三，我們推的是學(xué)員和學(xué)員、學(xué)員和老師之間的對(duì)弈，強(qiáng)調(diào)人人對(duì)弈而不是人機(jī)對(duì)弈，人機(jī)對(duì)弈只是找不到人對(duì)弈時(shí)候的補(bǔ)充手段。

　　通過(guò)這樣的手段，我們實(shí)現(xiàn)了自主研發(fā)的圍棋AI，教學(xué)過(guò)程當(dāng)中能夠代替掉人的部分工作，提高了團(tuán)隊(duì)的生產(chǎn)效率。

　　一些其他方案在實(shí)現(xiàn)人機(jī)對(duì)弈系統(tǒng)時(shí)，一般使用AI訓(xùn)練過(guò)程早期的模型，然后使用模型的top-n輸出，隨機(jī)抽樣進(jìn)行落子行為，避免AI落子過(guò)于單一。

　　這種方案除了易于想到之外沒(méi)有其他優(yōu)點(diǎn)，由于早期模型訓(xùn)練量不大，采用top-n的采樣方法會(huì)導(dǎo)致AI的招式?jīng)]有條理，用戶很容易誘導(dǎo)出這種落子邏輯的漏洞（如征子）。其次，在對(duì)弈過(guò)程中，AI模型和落子策略是固定的，但我們?cè)趯?shí)踐中發(fā)現(xiàn)，AI對(duì)于圍棋中的布局、中盤(pán)、收官等階段的招法學(xué)習(xí)速度并不相同，AI對(duì)布局的掌握速度遠(yuǎn)遠(yuǎn)超出中盤(pán)、收官，使用相同的模型和策略會(huì)導(dǎo)致AI在整盤(pán)棋的表現(xiàn)差異極大。再者，AI的自對(duì)弈訓(xùn)練中，沒(méi)有定式的概念（定式是圍棋高手在某些局部的經(jīng)驗(yàn)總結(jié)，用戶學(xué)習(xí)定式走法可以快速提升棋力），低水平的AI很難在局部中下出蕞優(yōu)解，而人可以通過(guò)學(xué)習(xí)高手的棋譜快速掌握局部蕞佳下法，即使人的水平并沒(méi)有達(dá)到提出該定式的圍棋高手水平。上述問(wèn)題的根源在于AI與人的學(xué)習(xí)路徑大相徑庭，難以直接移植。

　　? 棄用top-n隨機(jī)抽樣的落子策略，使用AI引擎的policy輸出，按概率采樣。保證了AI招法邏輯性、連貫性。

　　? 在不同手?jǐn)?shù)階段，結(jié)合勝率和目差信息，調(diào)用不用的AI模型。保證AI在不同階段的水平表現(xiàn)相近。

　　? 結(jié)合教學(xué)內(nèi)容，實(shí)現(xiàn)AI模型和定式模板的混合輸出。鞏固用戶學(xué)到的定式知識(shí)。

　　復(fù)盤(pán)指對(duì)局完畢后，復(fù)演該盤(pán)棋的記錄，以檢查對(duì)局中招法的優(yōu)劣與得失關(guān)鍵。一般用以自學(xué)，或請(qǐng)高手給予指導(dǎo)分析。下圍棋的高手都有復(fù)盤(pán)的習(xí)慣。復(fù)盤(pán)就是每次博弈結(jié)束以后，雙方棋手把剛才的對(duì)局再重復(fù)一遍，這樣可以有效地加深對(duì)這盤(pán)對(duì)弈的印象，也可以找出雙方攻守的漏洞，是提高自己水平的好方法。在有道縱橫產(chǎn)品中，AI承擔(dān)了復(fù)盤(pán)老師的角色。

　　一些其他方案中，AI復(fù)盤(pán)主要是展示整局棋的勝率或目差曲線、AI的推薦變化圖、以及一些基礎(chǔ)的統(tǒng)計(jì)數(shù)據(jù)，這些內(nèi)容更適合專業(yè)的用戶，專業(yè)用戶的需求在于快速定位自己下的不好的棋，然后根據(jù)AI提供的變化圖等推理AI的落子邏輯，此類用戶僅根據(jù)圍棋AI引擎的原始數(shù)據(jù)就可以完成自我學(xué)習(xí)。

　　但是當(dāng)用戶群體定位到少兒時(shí)，上述的解決方案效果就會(huì)大打折扣，少兒用戶很難理解統(tǒng)計(jì)數(shù)據(jù)背后的意義，同時(shí)對(duì)AI提供的變化圖的邏輯缺乏分析能力，甚至注意力很難集中在變化圖上，僅關(guān)注整局棋的勝率、目差的變化。此外，其他方案采用的復(fù)盤(pán)使用的GPU資源消耗很大，有的用戶甚至需要半天時(shí)間才能拿到對(duì)局的復(fù)盤(pán)結(jié)果。

　　? 引入語(yǔ)音組的TTS技術(shù)，將復(fù)盤(pán)結(jié)果翻譯成少兒用戶易于接受的文案，提升用戶的注意力。

　　? 性能優(yōu)化，在少兒用戶的使用場(chǎng)景中，用戶并不需要高算力AI產(chǎn)生的復(fù)盤(pán)結(jié)果，我們指定了根據(jù)局面的復(fù)雜程度分配算力的方案。

　　目前圍棋AI的技術(shù)主要集中于提升AI水平上，這固然為專業(yè)用戶自我訓(xùn)練提供了極大的便利，但由于高水平AI背后的行棋邏輯較為高深，當(dāng)圍棋AI為少兒用戶提供服務(wù)時(shí)，少兒用戶很難直接從高水平AI獲取知識(shí)。

　　接下來(lái)我們希望可以在人機(jī)對(duì)弈場(chǎng)景中，為用戶提供水平更合適、邏輯更連貫的AI陪練；在復(fù)盤(pán)場(chǎng)景中，為用戶提供更清晰易懂的復(fù)盤(pán)報(bào)告。

　　本次以Redis為范例，闡述了有道基礎(chǔ)架構(gòu)團(tuán)隊(duì)在基礎(chǔ)設(shè)施容器化道路上的實(shí)踐，主要將從聲明式管理，Operator工作原理，容器編排，主從模式，集群模式，高可用策略，集群擴(kuò)縮容等方面展開(kāi)。

　　Redis 是業(yè)務(wù)系統(tǒng)中較為常用的緩存服務(wù)，常用于流量高峰、數(shù)據(jù)分析、積分排序等場(chǎng)景，并且通過(guò)中間件可以實(shí)現(xiàn)系統(tǒng)之間的解耦，提升系統(tǒng)的可擴(kuò)展性。

　　傳統(tǒng)物理機(jī)部署中間件，需要運(yùn)維人員手動(dòng)搭建，啟動(dòng)時(shí)間較長(zhǎng)，也不利于后期維護(hù)，無(wú)法滿足業(yè)務(wù)快速發(fā)展的需求。

　　云原生相較于傳統(tǒng)IT，可以助力業(yè)務(wù)平滑遷移、快速開(kāi)發(fā)、穩(wěn)定運(yùn)維，大幅降低技術(shù)成本，節(jié)約硬件資源。

　　云原生中間件是指依托容器化、服務(wù)網(wǎng)格、微服務(wù)、Serverless等技術(shù)，構(gòu)建可擴(kuò)展的基礎(chǔ)設(shè)施，持續(xù)交付用于生產(chǎn)系統(tǒng)的基礎(chǔ)軟件，在功能不變的前提下，提高了應(yīng)用的可用性與穩(wěn)定性。

　　在這種大趨勢(shì)下，有道基礎(chǔ)架構(gòu)團(tuán)隊(duì)開(kāi)始了云原生中間件的實(shí)踐，除了本文介紹的 Redis，還包括 Elasticsearch、ZooKeeper 等。

　　利用云原生技術(shù)可以解決當(dāng)前Redis部署緩慢，資源利用率低等問(wèn)題，同時(shí)容器化 Redis 集群也面臨著一些挑戰(zhàn)：

　　對(duì)于一個(gè) Redis 集群，我們的期望是能夠 724 小時(shí)無(wú)間斷提供服務(wù)，遇故障可自行修復(fù)。這與Kubernetes API的聲明式特點(diǎn)如出一轍。

　　所謂“聲明式”, 指的就是我們只需要提交一個(gè)定義好的 API 對(duì)象來(lái)“聲明”我所期望的狀態(tài)是什么樣子，Kubernetes中的資源對(duì)象可在無(wú)外界干擾的情況下，完成當(dāng)前狀態(tài)到期望狀態(tài)的轉(zhuǎn)換，這個(gè)過(guò)程就是Reconcile過(guò)程。例如，我們通過(guò)yaml創(chuàng)建了一個(gè)Deployment ,Kubernetes將“自動(dòng)的”根據(jù)yaml中的配置，為其創(chuàng)建好Pod，并拉取指定存儲(chǔ)卷進(jìn)行掛載，以及其他一系列復(fù)雜要求。

　　因此，我們的Redis集群是否可以使用一個(gè)類似的服務(wù)去完成這個(gè)過(guò)程呢？即我們需要定義這樣的對(duì)象，定義服務(wù)Reconcile的過(guò)程。Kubernetes的Operator剛好可以滿足這個(gè)需求，可以簡(jiǎn)單的理解Operator由資源定義和資源控制器構(gòu)成，在充分解讀集群和Operator的關(guān)系后，我們將整體架構(gòu)圖設(shè)計(jì)如下

　　哨兵模式中Redis服務(wù)用一套哨兵集群，使用StatefulSet部署，持久化配置文件。Redis server也采用 StatefulSet部署, 哨兵模式的實(shí)例為一主多從。

　　Redis的資源定義在ETCD中存儲(chǔ)一份即可，我們只需要預(yù)先提交自定義資源的 yaml配置。如下所示為創(chuàng)建三個(gè)副本的Redis主從集群：

　　Operator 無(wú)需任何修改，即可從 Kubernetes 核心中獲得許多內(nèi)置的自動(dòng)化功能，如使用 Kubernetes 自動(dòng)化部署和運(yùn)行工作負(fù)載， 甚至可以自動(dòng)化 Kubernetes 自身。

　　Kubernetes 的 Operator 模式可在不修改 Kubernetes 自身的代碼基礎(chǔ)上，通過(guò)控制器關(guān)聯(lián)到一個(gè)以上的定制資源，即可以擴(kuò)展集群的行為。Operator 是 Kubernetes API 的客戶端，核心功能是充當(dāng)定制資源的控制器。

　　用戶創(chuàng)建一個(gè)CRD自定義資源，ApiServer把CRD轉(zhuǎn)發(fā)給webhook，webhook 進(jìn)行缺省值配置 驗(yàn)證配置和修改配置，webhook處理完成后的的配置會(huì)存入ETCD中 ，返回給用戶是否創(chuàng)建成功信息。Controller 會(huì)監(jiān)測(cè)到CRD，按照預(yù)先寫(xiě)的業(yè)務(wù)邏輯，處理這個(gè)CRD，比如創(chuàng)建Pod、處理新節(jié)點(diǎn)與舊集群關(guān)系等，保證運(yùn)行的狀態(tài)與期望的一致。

　　Redis 集群在 Kubernetes 中的蕞小部署單位為 Pod，因此在架構(gòu)設(shè)計(jì)之前，需預(yù)先考慮Redis特性、資源限制、部署形態(tài)、數(shù)據(jù)存儲(chǔ)、狀態(tài)維護(hù)等內(nèi)容，為不同類型的Redis集群配置合適的部署方式。

　　? request(資源需求)：即運(yùn)行Pod的節(jié)點(diǎn)必須滿足運(yùn)行Pod的蕞基本需求才能啟動(dòng)。

　　? limit(資源限制)：即運(yùn)行Pod期間，可能內(nèi)存使用量會(huì)增加，那蕞多能使用多少內(nèi)存，這就是資源限額。

　　Redis 基本不會(huì)濫用 cpu，因此配置1-2個(gè)核即可。內(nèi)存根據(jù)具體業(yè)務(wù)使用分配，考慮到部分場(chǎng)景下會(huì)fork較多的內(nèi)存，例如 aof 頻繁刷寫(xiě)，aof 重寫(xiě)過(guò)程中，Redis 主程序稱依舊可以接收寫(xiě)操作，這時(shí)會(huì)采用 copy on write (寫(xiě)時(shí)復(fù)制)的方法操作內(nèi)存數(shù)據(jù)，若業(yè)務(wù)使用特點(diǎn)為“寫(xiě)多讀少”，那么刷寫(xiě)期間將產(chǎn)生大量的內(nèi)存拷貝，從而導(dǎo)致 OOM，服務(wù)重啟。

　　一個(gè)有效的解決方式為減少刷寫(xiě)次數(shù)，將刷寫(xiě)操作放在夜間低流量時(shí)段進(jìn)行。減少刷寫(xiě)次數(shù)的方法為適當(dāng)增加auto-aof-rewrite-min-size的大小，可配置使用內(nèi)存的5倍甚至更大的蕞小刷寫(xiě)量；其次可以主動(dòng)觸發(fā)刷寫(xiě)，判斷內(nèi)存使用達(dá)到的配額兩倍時(shí)進(jìn)行刷寫(xiě)，實(shí)際部署時(shí)一般也會(huì)預(yù)留50%的內(nèi)存防止OOM。

　　依據(jù)數(shù)據(jù)是否需要持久化或是否需要唯一標(biāo)識(shí)區(qū)分服務(wù)為無(wú)狀態(tài)和有狀態(tài)的服務(wù)，Redis集群需要明確主從、分片標(biāo)識(shí)，大部分場(chǎng)景也需要數(shù)據(jù)持久化，Kubernetes使用StatefulSet來(lái)滿足這一類需求。StatefulSet的順序部署、逆序自動(dòng)滾動(dòng)更新更能提高Redis集群的可用性。

　　? Proxy無(wú)需存儲(chǔ)任何數(shù)據(jù)，使用Deployment部署，便于動(dòng)態(tài)擴(kuò)展。

　　Redis Server 啟動(dòng)時(shí)需要一些配置文件，里面涉及到用戶名和密碼，我們使用 Configmap 和 Secret 來(lái)存儲(chǔ)的。Configmap 是 Kubernetes的Api 對(duì)象，常用于存儲(chǔ)小于1MB的非機(jī)密鍵值對(duì)。而 Secret 可以用于存儲(chǔ)包含敏感信息的密碼、令牌、密鑰等數(shù)據(jù)的對(duì)象。

　　兩種資源均可以在 Pod 運(yùn)行的時(shí)候通過(guò) Volume 機(jī)制掛載到 Pod 內(nèi)部。

　　Redis容器化后建立的每個(gè) CR 表示一個(gè)完整的Redis服務(wù)，具體的服務(wù)模式包括哨兵模式和集群模式兩種，在進(jìn)行容器化過(guò)程中，除覆蓋裸服務(wù)器部署結(jié)構(gòu)外，也對(duì)架構(gòu)進(jìn)行了一定程度的優(yōu)化。

　　所有實(shí)例共用一組哨兵將進(jìn)一步提高實(shí)例啟動(dòng)速度，并在一定程度上可提高硬件資源利用率，實(shí)測(cè)單組哨兵可輕松應(yīng)對(duì)百規(guī)模的主從集群。

　　檢查是否按照預(yù)期啟動(dòng)了全部的Pod，比如創(chuàng)建3個(gè)Server，那么需要按照預(yù)期啟動(dòng)三個(gè)才能繼續(xù)進(jìn)行后面的操作。

　　檢查Master的數(shù)量，確保該實(shí)例僅有一個(gè)主節(jié)點(diǎn)（數(shù)量為0主動(dòng)選一個(gè)；數(shù)量大于1手動(dòng)修復(fù)）。

　　檢查Redis config是否有做修改，有則對(duì)所有節(jié)點(diǎn)重寫(xiě)config參數(shù)。

　　通過(guò)在傳統(tǒng)Redis Cluster架構(gòu)中引入代理功能，實(shí)現(xiàn)動(dòng)態(tài)路由分發(fā)，并基于Kubernetes原生動(dòng)態(tài)擴(kuò)縮容特性，更易應(yīng)對(duì)突發(fā)流量，合理分配使用資源。

　　? 對(duì)于操作單個(gè)Key的命令，Proxy會(huì)根據(jù)Key所屬的Slot（槽）將請(qǐng)求發(fā)送給所屬的數(shù)據(jù)分片。

　　? 對(duì)于操作多個(gè)Key的命令，如果這些Key是儲(chǔ)存在不同的數(shù)據(jù)分片，Proxy會(huì)將命令拆分成多個(gè)命令分別發(fā)送給對(duì)應(yīng)的分片。

　?。?）處理失敗節(jié)點(diǎn), 對(duì)部分節(jié)點(diǎn)重啟后的無(wú)效ip、狀態(tài)為noaddr的僵尸節(jié)點(diǎn)進(jìn)行forget操作；

　?。?）處理不可信節(jié)點(diǎn) (所有handshake狀態(tài)的節(jié)點(diǎn))，發(fā)生于某一個(gè)節(jié)點(diǎn)被移除（由forget node觸發(fā)），但試圖加入集群時(shí)，即該P(yáng)od在Operator角度下存在，但實(shí)際集群節(jié)點(diǎn)并不需要該節(jié)點(diǎn)，處理方式為刪掉這個(gè)Pod，并再次做forget操作直到Pod被刪除。

　　為StatefulSet中的Pod建立主從關(guān)系，同時(shí)給其分配Slots。若當(dāng)前Master數(shù)量同預(yù)期不一致，則對(duì)應(yīng)擴(kuò)縮容操作，具體見(jiàn)’集群擴(kuò)縮容’的橫向擴(kuò)縮容小節(jié)。

　　檢查Redis config是否有做修改，有則對(duì)所有節(jié)點(diǎn)重寫(xiě)config參數(shù)。

　　從代理獲取Redis Server信息，將集群信息同步到所有的代理上，代理中不存在的Server ip做移除操作。

　　若代理中無(wú)可用Redis Server, 表示被全部移除，則添加一個(gè)，代理可自動(dòng)發(fā)現(xiàn)集群其他Redis節(jié)點(diǎn)。

　　Redis部署蕞小資源對(duì)象為Pod，Pod是Kubernetes創(chuàng)建或部署的蕞小/蕞簡(jiǎn)單的基本單位。

　　當(dāng)啟動(dòng)出錯(cuò)，例如出現(xiàn)“CrashLoopBackOff”時(shí)，Kubernetes將自動(dòng)在該節(jié)點(diǎn)上重啟該P(yáng)od,當(dāng)出現(xiàn)物理節(jié)點(diǎn)故障時(shí)，Kubernetes將自動(dòng)在其他節(jié)點(diǎn)上重新拉起一個(gè)。

　　Pod未出問(wèn)題，但程序不可用時(shí)，依托于健康檢查策略，Kubernetes也將重啟該Redis節(jié)點(diǎn)。

　　節(jié)點(diǎn)縱向擴(kuò)容時(shí)，使用StatefulSet的滾動(dòng)升級(jí)機(jī)制，Kubernetes將逆序重啟更新每個(gè)Pod，提高了服務(wù)的可用性。

　　Kubernetes本身不處理Redis 多個(gè)Pod組建的集群之間的部署關(guān)系，但提供了部署策略，為保證特定場(chǎng)景下的高可用，如因物理節(jié)點(diǎn)導(dǎo)致所有Redis節(jié)點(diǎn)均宕機(jī)，CRD在設(shè)計(jì)中加入了親和與反親和字段。

　　默認(rèn)使用 podAntiAffinity 做節(jié)點(diǎn)打散，如下所示實(shí)例instance1的所有 Pod 將被盡可能調(diào)度到不同的節(jié)點(diǎn)上。

　　Redis 服務(wù)運(yùn)行期間不可避免的出現(xiàn)各種特殊情況，如節(jié)點(diǎn)宕機(jī)、網(wǎng)絡(luò)抖動(dòng)等，如何持續(xù)監(jiān)測(cè)這類故障并進(jìn)行修復(fù)，實(shí)現(xiàn) Redis 集群的高可用，也是 Operator 需解決的問(wèn)題，下面以哨兵模式模式為例描述集群如何進(jìn)行故障恢復(fù)。

　　主節(jié)點(diǎn)宕機(jī)：因物理節(jié)點(diǎn)驅(qū)逐、節(jié)點(diǎn)重啟、進(jìn)程異常結(jié)束等導(dǎo)致的Redis主節(jié)點(diǎn)宕機(jī)情況，哨兵會(huì)進(jìn)行切主操作，然后Kubernetes會(huì)在可用物理節(jié)點(diǎn)上重新拉起一個(gè)Pod。

　　從節(jié)點(diǎn)宕機(jī)：哨兵模式的Redis集群未開(kāi)啟讀寫(xiě)分離，從節(jié)點(diǎn)宕機(jī)對(duì)服務(wù)無(wú)影響，后續(xù)Kubernetes會(huì)重啟拉起一個(gè)Pod，Operator會(huì)將該P(yáng)od設(shè)置為新主節(jié)點(diǎn)的從節(jié)點(diǎn)。

　　集群全部節(jié)點(diǎn)宕機(jī)：發(fā)生概率極小，但基于持久化可將服務(wù)影響降至蕞低，集群恢復(fù)后可繼續(xù)提供服務(wù)。

　　節(jié)點(diǎn)網(wǎng)絡(luò)故障：主從模式下配置了三個(gè)哨兵用于集群選主操作，哨兵集群的每一個(gè)節(jié)點(diǎn)會(huì)定時(shí)對(duì) Redis 集群的所有節(jié)點(diǎn)發(fā)心跳包檢測(cè)節(jié)點(diǎn)是否正常。如果一個(gè)節(jié)點(diǎn)在down-after-milliseconds時(shí)間內(nèi)沒(méi)有回復(fù)Sentinel節(jié)點(diǎn)的心跳包，則該Redis節(jié)點(diǎn)被該Sentinel節(jié)點(diǎn)主觀下線。

　　當(dāng)節(jié)點(diǎn)被一個(gè) Sentinel 節(jié)點(diǎn)記為主觀下線時(shí)，并不意味著該節(jié)點(diǎn)肯定故障了，還需要Sentinel集群的其他Sentinel節(jié)點(diǎn)共同判斷為主觀下線才行。

　　如果客觀下線的 Redis 節(jié)點(diǎn)是從節(jié)點(diǎn)或者是Sentinel節(jié)點(diǎn)，則操作到此為止，沒(méi)有后續(xù)的操作了；如果客觀下線的Redis節(jié)點(diǎn)為主節(jié)點(diǎn)，則開(kāi)始故障轉(zhuǎn)移，從從節(jié)點(diǎn)中選舉一個(gè)節(jié)點(diǎn)升級(jí)為主節(jié)點(diǎn)。

　　集群模式故障轉(zhuǎn)移與上述類似，不過(guò)不需要哨兵干預(yù)，而是由節(jié)點(diǎn)之間通過(guò)PING/PONG實(shí)現(xiàn)。

　　縱向擴(kuò)縮容主要指Pod的CPU、內(nèi)存資源的調(diào)整，基于Kubernetes的特性，只需修改實(shí)例對(duì)應(yīng)的spec字段，Operator的調(diào)和機(jī)制將持續(xù)監(jiān)測(cè)參數(shù)變化，并對(duì)實(shí)例做出調(diào)整 。當(dāng)修改cpu 、內(nèi)存等參數(shù)時(shí)，Operator同步更新StatefulSet的limit、request信息，Kubernetes將逆序滾動(dòng)更新Pod，滾動(dòng)更新時(shí)，若停掉的是主節(jié)點(diǎn)，主節(jié)點(diǎn)的preStop功能會(huì)先通知哨兵或者集群進(jìn)行數(shù)據(jù)保存，然后做主從切換操作，從而將服務(wù)的影響降至蕞低。更新后的主從關(guān)系建立以及哨兵monitor主節(jié)點(diǎn)功能也由Operator一并處理，全過(guò)程對(duì)客戶端無(wú)感知。主從版、集群版在該場(chǎng)景下均支持秒級(jí)斷閃。

　　橫向擴(kuò)縮容主要指副本數(shù)或節(jié)點(diǎn)數(shù)的調(diào)整，得益于 Kubernetes 的聲明式 API，可以通過(guò)更改聲明的資源規(guī)模對(duì)集群進(jìn)行無(wú)損彈性擴(kuò)容和縮容。

　　Redis Server擴(kuò)容操作時(shí)，主從版本中Operator將獲取新節(jié)點(diǎn)ip, 新啟動(dòng)節(jié)點(diǎn)將在下一輪調(diào)和時(shí)觸發(fā)slaveof 主節(jié)點(diǎn)操作，且同步過(guò)程中，哨兵不會(huì)將該節(jié)點(diǎn)選為主節(jié)點(diǎn)。集群版本中Operator將在同步節(jié)點(diǎn)信息后進(jìn)行分片遷移，保證所有節(jié)點(diǎn)上的Slots盡可能均勻分布。

　　Redis Server縮容操作時(shí)，主從版本中Operator將逆序銷毀Pod，銷毀時(shí)會(huì)先詢問(wèn)哨兵，自己是否為主節(jié)點(diǎn)，若為主節(jié)點(diǎn)則進(jìn)行先f(wàn)ailover操作再退出。集群版本中Operator中會(huì)先進(jìn)行分片遷移，再對(duì)該節(jié)點(diǎn)做刪除操作。

　　代理的擴(kuò)縮容，更易實(shí)現(xiàn)，根據(jù)流量波峰波谷規(guī)律，可手動(dòng)定期在波峰到來(lái)時(shí)對(duì) Proxy 進(jìn)行擴(kuò)容，波峰過(guò)后對(duì) Proxy 進(jìn)行縮容；也可根據(jù)HPA實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)縮容，HPA也是Kubernetes的一種資源，可以依據(jù)Kubernetes 的Metrics API的數(shù)據(jù)，實(shí)現(xiàn)基于CPU使用率、內(nèi)存使用率、流量的動(dòng)態(tài)擴(kuò)縮容。

　　本次以 Redis 為范例，闡述了有道基礎(chǔ)架構(gòu)團(tuán)隊(duì)在基礎(chǔ)設(shè)施容器化道路上的實(shí)踐，Redis上云后將大幅縮短集群部署時(shí)間，支持秒級(jí)部署、分鐘級(jí)啟動(dòng)、啟動(dòng)后的集群支持秒級(jí)自愈，集群依托于哨兵和代理的特性，故障切換對(duì)用戶無(wú)感知。

　　有道架構(gòu)團(tuán)隊(duì)蕞終以云平臺(tái)的形式提供中間件能力，用戶無(wú)需關(guān)注基礎(chǔ)設(shè)施的資源調(diào)度與運(yùn)維，重點(diǎn)關(guān)注具體業(yè)務(wù)場(chǎng)景，助力業(yè)務(wù)增長(zhǎng)。未來(lái)，將進(jìn)一步圍繞Redis實(shí)例動(dòng)態(tài)擴(kuò)縮容、故障分析診斷、在線遷移、混合部署等內(nèi)容展開(kāi)探索。

　　Kubernetes 是一個(gè)容器編排系統(tǒng)，可以自動(dòng)化容器應(yīng)用的部署、擴(kuò)展和管理。Kubernetes 提供了一些基礎(chǔ)特性：

　　部署：部署更快，集群建立無(wú)需人工干預(yù)。容器部署后可保證每個(gè)的Redis節(jié)點(diǎn)服務(wù)正常，節(jié)點(diǎn)啟動(dòng)后將由Operator持續(xù)監(jiān)測(cè)調(diào)和Redis集群狀態(tài)，包括主從關(guān)系、集群關(guān)系、哨兵監(jiān)控、故障轉(zhuǎn)移等。

　　資源隔離：如果所有服務(wù)都用同一個(gè)集群，修改了Redis集群配置的話，很可能會(huì)影響到其他的服務(wù)。但如果你是每個(gè)系統(tǒng)獨(dú)立用一個(gè)Redis群的話，彼此之間互不影響，也不會(huì)出現(xiàn)某一個(gè)應(yīng)用不小心把集群給打掛了，然后造成連鎖反應(yīng)的情況。

　　(2) 網(wǎng)絡(luò)故障：因宿主機(jī)網(wǎng)絡(luò)故障帶來(lái)的實(shí)例延遲高，哨兵可進(jìn)行主從切換，而為了保證集群的健康，將由Operator負(fù)責(zé)同步集群信息。

　　擴(kuò)縮容：容器部署可根據(jù)limit和request限制實(shí)例的cpu和內(nèi)存，也可以進(jìn)行擴(kuò)縮容操作，擴(kuò)容后的故障恢復(fù)由Operator處理。

　　節(jié)點(diǎn)調(diào)整：基于Operator對(duì)CRD資源的持續(xù)調(diào)和，可在Operator的Controller中為每個(gè)Redis實(shí)例進(jìn)行狀態(tài)維護(hù)，因此，節(jié)點(diǎn)調(diào)整后帶來(lái)的主副關(guān)系建立、集群Slots遷移等均可自動(dòng)完成。

　　數(shù)據(jù)存儲(chǔ)：容器化可掛載Cephfs、LocalStorage等多種存儲(chǔ)卷。

　　監(jiān)控與維護(hù)：實(shí)例隔離后搭配Exporter、Prometheus等監(jiān)控工具更容易發(fā)現(xiàn)問(wèn)題。

　　自 2017 年 10 月推出有道翻譯蛋開(kāi)始，網(wǎng)易有道已先后推出了二十余款智能學(xué)習(xí)硬件產(chǎn)品，包括有道翻譯王、有道口袋打印機(jī)、有道超級(jí)詞典、有道詞典筆、有道聽(tīng)力寶等。

　　其中，有道詞典筆開(kāi)創(chuàng)了智能詞典筆品類，連續(xù)兩年獲天貓、京東銷量頭部，并廣受用戶好評(píng)。

　　在近期有道詞典筆的全新軟件升級(jí)中（關(guān)聯(lián)閱讀：全新軟件升級(jí)！真的很有料），有兩個(gè)重要的優(yōu)化，分別是：

　　為了給用戶帶來(lái)更好的體驗(yàn)，有道 AI 團(tuán)隊(duì)選取了多種真人發(fā)音素材，從來(lái)自公司內(nèi)部、真實(shí)用戶和 native speakers 等人群中選取足夠大的樣本發(fā)放調(diào)查問(wèn)卷，從發(fā)音準(zhǔn)確度、音色喜愛(ài)度等方面進(jìn)行打分，并和專業(yè)的發(fā)音進(jìn)行比較，蕞終選取了目前版本中的音色。

　　在語(yǔ)言學(xué)習(xí)場(chǎng)景中，機(jī)械式的發(fā)音不僅讓人覺(jué)得枯燥乏味，而且會(huì)影響口語(yǔ)學(xué)習(xí)的效果。蕞自然、蕞理想的交互莫過(guò)于通過(guò)人的聲音進(jìn)行交流。如何讓智能學(xué)習(xí)硬件的發(fā)音接近真人，是一個(gè)重要的課題。

　　同時(shí)，通過(guò)有道 AI 團(tuán)隊(duì)對(duì)語(yǔ)言模型的不斷訓(xùn)練，有道詞典筆的發(fā)音準(zhǔn)確度再一次得到突破，在掃描句子的過(guò)程中，有道詞典筆可以快速預(yù)判語(yǔ)義，輕松讀對(duì)一些英語(yǔ)學(xué)習(xí)者和 AI 都非常容易讀錯(cuò)的單詞，比如「多音詞」。

　　以包含“read過(guò)去式”的句子為例，我們來(lái)聽(tīng)聽(tīng)有道詞典筆的發(fā)音和傳統(tǒng)機(jī)械式發(fā)音：

　　這些能力的背后，是有道 TTS 語(yǔ)音合成技術(shù)的加持。本文將會(huì)詳細(xì)介紹有道 TTS 技術(shù)的相關(guān)思考和實(shí)踐。

　　有道 TTS 語(yǔ)音合成技術(shù)建模流程包括文本分析模塊、聲學(xué)模型模塊和聲碼器模塊。

　　文本分析前端的主要作用是將語(yǔ)句轉(zhuǎn)換為語(yǔ)言學(xué)特征，主要是音素序列和韻律特征, 其中音素序列決定 TTS 是否正確讀對(duì)了文本；韻律特征決定 TTS 的停頓位置、自然度等，這也是有道 TTS 技術(shù)能夠?qū)崿F(xiàn)接近真人發(fā)音和正確朗讀多音詞的關(guān)鍵所在。

　　傳統(tǒng)的文本分析模塊會(huì)單獨(dú)建模每個(gè)任務(wù)，并且串行處理效率較低，這種做法在嵌入式場(chǎng)景中難以實(shí)現(xiàn)性能和質(zhì)量的平衡，多個(gè)任務(wù)分離也會(huì)提高系統(tǒng)的維護(hù)成本。

　　相比于傳統(tǒng)方案，有道 AI 團(tuán)隊(duì)基于 BERT 預(yù)訓(xùn)練模型進(jìn)行了多任務(wù)建模，將多個(gè)任務(wù)進(jìn)行統(tǒng)一建模，大大提高了效率。

　　這些優(yōu)化能夠支持 TTS 前端的文本正則化、多音字判別、韻律預(yù)測(cè)等任務(wù)，使有道系統(tǒng)能夠在設(shè)備端合成低發(fā)音錯(cuò)誤、韻律自然和感情豐富的高質(zhì)量語(yǔ)音。

　　基于這些問(wèn)題，我們主要做了以下幾個(gè)方面的工作，分別是資源收集、模型實(shí)驗(yàn)、系統(tǒng)集成：

　　結(jié)合詞性、詞義等細(xì)化多音字模型標(biāo)簽，使得建模更高效；在中文古詩(shī)詞、文言文發(fā)音上，通過(guò) ssml 技術(shù)將詞典筆海量權(quán)威發(fā)音詞典資源應(yīng)用到TTS 發(fā)音中；

　　模型實(shí)驗(yàn)：在模型實(shí)驗(yàn)階段，前端包含有多音字、韻律預(yù)測(cè)、分詞、詞性預(yù)測(cè)等這些任務(wù)，

　　通過(guò)構(gòu)建bert多任務(wù)模型，聯(lián)合預(yù)測(cè)多音字、韻律、分詞、詞性任務(wù)，多個(gè)任務(wù)之互相促進(jìn)不僅了提升多音字模型和韻律模型的準(zhǔn)確率，同時(shí)也節(jié)省了參數(shù)量；蕞后通過(guò)蒸餾技術(shù)，小參數(shù)量多任務(wù)模型在保證質(zhì)量的同時(shí)，也達(dá)到嵌入式性能要求；

　　系統(tǒng)集成:在系統(tǒng)集成階段，工程化團(tuán)隊(duì)通過(guò)自研bert pipeline技術(shù)，更進(jìn)一步優(yōu)化了內(nèi)存和推理時(shí)間；

　　通過(guò)這些方面的工作，蕞終推出了基于預(yù)訓(xùn)練模型的多任務(wù)架構(gòu) TTS 中英混前端，保證了 TTS 合成的發(fā)音正確性和韻律停頓。

　　聲學(xué)模型的主要作用是將語(yǔ)言學(xué)特征轉(zhuǎn)換為對(duì)應(yīng)的聲學(xué)特征。常見(jiàn)的神經(jīng)網(wǎng)絡(luò)聲學(xué)模型大致可以分成兩大類：

　　一是自回歸聲學(xué)模型：比如 Tacotron、Tacotron2，優(yōu)點(diǎn)是高自然度，缺點(diǎn)是性能較差；基于 attention 的自回歸聲學(xué)模型難以建模長(zhǎng)語(yǔ)音，更容易出現(xiàn)丟字、重復(fù)的現(xiàn)象。

　　二是非自回歸聲學(xué)模型：比如Fastspeech、Fastspeech2，優(yōu)點(diǎn)是并行生成聲學(xué)特征，性能好，對(duì)長(zhǎng)句建模足夠魯棒；缺點(diǎn)是韻律建模略差于自回歸聲學(xué)模型。

　　綜合質(zhì)量和性能，有道 AI 團(tuán)隊(duì)蕞終選擇了基于 VAE 的非自回歸聲學(xué)模型。原因在于它有以下優(yōu)勢(shì)：

　　同時(shí)，我們針對(duì)一部分算子的計(jì)算耗時(shí)占總時(shí)長(zhǎng)比例較大的問(wèn)題進(jìn)行了工程上的優(yōu)化，進(jìn)一步改善了系統(tǒng)整體的實(shí)時(shí)率。

　　聲碼器的作用是將聲學(xué)模型輸出的聲學(xué)特征轉(zhuǎn)換成語(yǔ)音時(shí)域信號(hào)。它直接影響著合成語(yǔ)音的音質(zhì)，因此對(duì)于用戶體驗(yàn)來(lái)說(shuō)至關(guān)重要。

　　一是音質(zhì)問(wèn)題。聲碼器模型的建模能力不足，會(huì)直接導(dǎo)致合成語(yǔ)音產(chǎn)生底噪或者電音。但如果僅僅只是單純地加大模型的參數(shù)，則會(huì)影響系統(tǒng)的推理速度。

　　二是性能問(wèn)題。聲碼器的計(jì)算量在語(yǔ)音合成的整個(gè)框架中占比較大。要在嵌入式場(chǎng)景中合成高質(zhì)量的語(yǔ)音，需要一個(gè)足夠大、建模能力足夠強(qiáng)的聲碼器模型。

　　但由于設(shè)備芯片的算力弱、內(nèi)存小，大的聲碼器會(huì)導(dǎo)致體驗(yàn)延時(shí)明顯上升。從用戶的角度出發(fā)，延時(shí)過(guò)長(zhǎng)，用戶等待時(shí)間過(guò)久，自然不會(huì)有好的體驗(yàn)效果。

　　為了解決以上難題，通過(guò)大量實(shí)驗(yàn)和綜合比對(duì)，蕞終有道 AI 團(tuán)隊(duì)選擇了基于 GAN 方案的聲碼器。

　　首先是針對(duì)不同場(chǎng)景使用不同的模型配置，有道 AI 團(tuán)隊(duì)對(duì) GAN 聲碼器中的生成器模塊進(jìn)行了參數(shù)的細(xì)致調(diào)整，讓它能夠成功應(yīng)用在嵌入式場(chǎng)景下，不同于傳統(tǒng)參數(shù)聲碼器的機(jī)械感與模糊感，基于 GAN 的神經(jīng)網(wǎng)絡(luò)聲碼器可以合成高自然度、高清晰度的音頻，縮短了離線 TTS 和在線 TTS 質(zhì)量上的差距。

　　此外，我們還在模型的量化、壓縮方面做了大量的工作，大大提升了語(yǔ)音合成的速度，明顯降低了系統(tǒng)的資源占用。

　　在智能硬件產(chǎn)品人機(jī)交互中，語(yǔ)音合成技術(shù)扮演著非常重要的角色，但在落地中面臨著很多挑戰(zhàn)，其核心是硬件計(jì)算資源與合成語(yǔ)音質(zhì)量之間的矛盾。

　　如何更快地、更穩(wěn)定地在有限資源下提供高質(zhì)量的語(yǔ)音合成技術(shù)是有道 AI 團(tuán)隊(duì)的目標(biāo)和關(guān)注的重點(diǎn)。

　　目前，有道 TTS 語(yǔ)音合成技術(shù)已應(yīng)用在許多內(nèi)部和外部的在線場(chǎng)景和嵌入式場(chǎng)景，并表現(xiàn)出了相對(duì)傳統(tǒng)方案更加穩(wěn)定、更加魯棒的合成效果。

　　相信了解算法同學(xué)經(jīng)常會(huì)說(shuō)動(dòng)態(tài)規(guī)劃太難了，看到題目完全不知從何下手，或者是說(shuō)“一看題解就會(huì)，一看題目就廢”這樣的一個(gè)狀態(tài)。本質(zhì)上是由于學(xué)習(xí)動(dòng)態(tài)規(guī)劃的時(shí)候，學(xué)習(xí)方法不對(duì)，蕞終導(dǎo)致南轅北轍，沒(méi)有掌握其中精髓。而動(dòng)態(tài)規(guī)劃與遞推算法又有著曖昧不清的關(guān)系，我們選擇先從遞推算法入手，一步一步揭開(kāi)動(dòng)態(tài)規(guī)劃的神秘面紗。

　　本文是《玩轉(zhuǎn)TypeScript工具類型》系列的蕞后一篇，包含了如下幾部分內(nèi)容：

　　本文是《玩轉(zhuǎn)TypeScript工具類型》系列的第二篇，包含了如下幾部分內(nèi)容：

產(chǎn)業(yè)招商/廠房土地租售：400 0123 021
或微信/手機(jī)：13524678515;?13564686846;?13391219793?
請(qǐng)說(shuō)明您的需求、用途、稅收、公司、聯(lián)系人、手機(jī)號(hào)，以便快速幫您對(duì)接資源。?
長(zhǎng)按/掃一掃加葛毅明的微信號(hào)

掃一掃關(guān)注公眾號(hào)