文章來源于作者：餓了么物流技術(shù)團(tuán)隊(duì) 在 GitChat 上的分享。
開篇
Elasticsearch，簡稱 ES，目前最火的搜索引擎，底層使用開源庫 Lucene，擁有豐富的 REST API，開箱即用。分布式的數(shù)據(jù)存儲、倒排索引等設(shè)計(jì)，使其可以快速存儲、搜索、分析海量數(shù)據(jù)。
當(dāng)你開始接觸 Elasticsearch 并開始使用到業(yè)務(wù)中時，你會發(fā)現(xiàn)對于 Elasticsearch 我們有太多的東西需要去學(xué)習(xí)，其入門較為簡單，想要深入?yún)s是挺難的。好在 Elasticsearch 本身迭代更新還是挺快的，官網(wǎng)資料也挺詳細(xì)，各種玩法也趨于成熟，所以對于初學(xué)者來說項(xiàng)目接入 Elasticsearch，也不需要過多的擔(dān)心實(shí)現(xiàn)難度問題。
本次分享將會從以下幾點(diǎn)來講解 ES：
ES 安裝
ES 的基本操作
ES 的核心機(jī)制
ES 在傳統(tǒng)數(shù)據(jù)庫無法滿足多種條件花式查詢情況下的大數(shù)據(jù)場景應(yīng)用
一些踩坑經(jīng)歷
本篇文章從 ES 的安裝、操作到 ES 的應(yīng)用，由淺及深，適用于初學(xué) ES 的用戶。由于篇幅原因，本篇文章會盡量講清楚文章的核心知識點(diǎn)，對于文章中有不懂的地方可以隨時交流，希望可以幫助到大家。
ES 安裝
環(huán)境準(zhǔn)備
ES 的安裝環(huán)境很簡單，只需要提前準(zhǔn)備好 Java 環(huán)境（jdk1.8），和 ES 的安裝包即可，jdk1.8 的安裝在此省略，我們直接進(jìn)入 ES 的安裝過程。
下載 ES 安裝包
curl -O -L https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.3.2.tar.gz
解壓文件
tar -zxvf elasticsearch-5.3.2.tar.gz
修改配置文件
#es集群名稱
cluster.name: cluster-es-test
#節(jié)點(diǎn)名稱，另外兩個可以為node-1,node-2
node.name: master-1
#索引數(shù)據(jù)存儲位置，注意給es賬戶授權(quán)
path.data: /usr/local/es/data
#日志文件存儲位置，注意給es賬戶授權(quán)
path.logs: /var/log/es
#綁定的ip地址
network.host: 0.0.0.0
#設(shè)置對外服務(wù)的http端口，默認(rèn)為9200
http.port: 9200
#設(shè)置節(jié)點(diǎn)間交互的tcp端口,默認(rèn)是9300
transport.tcp.port: 9300
#靜態(tài)設(shè)置設(shè)置主機(jī)列表，每個值應(yīng)采用host：port或host的形式（其中port默認(rèn)為設(shè)置transport.profiles.default.port，如果未設(shè)置則返回transport.tcp.port）
discovery.zen.ping.unicast.hosts: ["host1", "host2", "host3:9300"]
#指定該節(jié)點(diǎn)是否有資格被選舉成為master節(jié)點(diǎn)(這里的true，不代表是master節(jié)點(diǎn)，只是有master節(jié)點(diǎn)的選舉資格)
node.master: true
#允許該節(jié)點(diǎn)存儲數(shù)據(jù)(默認(rèn)開啟)
node.data: false
#注意如果需要裝head插件，需要解決跨域問題
http.cors.allow-origin: "*"
創(chuàng)建 ES 用戶
groupadd esg
useradd esu -g esg
chown -R esu:esg /home/es/elasticsearch-5.3.2
調(diào)整 jvm 參數(shù)
vim /home/es/elasticsearch-5.3.2/config/jvm.options
-Xms1g
-Xmx1g
官方建議內(nèi)存設(shè)置低于系統(tǒng)內(nèi)存的一半，不要超過 32G（為什么不要超過 32G 可以翻閱一下資料，這里就不展開了），假如物理機(jī)器有 128G，可以在機(jī)器上面運(yùn)行兩個 ES 實(shí)例。
啟動所有節(jié)點(diǎn)
/home/es/elasticsearch-5.3.2/bin/elasticsearch -d
驗(yàn)證
http://master1:9200
本章小結(jié)
本章主要以 master 節(jié)點(diǎn)來介紹 ES 的安裝過程，數(shù)據(jù)節(jié)點(diǎn)的安裝主要在于配置的不同，啟動的時候可能會有一些失敗情況，注意觀察配置文件目錄里面的日志，在此不做展開，有關(guān)這方面的問題也可以隨時交流。
ES 的基本操作
本篇主要講述 ES 相對于傳統(tǒng)數(shù)據(jù)庫的增刪改查操作。
基本概念介紹及與傳統(tǒng)關(guān)系型數(shù)據(jù)庫類比
拿 MySQL 數(shù)據(jù)庫進(jìn)行對比，數(shù)據(jù)庫相當(dāng)于 ES 中的索引（Indices），數(shù)據(jù)庫中的表相當(dāng)于 ES 中的類型（types），而表中的每一行相當(dāng)于一個類型里面文檔（Documents），而表中的每一列相當(dāng)于文檔中的每個字段（Fields）
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices(數(shù)據(jù)庫)-> Types(表)-> Documents(行)-> Fields(字段)
創(chuàng)建索引
PUT /company?pretty
返回值
{
"acknowledged": true,
"shards_acknowledged": true
}
插入一條數(shù)據(jù)
PUT /company/user/1?pretty #“1” 為es中索引中的_id,在索引中唯一表示一條數(shù)據(jù)
{
"name": "張三",
"age": 12,
"sex": 1
}
返回值
{
"_index": "company",
"_type": "user",
"_id": "1",
"_version": 1,
"result": "created",
"_shards":{
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}
修改數(shù)據(jù)
PUT /company/user/1?pretty
{
"name": "李四", #名稱做修改
"age": 12,
"sex": 1
}
返回值
{
"_index": "company",
"_type": "user",
"_id": "1",
"_version": 2, #版本號變更為2
"result": "updated",
"_shards":{
"total": 2,
"successful": 1,
"failed": 0
},
"created": false
}
可以看到的是文檔的版本號變更為 2， ES 中更新數(shù)據(jù)只能根據(jù)索引中的 _id 來更新數(shù)據(jù)，在其內(nèi)部，其實(shí)是先刪除舊的文檔，再添加新的文檔。
刪除文檔
DELETE /company/user/1?pretty
返回值
{
"found": true,
"_index": "company",
"_type": "user",
"_id": "1",
"_version": 3, #版本號變更為3
"result": "deleted",
"_shards":{
"total": 2,
"successful": 1,
"failed": 0
}
}
查詢數(shù)據(jù)
GET /company/user/1?pretty
返回值
{
"_index": "company",
"_type": "user",
"_id": "1",
"_version": 4, #再次寫入該數(shù)據(jù)后查詢版本號已變更為4
"found": true,
"_source":{
"name": "李四",
"age": 12,
"sex": 1
}
}
Query DSL
DSL：Domain Specified Language，特定領(lǐng)域的語言
http request body：請求體，可以用 json 的格式來構(gòu)建查詢語法，比較方便，可以構(gòu)建各種復(fù)雜的語法，在此不做擴(kuò)展了。
本章小結(jié)
本章主要對于 ES 的增刪改查舉列說明了一下，主要是幫助大家理解 ES 的一些操作，實(shí)際應(yīng)用中，會根據(jù)實(shí)際情況做響應(yīng)的優(yōu)化，每種操作可能不僅僅這樣的簡單，在后面的實(shí)際應(yīng)用中，會有響應(yīng)的例子。
ES 的核心機(jī)制
ES 在面向用戶的時候，操作起來非常簡單，這是因?yàn)?ES 內(nèi)部極力的影藏了其分布式系統(tǒng)復(fù)雜性，下面簡單的介紹 ES 的一些核心機(jī)制。
主備機(jī)制：和其他的分布式系統(tǒng)一樣，ES 也會采取主備機(jī)制來保證一些意外情況下數(shù)據(jù)的完整性，即es中索引的每個分片都會存在主索引和副本索引。當(dāng)然副本索引也能夠提供查詢，也極大的提高了 ES 的吞吐量。
容錯機(jī)制：當(dāng) ES 的 master 節(jié)點(diǎn)丟失的時候（此時集群會變?yōu)榧t色），會從有資格成為主節(jié)點(diǎn)的機(jī)器中選取一個節(jié)點(diǎn)作為新的主節(jié)點(diǎn)（此時集群內(nèi)丟失部分 shard 分片，集群變?yōu)辄S色），之后將丟失主分片的副本分片升級為主分片，再將這些分片 copy 一份到其他的數(shù)據(jù)節(jié)點(diǎn)上（其中可能會因?yàn)閿?shù)據(jù)的不平衡發(fā)生數(shù)據(jù)偏移），之后集群會變?yōu)檎顟B(tài)（綠色）。
并發(fā)控制：通過 version 版本號來做樂觀鎖并發(fā)控制。系統(tǒng)會檢查傳遞給索引請求的版本號是否大于當(dāng)前存儲的文檔的版本，如果大于則重建索引并使用傳入的版本號作為新的 version 值，如果提供的值小于或等于存儲文檔的版本號，則會發(fā)生版本沖突，索引操作將失敗。在類似的問題處理中，最簡單的方法就是使用每次更新數(shù)據(jù)的時間戳來做版本號。
路由機(jī)制：ES 通過路由算法（ shard = hash(routing) % number_of_primary_shards）來確定 document 當(dāng)前屬于哪個分片，默認(rèn)的 routing 值為 document 的 _id，通常我們也會指定別的 Field 來作為 ES 的 routing 值，來提高 ES 查詢的性能，但是可能會引起數(shù)據(jù)的偏移，出現(xiàn)熱節(jié)點(diǎn)現(xiàn)象。所以 routing 值在選取時需要做充分的評估。
ES 在傳統(tǒng)數(shù)據(jù)庫無法滿足多種條件花式查詢情況下的大數(shù)據(jù)場景應(yīng)用
背景
隨著數(shù)據(jù)的增長，傳統(tǒng)的數(shù)據(jù)庫很難支撐現(xiàn)有的業(yè)務(wù)：
各種場景的數(shù)據(jù)查詢、統(tǒng)計(jì)，導(dǎo)致數(shù)據(jù)庫必須加入各種字段的索引，大大增加了核心鏈路插入數(shù)據(jù)所需要的成本，嚴(yán)重影響了核心鏈路的并發(fā)度；大量的索引同時占用了很大的磁盤空間，也給線上 ddl 帶來的更大的風(fēng)險；
很多場景沒有辦法或者很難實(shí)現(xiàn)，如：分頁、排序、分組查詢。大體量數(shù)據(jù)的關(guān)系型數(shù)據(jù)庫設(shè)計(jì)者必然要考慮水平分庫，此時數(shù)據(jù)在這些操作上面將會異常麻煩。此時我們引入了 ES，來處理允許一定延遲的數(shù)據(jù)查詢、統(tǒng)計(jì)的業(yè)務(wù)。
當(dāng)傳統(tǒng)數(shù)據(jù)庫面對這種大體量數(shù)據(jù)查詢而感到無力的時候，我們可以使用 ES 來處理這種業(yè)務(wù)
數(shù)據(jù)存儲
在聊數(shù)據(jù)存儲的時候，我先拋出幾個問題：
如大家所知的那樣，ES 不支持事務(wù)，其會利用 _version (版本號)的方式來確保應(yīng)用中相互沖突的變更不會導(dǎo)致數(shù)據(jù)丟失，那么我們是如何存儲我們的數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)是什么樣子，如何保證數(shù)據(jù)的時效性、完整性和一致性的呢？
數(shù)據(jù)結(jié)構(gòu)
首先需要合適的分片數(shù)和副本數(shù)。目前官方推薦的分片的大小為 20-40G，一般個人會控制在 30G 以內(nèi)，主副本分片數(shù)條件允許的話建議等于節(jié)點(diǎn)數(shù)。
網(wǎng)上有很多關(guān)于如何規(guī)劃分片數(shù)的文章，本人感覺可以作為參考，在機(jī)器性能、數(shù)據(jù)量的大小、使用場景等等的不同，分片數(shù)量最好可以通過壓測或者線上實(shí)際流量來做調(diào)整。
我們會盡量減少我們所需要的字段，做到夠用就好，mapping 設(shè)置方面：設(shè)置"_all"為 false，String 類型"index"盡量設(shè)置為不分詞（"not_analyzed"，根據(jù)需要設(shè)置 analyzed），如商家名稱這類 String 類型字段只存儲索引結(jié)構(gòu)，不存儲原始文檔（后面會聊到如何拿到原始文檔）。
起初我們在建索引的時候，我們是盡量冗余數(shù)據(jù)庫中的所有字段整合成一張寬表，導(dǎo)致每天的索引數(shù)據(jù)量很大，而上面大部分的字段都是不需要的，磁盤利用率很低，而用于該集群的都是 ssd 盤，整體的磁盤容量并不高，常常由于磁盤存不下，而需要添加機(jī)器，導(dǎo)致大量的資源浪費(fèi)。另一方面，盡量的減少我們所需要的字段，這也需要我們支持一個額外的能力，萬一需要添加某個字段的時候，我們需要在需求上線之前迅速將歷史數(shù)據(jù)補(bǔ)齊這個字段，同時不影響線上。（我們現(xiàn)在可以一個晚上重刷我們需要周期內(nèi)的歷史數(shù)據(jù)）。
"mappings": {
"index_type_name": {
"_all": {
"enabled": false
},
"_source": {
"excludes": ["shop_name"] #部分字段只存儲其索引部分，不存儲原始文檔（
},
"properties": {
"order_id": {
"type": "long"
},
"shop_name": {
"type": "string",
"index": "not_analyzed" #提供該字段和關(guān)系型數(shù)據(jù)庫like關(guān)鍵字一樣功能的查詢不需要分詞
}
...
}
}
}
以一天為一個索引（根據(jù)業(yè)務(wù)場景，因?yàn)槲覀兊臉I(yè)務(wù)場景大部分要的都是某天的數(shù)據(jù)），這也為我們根據(jù)實(shí)際線上流量調(diào)整我們分片、副本數(shù)量提供了方便，修改完索引的模板（"_template"）之后，第二天會自動生效，而查詢多天不同數(shù)量分片的索引的聯(lián)合查詢不會影響查詢結(jié)果。
注意：分片數(shù)一旦固定，那么一個已存在的索引是沒有辦法直接修改分片數(shù)，一般會采取 reindex 的方式重建索引.
盡量避免 Nested 數(shù)據(jù)類型。每一個 nested 將會作為一個隱藏的單獨(dú)文本建立索引，雖然官網(wǎng)上說在查詢的時候?qū)⒏谋竞?nested 文檔拼接是很快的，就跟把他們當(dāng)成一個單獨(dú)的文本一樣的快。但是其實(shí)還是有一部分的額外的消耗，尤其是在用 Nested 中的某個字段作為 aggs 聚合的時候。如果真的需要放入數(shù)組類型的數(shù)據(jù)，可以根據(jù)實(shí)際需求，轉(zhuǎn)化為一個字段，直接建在主數(shù)據(jù)上面。
如：我們現(xiàn)在有一個索引，里面有某個學(xué)校每天每個學(xué)生的學(xué)習(xí)、生活情況，每個學(xué)生每天會產(chǎn)生一條數(shù)據(jù)?，F(xiàn)在我們想統(tǒng)計(jì)每個班級某天 中午吃飯時間小于 10 分鐘的人數(shù)、以及一天在校的用餐次數(shù)，我們可以設(shè)計(jì)一個 nested Objects 數(shù)據(jù)結(jié)構(gòu)來存儲一天三餐的用餐情況，也可以在主數(shù)據(jù)上添加四個字段：早上吃飯所花時間，中午所花時間、晚上吃飯所花時間，三餐在校用餐次數(shù)，這樣就可以直接對著這四個字段進(jìn)行數(shù)據(jù)統(tǒng)計(jì)。
盡量減少 script line 的使用。同樣的道理，我們可以預(yù)先將需要用 script line 的中間值先存到主數(shù)據(jù)上面。避免查詢、統(tǒng)計(jì)時候的額外消耗。
數(shù)據(jù)如何存儲
考慮在不影響已有的業(yè)務(wù)情況下，我們采取解析數(shù)據(jù)落庫產(chǎn)生的 binlog 日志來建索引（binlog 日志公司有一套解決方案，不一定非要使用 binlog 日志，業(yè)務(wù)狀態(tài)變更發(fā)送的mq消息也是可以的，另外阿里有開源的 Canal，用來做 binlog 日志解析的），使其與正常業(yè)務(wù)解耦。
此時我們不會直接拿這條數(shù)據(jù)插入 ES，因?yàn)閿?shù)據(jù)的狀態(tài)變化在同一個時刻可能會發(fā)生多次，每次的數(shù)據(jù)插入不一定是數(shù)據(jù)庫當(dāng)前的最新狀態(tài)，而且無論是 binlog 日志、還是狀態(tài)變化 MQ 消息都只是涵蓋了部分?jǐn)?shù)據(jù)，如果要數(shù)據(jù)在發(fā)送 MQ 消息的時候，把建索引所需要的數(shù)據(jù)補(bǔ)齊之后發(fā)送給你，對于的原有業(yè)務(wù)來說，會面臨經(jīng)常修改 MQ 消息結(jié)構(gòu)的問題，這已經(jīng)違背了我們要使其與正常業(yè)務(wù)解耦的初衷，所以我們在收到這條數(shù)據(jù)變更的時候，會通過 soa 接口的方式反查當(dāng)前寬表數(shù)據(jù)，這樣補(bǔ)齊寬表數(shù)據(jù)之后再寫索引，這樣我們就可以拿到我們想要的任何最新數(shù)據(jù)。
通過 ES 建索引的 **bulk api **減少與 ES 集群的交互次數(shù)，提高數(shù)據(jù)寫入的吞吐量。
同一條數(shù)據(jù)，在同一個時刻可能會在機(jī)器 A 和機(jī)器 B 中同時發(fā)生寫索引操作，機(jī)器 A 查詢到的是舊數(shù)據(jù)，機(jī)器 B 查詢到了新數(shù)據(jù)，但是寫入索引的時候機(jī)器 B 先寫入 ES 集群，機(jī)器 A 后寫入集群，導(dǎo)致數(shù)據(jù)錯誤。解決方案：每條數(shù)據(jù)寫入的時候，添加一個分布式鎖，相同唯一建的數(shù)據(jù)在同一個時刻只能有一條發(fā)生寫索引的動作，沒有獲得分布式鎖消息，丟入延遲隊(duì)列，下次再消費(fèi)（由于存在 soa 接口重新反查當(dāng)前寬表數(shù)據(jù)，所以也不需要擔(dān)心消息亂序消費(fèi)的問題）。
數(shù)據(jù)的補(bǔ)償（此處就不展開了）。
數(shù)據(jù)的查詢和統(tǒng)計(jì)
數(shù)據(jù)查詢
前面我們講述了我們 ES 中的索引結(jié)構(gòu)遵循的一些原則，其中有一條是，我們只存儲字段的索引部分來提供查詢，不會在 ES 中存儲原始文檔來提供輸出，那么當(dāng)查詢方需要該字段的信息的時候，我們需要怎么做？其實(shí)這是一個 ES 集群的定位問題，我們的 ES 集群僅僅是用來豐富數(shù)據(jù)查詢、支持?jǐn)?shù)據(jù)統(tǒng)計(jì)的功能，我們并不支持?jǐn)?shù)據(jù)的實(shí)際存儲，我們存儲的僅僅只是每個字段的索引而已，通過每個字段的索引支持各種各樣的數(shù)據(jù)查詢、數(shù)據(jù)統(tǒng)計(jì)，如果需要查詢數(shù)據(jù)的詳細(xì)信息，我們可以通過 ES 查詢得到數(shù)據(jù)的唯一鍵后，再通過 soa 接口來反查該數(shù)據(jù)，之后吐給需求方，我們會將這個步驟包掉，需求方無感知，且返回的數(shù)據(jù)只是將原有的 soa 查詢接口的返回數(shù)據(jù)包了一層，讓其他方感知到的是原 soa 接口的升級版接口，盡可能減少其他方的接入成本。
[圖片上傳失敗...(image-e47026-1561369954378)]
基于 ES 的數(shù)據(jù)的統(tǒng)計(jì)
ES 在做數(shù)據(jù)統(tǒng)計(jì)的時候往往會很消耗 ES 集群的資源，所以我們通常不允許需求方直接通過接口訪問 ES，我們會將各個維度的數(shù)據(jù)提前算好放入其他類型的數(shù)據(jù)庫中，供業(yè)務(wù)方使用，此處也不進(jìn)行展開了。
一些踩坑經(jīng)歷
同樣的查詢條件，前后連續(xù)兩次查詢出來的數(shù)據(jù)結(jié)果不一樣。
這是因?yàn)楦北痉制椭鞣制瑪?shù)據(jù)不一致（ES 只保證最終一致性），ES 在寫操作的時候有個 consistency 的參數(shù)來控制寫入的一致性，具體值為one（primary shard），all（all shard），quorum（default）。
one：要求我們這個寫操作，只要有一個 primary shard 是 active 活躍可用的，就可以執(zhí)行。
all：要求我們這個寫操作，必須所有的 primary shard 和 replica shard 都是活躍的，才可以執(zhí)行這個寫操作。
quorum：默認(rèn)的值，要求所有的 shard 中，必須是大部分的 shard 都是活躍的，可用的，才可以執(zhí)行這個寫操作。
但是就算設(shè)置成了 all 之后，查詢還是有不一致的情況，這是使用 lucene 索引機(jī)制帶來的 refresh 問題。
解決該問題需要將 write consistency 設(shè)置成為 all，replication 是 sync 模式(默認(rèn))，每次寫入數(shù)據(jù)時候需要手工 refresh。如果是寫入很大的應(yīng)用不建議這樣去做。我們選取了另一種方式：對于會短時間內(nèi)出現(xiàn)前后兩次查詢，且需要保證兩次查詢出來的數(shù)據(jù)強(qiáng)一致性的需求指定從 primary shard 讀。
ES 查詢成功，部分 shard 失敗
這個問題很尷尬，因?yàn)槲以谇捌诤荛L時間都沒注意到這個問題，發(fā)現(xiàn)查詢返回成功后，就直接把結(jié)果丟出去了，并沒有注意到下面還有失敗 shards 數(shù)量，后來一次 ES 集群異常，發(fā)現(xiàn)查詢出來的數(shù)據(jù)要比正常值普遍要小很多，不可能是 ES 主、副本分片數(shù)據(jù)不一致的問題，才發(fā)現(xiàn)是該問題。
新增字段
新增字段的時候，一定要先更新所有已存在的索引的 Mapping，再更新 template，最后才能發(fā)布更新后的程序。
由于 ES 集群寫操作在默認(rèn)情況下，Mapping 中沒有的字段，會被自動識別，而自動識別的字段可能不是我們想要的字段類型，而這個時候想要不斷服務(wù)的修改，會很復(fù)雜。所以一定要在發(fā)新的程序之前修改好Mapping、template。
定期進(jìn)行段合并，導(dǎo)致線上大量報錯
有時候?yàn)榱颂岣?ES 集群的性能，我們會定期的手工做一些段合并，但是段合并的計(jì)算量龐大，而且會吃掉大量的磁盤 IO，此時要注意設(shè)置段合并的線程數(shù)，避開業(yè)務(wù)高峰期，防止影響到正常業(yè)務(wù)。
慢查詢拖垮 ES 集群
我們解決這個問題主要有兩點(diǎn)：
- 慢查詢需要有監(jiān)控措施；
- 提供給 ES 的查詢接口限流、降級措施需要做好。
前期設(shè)計(jì)工作一定要做好
尤其是對于 mapping 的設(shè)計(jì)，一旦設(shè)計(jì)的不合理，后期再想修改會很費(fèi)勁，需要重新再長出一套同樣的東西供調(diào)用方使用，然后才能徹底下掉老邏輯，周期會很長。
做好 ES 集群的監(jiān)控很重要，否則出現(xiàn)問題，就跟瞎子一樣，很難定位問題。
小結(jié)
以上，便是本篇的全部內(nèi)容，Elasticsearch 里面可以講的有太多太多了，每個小點(diǎn)拿出來可能都能說上一番。本篇文章較淺，如果有您不滿意的的地方，希望可以多多指點(diǎn)，同時也希望本篇文章能夠?qū)δ兴斋@。
本文首發(fā)于 GitChat，未經(jīng)授權(quán)不得轉(zhuǎn)載，轉(zhuǎn)載需與 GitChat 聯(lián)系。
