創作人：毛夏軍
審稿人：劉帥
什麼是分片配置設定 (shard allocation)
分片配置設定 (shard allocation)，是指在索引建立、副本增減、節點增減、分片重平衡等，将索引分片落實到實際的實體節點的過程，分片配置設定可以分為，叢集級配置設定和索引級配置設定兩種，叢集級配置設定常見的包括
- 要求熱索引的分片不要去往低配機器，
- 商品、訂單索引的分片不要配置設定到同一個節點等。
将分片分布到不同的節點，一方面是為了提高系統的可用性，如當叢集中一台機器當機，使得該節點上的分片不可用時，分布在其他機器上的分片，能通過重新選舉繼續工作 (但是仍要保證同一分片的主從副本不全在當機節點上) ；
另一方面是為了提高系統的容量和讀寫性能，如通過增加節點橫向擴容，将叢集中部分分片 Rebalance 到新節點，既可以利用新節點的存儲容量，提升索引存儲容量，遷移過來的分片，可以利用新節點增加的算力提供服務。
總結一下分片配置設定過程，有兩個基本要素：
- 分片：來自叢集内的全部索引，包括主分片和副本分片
- 節點：組成叢集的各個 Elasticsearch 程序，能夠通過一定的辨別來識别個體或劃分成組
那麼，叢集内的各節點是如何被識别和标記的呢？
節點屬性 (node attributes)
節點屬性 (node attributes)，包括内置屬性和自定義屬性兩種。
Elasticsearch 會将常見用于區分不同機器的标記，如主機名 (_host)、IP 位址 (_ip)、節點名稱 (_name) 等作為内置屬性，供分片配置設定時區分節點的标記使用，具體包括：
- _name：節點名稱，即在 elasticsearch.yml 中定義的 node.name 屬性
- _host_ip、_publish_ip、_ip：節點的 IP 位址，一般情況下使用 _ip 即可，具體含義可以查閱官方幫助文檔
- _host：主機名
- _id：叢集為節點自動配置設定的唯一辨別符，手動調控時使用較少
- _tier：節點的資料角色，比如存儲冷熱資料的 data_cold、data_hot 等，可以在 elasticsearch.yml 中指定 node.roles 屬性
内置屬性可以用來區分不同節點，但是對于将節點劃分成組來說不是很便利，比如我們希望将索引配置設定到高配節點。如果使用内置屬性，比如 _ip 的話，需要在索引設定
index.routing.allocation.include._ip
中，指定多個機器的 IP 位址，在叢集增删高配節點的情況下，需要同時調整對應索引的分片配置設定設定，顯得不太便捷。
我們很自然的希望除了内置屬性之外，還可以根據機器配置的高低、是否同屬于一個網段等情況來标記節點，友善我們将不同類型的節點劃分為一個個組，繼而将索引的配置設定配置到節點組，這樣在叢集增删節點時，隻要節點配置了對應的組，叢集就會根據對應組的節點變化自動的将分片重新調整，而不需要我們再手動的同步每一個索引的配置設定設定。
自定義節點屬性解決的便是這個問題，我們可以通過：
- 在 elasticsearch.yml 中新增配置項，如 node.attr.zone=zone1
- 或在啟動指令中增加變量，如 bin/elasticsearch -Enode.attr.zone=zone1
以上方式來為節點增加自定義屬性。
小結
分布式架構為我們帶來了衆多容量、性能和可用性方面的優勢，但是相應的也提高了保障難度，因為分片在叢集自動配置設定的情況下不一定能達到我們期望的"平衡"狀态，需要我們對分片配置設定機制有較高的掌握程度來調控叢集内分片的配置設定狀況，比如主從副本不分布在同一實體節點、解決節點資料傾斜導緻新分片集中于某幾台負載較低節點的熱點問題等。
調控分片配置設定
Elasticsearch 叢集中 master 節點的一項重要功能，就是決定分片如何以最佳的方式，均衡分布到叢集内的各個節點上。除了自動配置設定之外，我們也可以從粗粒度的叢集次元和細粒度的索引次元，手動調控分片在各節點的配置設定。
叢集次元 (cluster level) 的分片配置設定，是将所有分片納入一起考慮，不會單獨考慮某個索引的分片配置設定情況。
舉個例子：我們有兩個索引，每個索引包含兩個分片，将分片配置設定到兩個節點組成的叢集。
狀态一：
同一個索引的全部分片配置設定到同一個節點
{
"node_1": ["index_1_shard_1", "index_1_shard_2"],
"node_2": ["index_2_shard_1", "index_2_shard_2"]
} 狀态二 ：
同索引的分片均勻配置設定到各節點
{
"node_1": ["index_1_shard_1", "index_2_shard_2"],
"node_2": ["index_2_shard_1", "index_1_shard_2"]
} 從叢集次元，都可以被認為是"平衡"狀态，但是從實際角度看，隻有狀态二是我們期望的平衡狀态。因為如果 index_1 和 index_2 負載不均，在狀态一下，很可能導緻叢集内節點負載不均，使得服務整體表現不能達到預期。
要達到我們期望的狀态二，就可以使用索引次元 (index level) 的分片配置設定控制方法，比如通過
index.routing.allocation.total_shards_per_node
參數控制每個節點的分片數量為 1 ，就可以達到我們的目的了。
叢集次元分片配置設定
從叢集層面來說，分片配置設定控制的是叢集内各索引的分片，集合在各節點的分布，并且在分片配置設定過程中，添加一些硬性限制以控制叢集負載在合理範圍内。
以一個實際操作中可能會遇到的情況來說，公司準備新上一批業務，需要用到大規模的資料檢索功能，首先需要處理搭建叢集的任務，在開始搭建叢集之前，讓我們先看看實際的業務場景。
系統用于收集應用打點日志，提供一周内資料供查詢。
分片平衡的啟發式參數
日志類型資料存儲，帶有非常明顯的時效性，一般情況下當日資料的讀寫頻繁，非當日資料幾乎不會有寫操作，離目前時間越久的資料讀操作也越少。
通過上述判斷，可以認為索引的分片，越是平均分布于叢集内各節點越好，因為可以充分利用全部節點的算力，來分攤當日資料的高頻讀寫負載。
為了達到這個目的，我們可以通過 Elasticseach 提供的部分啟發式參數，讓 master 在決策分片如何配置設定時，更多的向我們期望的方向考慮：
- cluster.routing.allocation.balance.shard 節點中分片總數對權重的影響因子，預設為 0.45，該值越大則各節點的分片數越趨向于相等。
- cluster.routing.allocation.balance.index 節點中來自不同索引的分片數對權重的影響因子，預設為 0.55，該值越大，則各索引的分片更傾向于均勻配置設定到各節點。
- cluster.routing.allocation.balance.threshold 預設為 1.0，該值越大，則叢集對不平衡狀态的容忍程度越高。
我們可以适當放大
cluster.routing.allocation.balance.index
的權重來使得叢集在配置設定分片時，更傾向于将一個索引的不同分片，均勻分布到各個節點。不過需要注意的是，這隻是一個啟發式參數，更多的是"建議"，而不是"指令"，要完全達到我們的期望，還需要借助索引次元的配置設定調控手段。
分片遷移的流量控制
回到本節起始提到的日志業務，系統上線運作一段時間後，随着索引量的不斷增加，我們需要适時的清理掉過期資料，清理過程中自然的會删除過期資料所在的索引，釋放存儲空間供新的索引使用。
在叢集删除索引時，因為叢集内分片總數發生了變化，自然的分片在各節點的配置設定狀态也随之發生變化，可能會出現分片的"不平衡"狀态。這時預設情況下叢集，會自動觸發分片的重平衡操作，将分片在各節點間适當的遷移，以使得分片在叢集重新達到"平衡"狀态。
在日志類資料情況下，單個分片包含的資料量可能會較大，達到若幹 GB。這樣在分片發生遷移時，節點必然會觸發大量的 IO 操作，為了避免大量的 IO 操作對節點造成沖擊，使得叢集服務發生抖動，我們可以通過分片遷移的流量控制參數進行幹預：
- cluster.routing.allocation.node_concurrent_incoming_recoveries
用于控制可同時在一個節點上進行初始化或恢複的最大分片數，預設為2，設定過大可能導緻節點負載過高 (同時寫入大量資料)，調整時需要考慮節點的硬體配置。
- cluster.routing.allocation.node_concurrent_outgoing_recoveries
用于控制該節點可同時為其他節點分片恢複或遷移提供資料源的最大分片數，預設為2，調整同理。
注1: 從節點的角度，分片會出現兩種流向：流入 和 流出，其中，流入是指來自某個索引的分片新落入到該節點，流出是指該在其他節點的分片以該節點所屬的分片為資料源進行副本恢複或者資料遷移。
節點的水位線
随着打點應用的接入越來越多，單日的日志索引量上漲迅速，節點的磁盤水位吃緊，我們希望新的分片在配置設定時，能考慮到節點存儲容量的狀态，避免将新分片配置設定到磁盤容量快滿的節點。
這個情況下如果要自行通過節點屬性來調控，至少需要：
- 自動監測磁盤水位，并為節點打上 low/medium/high 的屬性，而且更改屬性還需要重新開機節點。
- 為新配置設定的索引設定
index.routing.allocation.require.*
- 在節點的磁盤水位屬性變更時，自動為叢集内的索引更新 allocation 配置來避免自動平衡。
看上去就很麻煩，那麼有沒有簡便方法呢？
答案是使用内置的水位
cluster.routing.allocation.disk.watermark.*
屬性。
水位限制分為高低兩種，其中：
- cluster.routing.allocation.disk.watermark.low
低水位，預設為磁盤容量的 85%，Elasticsearch 會避免将分片分布至磁盤容量超過低水位的節點。但是新建立索引的主分片 (primary shards)，仍然可以配置設定到超過低水位的節點。
- cluster.routing.allocation.disk.watermark.high
高水位，預設為磁盤容量的 90%，Elasticsearch 會将磁盤容量超過高水位節點上的分片遷移至其他節點。
- cluster.routing.allocation.disk.watermark.flood_stage
警戒水位，預設為磁盤容量的 95%，當節點磁盤容量超過警戒水位時，該節點所屬分片所在的索引，都會被執行寫禁止操作，即索引變為隻讀狀态。
比如 A 索引的 shard 1 分布在 N1 節點，shard 2 分布在 N2 節點，如果 N1 節點磁盤容量超過警戒水位，索引 A 即被執行寫禁止操作，成為隻讀索引。但是容量絕對值和百分比不能混用，比如指定了磁盤低水位為 500mb，則高水位相應的也必須使用絕對值表示。
索引的增、删、改都會對所在節點的磁盤水位産生影響，為了動态的感覺磁盤水位，相應的就有了水位采集參數：
- cluster.info.update.interval
磁盤水位采集頻率，即每隔多久去檢查一次磁盤用量，預設為 30 秒。
- cluster.routing.allocation.disk.include_relocations
是否将正在遷移到目前節點的分片磁盤用量 (将占用的磁盤空間) ，計入目前節點的磁盤用量，預設打開。
熱點問題
雖然根據實際資料更替情況，合理配置了節點的高低水位，但是随着時間推移，我們發現叢集發生了熱點資料傾斜問題，由于冷資料占用了大量的存儲空間，導緻熱點資料 (當日新建立的索引)， 被迫配置設定到空間用量相對較少的幾個節點，使得叢集的負載不均。
針對日志服務等索引頻繁建立、删除的場景，資料帶有明顯的時效性，可以考慮叢集分組，對冷熱資料使用不同的配置設定标記 (allocation attributes) ，來隔離冷熱資料 (或者使用 data tier allocation) ，目的是避免通路較少的冷資料，占用磁盤容量，導緻叢集将新建立的索引配置設定到少數幾個"看起來比較合适"的節點，導緻熱點問題出現。
Elasticsearch 新版本中已經将類似的功能內建為 data_tier 插件，詳見下一小節。
針對索引建立、删除不頻繁的場景，比如電商後端常見的商品搜尋、訂單搜尋等，一方面可以考慮将叢集節點分組，或者部署多個叢集，将不同業務進行資源隔離。
另一方面，建立索引時需要考慮到，未來資料量的增長情況，以設定合理的分片數量，将分片盡量均勻配置設定到每個節點，以更合理的利用節點硬體資源；
一般來說，商品、訂單等業務資料長尾效應比較明顯，針對熱點的店鋪、類目等引起的資料傾斜問題，可以将熱點資料單獨拆出一個索引，配合前端的引擎代理将請求路由到對應的索引。
管理節點
系統資源吃緊，需要通過橫向擴容增加叢集容量。
節點擴/縮容
當向叢集擴容節點時，其他節點會遷移部分分片到新節點，如果并發遷移的分片過多，可能造成瞬時的高 IO 負載，引起服務抖動。
我們可以通過
cluster.routing.allocation.node_concurrent_incoming_recoveries
參數控制分片遷移的速度，如果是在叢集負載較高的情況下橫向擴容新節點，建議分開兩步操作：
- 關閉
cluster.routing.rebalance.enable
- 通過手動對目标索引進行
index.routing.allocation.include
同樣的，在縮容叢集時，如果直接關閉節點，可能存在兩個風險點：
- 在叢集規模較大情況下，會有大量索引同時進行分片主從切換和分片重新配置設定操作，瞬時對 master 節點帶來很大的負載，尤其是日志類資料的大叢集。因為分片數較多，可能導緻 master 節點 CPU 飙高，使得新建立索引等操作被阻塞；
- 小機率情況下。如果其他節點發生意外當機，索引将存在資料丢失風險。
對于類似縮容，存在一定風險性的主動操作，建議與擴容類似，首先設定全部索引的
index.routing.allocation.exclude
或者直接在叢集範圍内設定
cluster.routing.allocation.exclude
屬性将待下線的節點排除，待分片全部移出之後再關閉節點程序。
節點重新開機
除了橫向擴容外，對節點縱向擴容，或者更新 Elasticsearch 版本，都需要對節點進行重新開機操作。
在重新開機節點時，自然會有節點的上下線操作，節點下線同時會讓該節點所屬的分片處于 unassigned 狀态。正常情況下，叢集會将這些未配置設定分片，重新配置設定到叢集内其他節點上，在日常運維的節點重新開機操作中，這顯然不是我們期望的，無端的帶來了大量的 IO 操作。
正常的滾動重新開機操作中，建議是：
- 通過
cluster.routing.allocation.enable: none
- 重新開機節點；
- 将
cluster.routing.allocation.enable
調控分片的實體配置設定
因為日志檢索方面表現良好，公司決定将商品、訂單等系統的檢索功能也遷移到 Elasticsearch 叢集，并提供了高配機器用于叢集搭建。
分片在單台實體機的配置設定
在實際的部署過程中，有時會遇到大容量高配機器，比如 32 核 128GB 記憶體，我們可以考慮單節點部署，将對記憶體資料量擴大到 32GB 以上 (一個是對象指針壓縮技術不再可用，造成記憶體空間膨脹，另一個是堆記憶體回收壓力也增大，可能造成 gc 停頓時間變長)；
也可以考慮單機多節點的部署方式，在這種情況下，為了資料可用性的考慮，索引内同一分片的主副本資料，需要配置設定到不同的實體節點上，這時可以使用如下參數：
- cluster.routing.allocation.same_shard.host
阻止同一分片的多個執行個體 (主副本) 落到同一個主機，同一主機的判定條件為相同的主機名 (host name) 和主機位址 (host address)，預設情況下該參數為關閉狀态，強烈建議在單機多節點部署的情況打開該配置，避免可能的資料丢失風險。
對商品、訂單的搜尋場景，一般單節點的負載會控制在最大值的 50% 左右，以提供足夠的餘量來承載瞬時的流量高峰，為了達到這個目的，在分片配置設定層面，可以設定單節點的分片數上限：
- cluster.routing.allocation.total_shards_per_node
單節點最多能支撐的分片數，當節點包含的分片數高于該數值時，新分片不會在該節點建立。
分片在機房内的配置設定
為了資料高可用的考慮，我們在管理叢集的時候，可能會考慮索引的主從分片，不要都落到某一台主控端，或者同一個機架上，這個時候可以通過一些提示性參數，讓叢集在選擇節點時有一定的傾向性：
- cluster.routing.allocation.awareness.attributes
設定分片分布時，會考慮将分布交叉分布到屬性不同的節點上，比如叢集包含兩個節點 N1
node.attr.zone=zone1
、N2
node.attr.zone=zone2
，如果我們在
elasticsearch.yml
中設定
cluster.routing.allocation.awareness.attributes: zone
，則我們建立帶一個副本的索引時，叢集會将同一分片的主副本交叉分布在不同的節點上。節點屬性可通過上述自定義屬性方式設定。
- cluster.routing.allocation.awareness.force.zone.values
假設叢集節點仍然是 N1、N2，如果 N2 因為故障當機，預設情況下，N2 所屬的分片會在 N1 節點重新恢複出來，但是在同一個節點運作相同分片的主副本并沒有實際意義，這時我們在
elasticsearch.yml
cluster.routing.allocation.awareness.force.zone.values： zone1,zone2
來避免這種操作，叢集會在
zone2
屬性節點恢複後再将相應的副本分片恢複到該節點。
叢集分片上限
系統跑起來了，那麼叢集最多能負載的分片數是多少呢？
對日志類的資料，通常會以應用、時間、日志級别等多個次元建立索引，這樣一來叢集内的總分片數變得相當可觀，那麼叢集最多能負載的分片數是多少呢？
答案也很簡單，就是節點數與單個節點能最多能支撐的分片的積，但是這裡的單節點最多支撐的分片數：
- cluster.max_shards_per_node
用于限制整個叢集最多能支撐的分片數，當叢集内活躍分片數大于
cluster.max_shards_per_node * number_of_data_node
時，叢集會阻止新索引的建立，直到有索引被删除或者關閉 (closed) ，使得活躍分片總數低于門檻值。這裡的活躍分片數是指非 closed 狀态的分片，包括 unassigned / initializing / relocating / started。
不會像
cluster.routing.allocation.total_shards_per_node
真正的限制單節點的分片數。
這裡列舉了部分較為常用的配置，更多參數可以參閱官方文檔。
我們調整或幹預叢集的分片參數，從根本上說，是為了在叢集穩定的情況下将性能最大化，從分片配置設定 (allocation) 的角度來說，穩定意味着分片盡量少的移動，性能意味着同一個索引的分片盡量均勻分布到各節點，而不要集中到少數幾個節點。
索引次元分片配置設定
如同設計系統需要先從架構角度考慮系統子產品設計，再細化到每一個應用設計應用自身的功能子產品，索引分片的調整也需要先從叢集角度，設定大的配置設定政策導向，如節點分布 (shard awareness)、平衡 (shard rebalance) 等，再細化到每一個索引考慮單索引分片如何調整以達到最佳的表現。
再以上一節中的商品、訂單檢索系統為例，因為這分屬兩個子系統，符合我們預期的了解是即使商品檢索系統負載很高，也不應該影響訂單系統的檢索耗時。
隔離不同索引
對不同業務所屬索引進行實體隔離，實作 A 索引在執行大負載操作時，不會對 B 産生影響，前提是使用節點屬性，将叢集按照需要分割為多個群組。
比如叢集包含以下設定的節點：
index.routing.allocation.*
配置可以啟用索引的分片控制，具體的：
-
index.routing.allocation.include.{attribute}
将索引分片配置設定到包含任一指定屬性的節點上。{attribute} 可以指定為節點内置屬性，如 _ip、_host 等，也可以指定為自定義屬性，如 zone 等，也可以混用。
- index.routing.allocation.require.{attribute}
将索引分片配置設定到指定節點上，節點必須包含指定的全部屬性。
- index.routing.allocation.exclude.{attribute}
不要将索引配置設定到包含任一指定屬性的節點上。
如果設定索引的分片控制參數為：如果參數設定為：如果參數設定為：則索引分片不會被配置設定到 Node C。
排查分片配置設定
當我們在建立索引後，發現索引分片不能被正常配置設定時，可以通過 explain 接口來檢視原因，如下：
curl -XGET '{host:port}/_cluster/allocation/explain' 在 response 中可以看到具體分片未被正常配置設定的原因，如：
{
"index": "test_v1",
"current_state": "unassigned",
"unassigned_info": {
"reason": "INDEX_CREATED",
"last_allocation_status": "no"
},
"can_allocate": "no",
"allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",
"node_allocation_decisions": [
{
"node_decision": "no",
"deciders": [
{
"decider": "filter",
"decision": "NO",
"explanation": "node does not match index setting [index.routing.allocation.require] filters [node:\"xxx\",_ip:\"1.1.1.1\"]"
}
]
}
]
} 表示因為沒有節點能夠同時滿足
node.attr.node: xxx
且 IP 位址為
1.1.1.1
的節點 (response 内容适當删減了非必要資訊)。
平衡索引分片在各節點的配置設定
在索引按業務分組隔離之後，以商品檢索為例，後續又追加了商品評價索引，用于存放商品的評價記錄，由于用量較低，我們希望将分組内機器資源，主要用來承載商品檢索服務。
不考慮分片資料傾斜的問題，即每個分片的負載一緻，我們可以将索引的分片數 (主分片和副本分片的總和) ，設定為與節點個數一緻，并通過設定索引分片，在各節點的配置設定個數來強迫索引在各節點間均衡配置設定。
要控制索引在單個節點的數量，可以通過
index.routing.allocation.total_shards_per_node
參數設定。
比如現有 6 個節點，我們可以将索引的分片數
index.number_of_shards
設定為 3，副本數
index.number_of_replicas
設定為 2，同時将索引在每個節點上的最大分片數
index.routing.allocation.total_shards_per_node
設定為 1，即可以保證索引在每個節點配置設定一個分片，充分利用每個節點的算力。
冷熱隔離/歸檔
回到日志資料的問題，為了便于回溯問題，我們期望将資料的存檔時間，從一周延長為半年，但是不要求全部的資料，都有同樣的可用性和響應時間，
- 一周内需要有高性能的讀寫能力
- 一月内資料僅需保證秒級的查詢 RT 即可
- 一年内的資料不需要實時保證可讀，隻要能保證資料在必要情況下可恢複使用即可。
對于冷熱時效明顯的資料場景 (比如日志類) ，熱資料 (如當日資料) 的讀寫頻率都要明顯高于冷資料 (如一周前資料)，這個時候從成本的角度出發，我們期望将冷資料存放于容量較大、IO 及 CPU 性能較弱的存儲類機器，将熱資料存放于 IO、CPU 性能較好的計算類機器。
我們可以将節點按照存儲優化型、計算優化型、通用型等定向優化的類型分組，使用 node.roles 将節點分組，可使用的角色包括：
- data_content 存儲使用者定義的業務資料，需要保證高性能的讀寫。
- data_hot 存儲新的時序資料，讀寫頻繁，CPU、IO 敏感型資料。
- data_warm 讀寫頻率降低，寫很少，可容忍讀 RT 變高。
- data_cold 保留隻讀資料，比如曆史記錄。
- data_frozen 用于保留資料快照，比如對冷資料将其副本作為 searchable snapshot 存放到 data_frozen 節點，并關閉原始索引的副本，在保證資料可用性的情況下進一步減少空間備援，降低資料成本。
實際應用中，通常會搭配 ILM (index lifecycle management) 來使用這類 data tier 屬性，如：
{
"phases" : {
"hot" : {
"actions" : {
"rollover" : {
"max_age" : "1d",
"max_size" : "5gb"
}
}
},
"warm" : {
"min_age" : "7d",
"actions" : {
"forcemerge" : {
"max_num_segments" : 1
}
}
},
"cold" : {
"min_age" : "30d",
"actions" : {
"searchable_snapshot": {
"snapshot_repository" : "snapshot_house"
}
}
}
}
} 将一周内資料作為熱點資料，存儲于 data_hot 節點，其他一月内資料作為溫資料，存儲于 data_warm 節點，超過一個月的資料，啟用 searchable_snapshot，叢集内隻保留主分片，副本備份到指定的遠端路徑下。
Elasticsearch 内部使用
index.routing.allocation.include._tier_preference
屬性來實作這個操作，與
index.routing.allocation.include._tier
不同，
_tier_preference
屬性不是僅限定一種角色的節點，比如設定
{
"index.routing.allocation.include._tier_preference": "data_hot,data_warm,data_cold"
} 表示将索引優先存儲于 data_hot 節點，如果不存在 data_hot 次選 data_warm，最後使用 data_cold 兜底存儲。
在索引的生命周期中，新建立的索引
_tier_preference
先設定為 data_hot，在超過熱點周期後，更新
_tier_preference
為 data_warm。data_hot 将其遷移到存在的 data_warm 節點。
通過這樣的手段，我們可以根據索引資料的使用場景，合理的調配硬體資源，達到成本利用的最優化。
創作人簡介：
毛夏君，關注研究中間件，比如 ES，Redis，RocketMQ 等技術領域。
部落格：微信公衆号——tiaotiaoba_abc**
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)