biz 配置
biz confighash_mode一級(jí)散列二級(jí)散列query_configreturn hit 優(yōu)化配置mempool配置join_config
在ha3 3.0 之前, indexlib 離線build,indexlib實(shí)時(shí)build索引, indexlib 索引加載, 以及在線檢索相關(guān)的配置都揉在cluster 配置里面,cluster 配置比較復(fù)雜, 3.0 對(duì)這些邏輯進(jìn)行了拆分：
indexlib 離線build 索引（全量增量）, indexlib 實(shí)時(shí)build索引的配置獨(dú)立出來(lái)放到離線的cluster 配置里面,文件名一般以app_cluster.json
indexlib 索引加載方式相關(guān)配置放到table的配置里面,文件命名一般也是cluster_name +"_cluster.json" ,與離線build配置文件通過(guò)文件夾路徑進(jìn)行區(qū)分;
在線檢索相關(guān)配置在biz 配置中, 配置結(jié)構(gòu)如下所述
biz config 結(jié)構(gòu)
{
"cluster_config": {...},
"aggregate_sampler_config" : {...},
"rankprofile_config" : {...},
"summary_profile_config" : {...},
"function_config", : {...},
"searcher_cache_config" : {...},
"service_degradation_config" : {...}}
cluster_config
cluster_config {
"hash_mode" : "",
"query_config" : "",
"join_config" : "",
"return_hit_rewrite_threshold" : "",
"return_hit_rewrite_ratio" : "",
"table_name" : "",
"pool_trunk_size: : 10,
"pool_recycle_size_limit" : 20,}
文檔的hash方式，用于決定將文檔被歸類(lèi)到哪一個(gè)partition當(dāng)中。 hash_field： 計(jì)算hash的字段, 一般使用pk 比較多, 當(dāng)然也有例外,比方說(shuō)inshop; hash_function: 目前支持三種hash方法，HASH、GALAXY_HASH、KINGSO_HASH。對(duì)于KINGSO_HASH，如果想修改kingSo的hash范圍可以將此項(xiàng)配置成KINGSO_HASH#range的形式,必須配置;
例子：
"hash_mode":
{
"hash_field" : "nid",
"hash_function" : "HASH"
}表示根據(jù)nid 字段使用HASH 方法計(jì)算hash值,進(jìn)行分partition
首先介紹下HA3引擎的索引由全量（增量）和實(shí)時(shí)索引組成。 全量索引由build service（下文簡(jiǎn)稱(chēng)bs）構(gòu)建，實(shí)時(shí)索引由searcher builder構(gòu)建，兩者都需要讀取swift對(duì)應(yīng)topic的文檔進(jìn)行build。索引文檔的路由由bs的processor完成。它讀取文檔中在hash_mode配置的字段，通過(guò)hash函數(shù)計(jì)算得到一個(gè)值，其范圍[0,65535]，發(fā)送到swift相應(yīng)的topic的分區(qū)中[0, 65535]。所以邏輯上索引共分2^16 邏輯partition, 編號(hào)是[0, 65535]。 用戶(hù)可以指定最終生成的物理partition個(gè)數(shù)，引擎會(huì)自動(dòng)把連續(xù)的邏輯partition映射到物理partition上。例如有2個(gè)物理partition的索引，包含的邏輯partition的區(qū)間分別是[0,32767]和[32768, 65535]，同時(shí)訂閱相同的swift topic分區(qū)就能獲取相應(yīng)的文檔。在線查詢(xún)時(shí)讀取在線對(duì)應(yīng)的hash_mode配置，進(jìn)而查詢(xún)指定的列。 有了上面的背景知識(shí)，我們先來(lái)說(shuō)下一級(jí)散列，舉個(gè)淘寶店鋪內(nèi)搜索的例子：hash_mode中配置hash_field為user_id（賣(mài)家id），大賣(mài)家的商品量遠(yuǎn)遠(yuǎn)大于其他小賣(mài)家所擁有的商品量，在bs processor構(gòu)建的時(shí)候會(huì)將user_id計(jì)算一個(gè)hash值，熱點(diǎn)主要表現(xiàn)為以下三點(diǎn)：1.bs processor計(jì)算hash之后，大賣(mài)家所在的builder和merger耗時(shí)會(huì)明顯大于其他builder和merger，從而拖慢整體build進(jìn)度；2.索引產(chǎn)出加載到引擎的不同列時(shí)，大賣(mài)家所在列的索引明顯大于其他列，引擎需要為了熱點(diǎn)擴(kuò)大全部列的資源，造成了在線資源的浪費(fèi)；3.查詢(xún)也表現(xiàn)為大賣(mài)家所在的列查詢(xún)量較多而出現(xiàn)查詢(xún)熱點(diǎn)。所以一級(jí)散列在這種情況下會(huì)導(dǎo)致build時(shí)間拉長(zhǎng)，在線資源浪費(fèi)和查詢(xún)熱點(diǎn)等問(wèn)題。
二級(jí)散列是在一級(jí)散列的基礎(chǔ)上拓展而來(lái)的功能，二級(jí)散列的作用是在一級(jí)散列的基礎(chǔ)上，把一級(jí)散列到同一列的文檔繼續(xù)按照二級(jí)散列字段散列到不同的列上，比如店鋪內(nèi)搜索，二級(jí)散列中hash_fields配置為user_id（賣(mài)家ID）、nid（寶貝ID），一級(jí)散列是按照賣(mài)家分列，大賣(mài)家的寶貝都落在了引擎的一列上面，二級(jí)散列就是在按照賣(mài)家分列的基礎(chǔ)上，再按照寶貝ID進(jìn)行二級(jí)散列，這樣大賣(mài)家的寶貝就會(huì)落在引擎的多列上。因?yàn)樯⒘惺窃赽s的processor中完成的，所以，1.bs的build和merge階段的數(shù)據(jù)熱點(diǎn)得以消除從而加快build速度；2.引擎中不同列數(shù)據(jù)不存在明顯的熱點(diǎn)，可以提升引擎整體的資源利用率；3.在查詢(xún)時(shí)同樣也會(huì)因查詢(xún)分布到不同的列上，減少查詢(xún)熱點(diǎn)的出現(xiàn)。此功能在引擎3.7.2版本開(kāi)始支持。 在autil中提供了二級(jí)列表函數(shù)ROUTING_HASH，其對(duì)應(yīng)的新的hash_mode的配置如下：
"hash_mode" :
{
"hash_field" : "user_id",
"hash_fields" : ["user_id", "nid"],
"hash_function" : "ROUTING_HASH",
"hash_params" : {
"hash_func": "HASH",
"routing_ratio":"0.25",
"hot_ranges":"512-1536;8000-10000",
"hot_ranges_ratio":"0.25;0.5"，
"hot_values":"t1;t2",
"hot_values_ratio":"0.3;0.4"
}
}參數(shù)說(shuō)明：
hash_field與hash_fields: 原先的hash_field仍支持，當(dāng)hash_fields沒(méi)有配置時(shí)，hash_filed的內(nèi)容會(huì)動(dòng)填入到hash_fields中。當(dāng)hash_fields配置時(shí)，hash_field不生效，hash_field仍需要配置。
hash_function 仍支持原先的三種：HASH、GALAXY_HASH、KINGSO_HASH，新增了ROUTING_HASH作為二級(jí)散列。
hash_params是hash函數(shù)的配置參數(shù)，是個(gè)map<string, string>類(lèi)型，在創(chuàng)建hash函數(shù)時(shí)會(huì)傳入。例如使用HASH、GALAXY_HASH、KINGSO_HASH可以不用配置，ROUTING_HASH如果不配置，默認(rèn)實(shí)現(xiàn)等同于HASH。
ROUTING_HASH的hash_params支持的配置項(xiàng)：
hash_func: 指定routing hash內(nèi)部使用的hash函數(shù)，默認(rèn)是HASH, 可以使用NUMBER_HASH方便測(cè)試
routing_ratio: 二級(jí)散列的覆蓋率， 上述配置中內(nèi)部二級(jí)散列值的計(jì)算是公式：
(HASH(user_id) %65536 + floor(HAHS(nid)%65536 * routing_ratio) )%65536hot_ranges與hot_ranges_ratio：分別是熱點(diǎn)散列值及對(duì)應(yīng)的覆蓋率，可以針對(duì)特定熱點(diǎn)的散列中指定不同的覆蓋率。主要應(yīng)用場(chǎng)景是已知熱點(diǎn)物理列，對(duì)應(yīng)的0-65535間的散列值已知。
hot_values與hot_values_ratio：分別是熱點(diǎn)賣(mài)家及對(duì)應(yīng)的覆蓋率，可以針對(duì)不同的大賣(mài)家設(shè)置不同的覆蓋率。主要的應(yīng)用場(chǎng)景是知道熱點(diǎn)賣(mài)家的原始值。
注意hash mode中hash函數(shù)或hash_params的改動(dòng)都會(huì)導(dǎo)致索引數(shù)據(jù)分布的改變，升級(jí)方案如下：
針對(duì)所有列都需要查詢(xún)的場(chǎng)景，需要重建全量索引+更新qrs配置才能生效。
針對(duì)單列或有二級(jí)散列的場(chǎng)景，需要通過(guò)重建機(jī)群+重建全量索引，原因是qrs的hash配置可能與索引使用的hash配置不一致，導(dǎo)致在升級(jí)的過(guò)程中查詢(xún)的列不正確。
檢索（query）相關(guān)配置, 主要是設(shè)置默認(rèn)檢索的索引名， 查詢(xún)多個(gè)詞之間的默認(rèn)關(guān)系以及是否開(kāi)啟multi_term 優(yōu)化。
default_index
默認(rèn)進(jìn)行查詢(xún)的索引名稱(chēng)，如果在query中未指明查詢(xún)的索引名稱(chēng)時(shí)，將在該索引中查找; 比方說(shuō)query=nid:1 指定了在nid索引下查找, query='mp3'未指定索引名稱(chēng),會(huì)使用默認(rèn)的index。
default_operator
查詢(xún)多個(gè)單詞時(shí)，多個(gè)單詞之間缺省的關(guān)系。例如這里配置為“AND”即表示求多個(gè)單詞查詢(xún)結(jié)果的交集。像 "query=a b" 將被作為 "query=a AND b"進(jìn)行查詢(xún)。如果查詢(xún)的時(shí)候單個(gè)語(yǔ)被分詞器拆分成多個(gè)詞，這多個(gè)詞之間也是按照該配置項(xiàng)指定的關(guān)系進(jìn)行查詢(xún);
multi_term_optimize
multi_term_optimize: 是否啟用multiterm query 優(yōu)化, 比方說(shuō)a|b a&b之類(lèi)的query,默認(rèn)query 解析等價(jià)于a OR b, a AND b, 都是binary query,有兩層,qrs 處理query 開(kāi)銷(xiāo)較大，尤其是|或者&的term 較多的情況,比方說(shuō)主搜海選個(gè)性化召回query,開(kāi)啟這個(gè)優(yōu)化選項(xiàng)之后會(huì)變成一個(gè)多term的單層query,通過(guò)op 標(biāo)識(shí)是OR 還是AND邏輯。
例子： "query_config" : {
"default_index" : "phrase",
"default_operator" : "AND",
"multi_term_optimize" : true},
表示默認(rèn)查詢(xún)的索引是phrase, 多關(guān)鍵默認(rèn)關(guān)系是AND, 并且query解析開(kāi)啟multi_term優(yōu)化。
優(yōu)化searcher 序列化到qrs doc數(shù)的一組配置,默認(rèn)情況qrs 查詢(xún)searcher, searcher 需要返回start+hit個(gè)數(shù)個(gè)文檔（searcher 排序出top(start+hit)）， 當(dāng)start+hit 比較大的時(shí)候searcher 序列化以及qrs 上反序列話成本比較大,事實(shí)上在多列場(chǎng)景每列數(shù)據(jù)分布較均勻, 適當(dāng)減少searcher上返回的條數(shù)對(duì)最終整體效果基本沒(méi)影響（保證所有searcher 返回的條數(shù)大于start+hit再乘以合適的系數(shù)）, 在爬蟲(chóng)或者rank service架構(gòu)下start+hit 往往比較大, 這個(gè)時(shí)候開(kāi)啟比較合適。
return_hit_rewrite_threshold : start + hit 大于這個(gè)閾值時(shí), 開(kāi)啟這個(gè)優(yōu)化;
return_hit_rewrite_ratio: 為了盡量不有損效果,searcher上實(shí)際排序出來(lái)的條數(shù)以及序列化之后的條數(shù),(start+hit)/partition之后的值會(huì)按照業(yè)務(wù)場(chǎng)景乘以一個(gè)大于1的系數(shù) 限制條件：return_hit_rewrite_ratio 合理取值范圍是（1,partition_count）； 對(duì)于類(lèi)似inshop 路由到單列的查詢(xún), 會(huì)自動(dòng)不做這個(gè)優(yōu)化處理;
優(yōu)化后search上序列化的條數(shù)為（start+hit）/partition_count*return_hit_rewrite_ratio. 當(dāng)列數(shù)越多的是以后優(yōu)化效果越明顯;
pool_trunk_size
用來(lái)控制pool分配的trunk大小，以M為單位，默認(rèn)為10M。
pool_recycle_size_limit
觸發(fā)pool回收的大小，以M為單位，默認(rèn)為20M。
輔表相關(guān)配置,典型應(yīng)用場(chǎng)景：寶貝數(shù)據(jù)除了存儲(chǔ)寶貝本身信息外,還要存儲(chǔ)會(huì)員維度（member）信息,如果不通過(guò)輔表的方案, 就要把所需要的會(huì)員信息冗余到寶貝上,同一會(huì)員的寶貝會(huì)都存儲(chǔ)相同的信息（這個(gè)需要離線處理好），會(huì)浪費(fèi)一些存儲(chǔ), 還有個(gè)問(wèn)題就是會(huì)員信息更新的時(shí)候所有的寶貝都需要更新;另外一個(gè)方案則是通過(guò)輔表來(lái)實(shí)現(xiàn), 寶貝和會(huì)員表分開(kāi)索引, 在線的是時(shí)候通過(guò)會(huì)員表的pk（寶貝里面存儲(chǔ)了member_id的正排,跟數(shù)據(jù)庫(kù)機(jī)制類(lèi)似）, 查詢(xún)得到對(duì)應(yīng)的會(huì)員信息（當(dāng)然具體實(shí)現(xiàn)上也有一些優(yōu)化的手段,后面配置會(huì)說(shuō)明）, 這種方案的好處比較明顯, 會(huì)員表沒(méi)有冗余存儲(chǔ),更新也不成問(wèn)題, 但是也有限制, 會(huì)員表信息不能作為檢索條件, 只能用于過(guò)濾排序或者展示, 實(shí)際使用上可以做一些折中,將會(huì)員表中需要檢索的字段冗余到寶貝表上, 其余的存儲(chǔ)在輔表上。
join_infos 描述了當(dāng)前cluster關(guān)聯(lián)的輔表的信息
join_field 用于與輔表關(guān)聯(lián)的字段。主表中的join_field有如下幾個(gè)限制： a. join_field必須與輔表的關(guān)聯(lián)字段完全一致 b. join_field目前不能是多值類(lèi)型 c. join_field僅支持整數(shù)類(lèi)型以及string類(lèi)型 d. 輔表中的primary key索引字段必須是join_field
join_cluster 關(guān)聯(lián)輔表的cluster name
strong_join 是否是強(qiáng)關(guān)聯(lián)。當(dāng)某次查詢(xún)需要取該輔表的attribute時(shí)，若某篇doc關(guān)聯(lián)失敗（ 即通過(guò)join attribute查輔表pk index失敗），如果開(kāi)啟了強(qiáng)關(guān)聯(lián)，則會(huì)丟棄該doc； 否則，默認(rèn)會(huì)保留該doc，即使關(guān)聯(lián)失敗。
use_join_cache 是否開(kāi)啟join docid cache功能。join docid cache是主表docid到輔表docid的映射（可認(rèn)為是一個(gè)特殊的attribute），對(duì)用戶(hù)是透明的，用于輔表性能優(yōu)化（開(kāi)啟了這個(gè)功能不需要再做輔表的pk 檢索,直接在cache 中拿到輔表的docid）。從2.8版本開(kāi)始每個(gè)join_cluster分別配置。
check_cluster_config 是否開(kāi)啟檢查配置路徑的功能，如果設(shè)為true，開(kāi)啟功能，會(huì)根據(jù)cluster_name去讀取相應(yīng)路徑下的配置文件，如果關(guān)閉功能，則跳過(guò)讀取配置文件，自動(dòng)填充table_name為cluster_name。默認(rèn)值為true。
配置例子：
"join_config" : {
"join_infos" : [
{
"join_field" : "company_id",
"join_cluster" : "company",
"strong_join" : true,
"use_join_cache" : true,
"check_cluster_config": true
}
]
},aggregate_sampler_config
aggregate_sampler_config配置統(tǒng)計(jì)時(shí)的相關(guān)參數(shù)，支持2種統(tǒng)計(jì)模式：普通統(tǒng)計(jì)和批量統(tǒng)計(jì)， 通過(guò)aggBatchMode標(biāo)識(shí),這部分為可選配置，默認(rèn)為普通統(tǒng)計(jì)模式。
普通統(tǒng)計(jì)是指每seek出一個(gè)結(jié)果就統(tǒng)計(jì)一次，它的參數(shù)含義如下：
"aggregate_sampler_config" :
{
"aggThreshold" : 0,
"sampleStep" : 1
}aggThreshold 統(tǒng)計(jì)的閾值,當(dāng)已經(jīng)統(tǒng)計(jì)的個(gè)數(shù)小于這個(gè)數(shù)字時(shí)，抽樣所有的。否則按照每sampleStep個(gè)數(shù)，抽取一次;
sampleStep 抽樣統(tǒng)計(jì)時(shí)，每次抽樣統(tǒng)計(jì)的跨度;
當(dāng)aggBatchMode 為true時(shí)表示批量統(tǒng)計(jì), 指seek出所有結(jié)果后再一次性統(tǒng)計(jì)，例子如下：
"aggregate_sampler_config" : {
"aggBatchMode" : true,
"aggThreshold" : 1000,
"batchSampleMaxCount" : 1000
}批量統(tǒng)計(jì)開(kāi)關(guān)
aggThreshold,批量統(tǒng)計(jì)的閾值，totalhits小于等于aggThreshold時(shí)，統(tǒng)計(jì)所有的結(jié)果。
totalhits大于aggThreshold時(shí)，批量統(tǒng)計(jì)的最大抽樣個(gè)數(shù)，此時(shí)的步長(zhǎng)公式是 (totalhits + batchSampleMaxCount - 1) / batchSampleMaxCount。
densemap功能開(kāi)關(guān)
"aggregate_sampler_config" : {
"enableDenseMode" : false
}enableDenseMode，值為"true"和"false"，與性能有關(guān)的選項(xiàng)，根據(jù)業(yè)務(wù)特點(diǎn)選擇開(kāi)啟或關(guān)閉。如果業(yè)務(wù)場(chǎng)景待統(tǒng)計(jì)的groupkey比較豐富，可以打開(kāi)，性能會(huì)有提升。默認(rèn)為"false"。
注：開(kāi)啟該選項(xiàng)前，務(wù)必要進(jìn)行壓測(cè)！
table_name
表名, 用于search上獲取schema等;
rankprofile_config
主要負(fù)責(zé)定義算分的插件，這部分為可選配置，主要配置插件so 名稱(chēng)以及用到score 插件名稱(chēng)
modules.module_name 插件的模塊名稱(chēng)
modules.module_path 插件動(dòng)態(tài)鏈接庫(kù)的名稱(chēng)
modeles.parameters 用戶(hù)自定義參數(shù)，傳遞給插件的so使用
rankprofiles.rank_profile_name rank_profile名稱(chēng)，可以在查詢(xún)語(yǔ)句中指定使用哪個(gè).
rankprofiles.score_name so中score的名稱(chēng)
rankprofiles.total_rank_size 這個(gè)表示該scorer算分時(shí)接受的最大文檔數(shù)量（單partition上要除以partition_count）
例子：
"rankprofile_config" : {
"modules" : [
{
"module_name" : "fake_scorer",
"module_path" : "libfakescorer.so",
"parameters" : {
"key" : "value"
}
}
],
"rankprofiles" : [
{
"rank_profile_name": "DefaultProfile",
"scorers" : [
{
"scorer_name" : "FakeScorer",
"module_name" : "fake_scorer",
"parameters" : {
"key" : "value"
},
"rank_size" : "300"
}
],
"field_boost" : {
"phrase.title" : 1000,
"phrase.body" : 100
}
}
]
}summary_profile_config
required_attribute_fields summary返回結(jié)果中，不在summary_schema中的attribute字段；主要應(yīng)用于輔表，即主表查詢(xún)結(jié)果里返回輔表字段。
modules.module_name 插件的模塊名稱(chēng)。
modules.module_path 插件動(dòng)態(tài)鏈接庫(kù)的名稱(chēng)。
modules.parameters 用戶(hù)自定義參數(shù)，傳遞給插件的so使用。
summary_profiles.summary_profile_name summary_profile的名稱(chēng)，可以在查詢(xún)語(yǔ)句中指定使用哪個(gè)。
summary_profiles.extractors summary extractor處理鏈的配置，extract summary時(shí)，按順序過(guò)一遍所有的extractor。
summary_profiles.parameters 用戶(hù)自定義參數(shù)，傳遞給summary_profile使用。
summary_profiles.field_configs 需要建立摘要的field的定義。
summary_profiles.max_summary_length highlight_prefix 可以指定關(guān)鍵字高亮顯示，摘要的長(zhǎng)度限制等。
配置例子：
"summary_profile_config" : {
"required_attribute_fields" : ["aux_field1", "aux_field2", "attr_field"],1
"modules" : [
{
"module_name" : "ha3_summary_eg",
"module_path" : "libha3_summary_eg.so",
"parameters" : {
"key" : "value"
}
}
],
"summary_profiles" : [
{
"summary_profile_name": "DefaultProfile",
"extractors" :[
{
"extractor_name" : "SmartSummaryExtractor",
"module_name" : "ha3_summary_eg",
"parameters" : {
"key": "value"
}
},
{
"extractor_name" : "DefaultSumamryExtractor",
"module_name" : "",
"parameters" : {}
}
],
"field_configs" : {
"TITLE" : {
"max_snippet" : 1,
"max_summary_length" : 40,
"highlight_prefix": "<font color=red>",
"highlight_suffix": "</font>",
"snippet_delimiter": "..."
},
"BODY" : {
"max_snippet" : 2,
"max_summary_length" : 100,
"highlight_prefix": "<font color=red>",
"highlight_suffix": "</font>",
"snippet_delimiter": "..."
}
}
}
]
}function_config
配置集群用到的function_expression插件信息，這部分為可選配置。具體參數(shù)含義如下：
"function_config" :
{
"modules" : [
{
"module_name" : "func_module_name",
"module_path" : "libfunction_expression_plugin.so",
"parameters" :
{
"config_path" : "pluginsConf/one_function.json"
}
}
]
}searcher_cache_config
searcher cache是用于cache第一階段查詢(xún)的結(jié)果
"searcher_cache_config" :
{
"max_size" : 1024, /* M byte */
"max_item_num" : 200000,
"inc_doc_limit" : 1000,
"inc_deletion_percent" : 1,
"latency_limit" : 1, /* ms */
"min_allowed_cache_doc_num" : 0,
"max_allowed_cache_doc_num" : 50000
}max_size max_size用于指定Searcher Cache的最大內(nèi)存使用空間，單位為 M 字節(jié)，默認(rèn)值為 1024 M bytes。
max_item_num max_item_num用于指定Searcher Cache的初始化時(shí)item的個(gè)數(shù)。cache的底層是一個(gè)hash table，max_item_num用于初始化hash_table，而cache中實(shí)際的item個(gè)數(shù)是運(yùn)行時(shí)根據(jù)實(shí)際的item大小和cache總的內(nèi)存限制決定的，因此這個(gè)配置值只是一個(gè)幫助cache初始化的值，一般情況下可以忽略這個(gè)配置項(xiàng)，默認(rèn)值是200000。
inc_doc_limit 在有增量的情況下，如果某個(gè)query命中了Searcher Cache，那么需要將cache中結(jié)果和在增量部分（相對(duì)于該query上一次進(jìn)cache時(shí)增量的doc）中查詢(xún)的結(jié)果進(jìn)行合并后返回給用戶(hù)，當(dāng)從增量部分查到的結(jié)果數(shù)大于 inc_doc_limit 時(shí)，則將該query在cache中的結(jié)果主動(dòng)失效，下次查詢(xún)?cè)搎uery時(shí)重新填充cache。默認(rèn)值是1000。
inc_deletion_percent 增量的刪除會(huì)導(dǎo)致原本在cache中的部分結(jié)果可能已經(jīng)失效（被刪除或更新）,當(dāng)失效的doc占cache中緩存的結(jié)果總數(shù)的百分比超過(guò) inc_deletion_percent% 時(shí)，同樣需要將這個(gè)cache結(jié)果主動(dòng)失效，而且當(dāng)前這次查詢(xún)會(huì)被當(dāng)成是一次cache miss，從而重新查詢(xún)當(dāng)前query并填充cache。默認(rèn)值是1。
latency_limit Searcher Cache只會(huì)緩存 (rank_latency + rerank_latency) > latency_limit 的query的查詢(xún)結(jié)果，因?yàn)楸籧ache住的query的latency越大，cache對(duì)性能提升的效果越明顯。單位時(shí)ms，默認(rèn)值是1ms。
min_allowed_cache_doc_num和max_allowed_cache_doc_num 分別用于設(shè)置允許進(jìn)入cache的結(jié)果數(shù)的最小值、最大值，以便應(yīng)對(duì)極端場(chǎng)景下走cache的開(kāi)銷(xiāo)，默認(rèn)值是0和std::numeric_limits<uint32_t>::max()
service_degradation_config
service_degradation_config是控制服務(wù)降級(jí)的配置，用于在服務(wù)異常或者流量暴增的情況下維護(hù)系統(tǒng)的穩(wěn)定運(yùn)作，示例如下：
"service_degradation_config" :
{
" condition" : {
"worker_queue_size_degrade_threshold" : 100,
"worker_queue_size_recover_threshold" : 10,
"duration" : 1000
},
"request" : {
"rank_size" : 5000,
"rerank_size" : 200
}
}配置服務(wù)降級(jí)主要分為兩部分，服務(wù)降級(jí)的檢測(cè)標(biāo)準(zhǔn)以及判斷為服務(wù)降級(jí)后的降級(jí)措施：
檢測(cè)標(biāo)準(zhǔn)：檢測(cè)服務(wù)需要降級(jí)的主要依據(jù)是當(dāng)前worker的工作隊(duì)列長(zhǎng)度，當(dāng)長(zhǎng)度持續(xù)duration ms大于worker_queue_size_degrade_threshold時(shí)，服務(wù)進(jìn)入降級(jí)狀態(tài)，在降級(jí)狀態(tài)下持續(xù)duration ms小于worker_queue_size_recover_threshold時(shí)，恢復(fù)為不降級(jí)狀態(tài)。特別的，在降級(jí)狀態(tài)下，如果隊(duì)列長(zhǎng)度小于worker_queue_size_recover_threshold，則該query不降級(jí)，這樣在降級(jí)狀態(tài)下隊(duì)列長(zhǎng)度會(huì)在worker_queue_size_recover_threshold上下波動(dòng)。
降級(jí)措施：目前只支持改寫(xiě)請(qǐng)求的rank_size以及rerank_size,即粗排和精排的條數(shù)，通過(guò)減小計(jì)算規(guī)模來(lái)降低請(qǐng)求的消耗時(shí)間，在rank_service架構(gòu)下只有rank_size 生效。
multi_call_config
ha3 3.2.0之前的版本參考如下流控配置，從3.2.0開(kāi)始流控邏輯做了較大重構(gòu)，字段由"anomaly_process_config"改為"multi_call_config"，例如：
"multi_call_config" : {
"probe_percent" : 0.3,
"latency_upper_limit_percent" : 0.4,
"begin_degrade_latency" : 100,
"full_degrade_latency" : 150,
"et_trigger_percent" : 0.8,
"et_wait_time_factor" : 5,
"et_min_wait_time" : 30,
"retry_trigger_percent" : 0.6,
"retry_wait_time_factor" : 3
}具體配置選項(xiàng)參考gig文檔。老版本配置說(shuō)明如下： 服務(wù)穩(wěn)定性可以在每個(gè)cluster里單獨(dú)配置，具體的配置項(xiàng)如下：
"anomaly_process_config" :
{
"flowControlEnabled" : true,
"earlyTerminationEnabled" : true,
"retryQueryEnabled" : true,
"flowControl" : {
"sample_interval" : 100,
"min_sample_count" : 10,
"heavy_load_arpc_error_ratio" : 0.5,
"light_load_arpc_error_ratio" : 0,
"max_flow_redirect" : 1,
"queue_size_threshold" : 5,
"flow_control_categories" : [1,2,3,4,5,6,7,8,9,10,11]
},
"detection" : {
"early_termination_trigger_result_percent" : 0.8,
"early_termination_wait_time_factor" : 3,
"retry_query_trigger_result_percent" : 0.8,
"retry_query_wait_time_factor" : 1
}
}searcher流量控制功能開(kāi)關(guān)
查詢(xún)提前結(jié)束功能開(kāi)關(guān)
重查功能開(kāi)關(guān)
流量控制的相關(guān)配置，目前其也包含searcher健康狀態(tài)監(jiān)控的相關(guān)參數(shù)
健康狀態(tài)的更新間隔，單位ms
最少需要sample查詢(xún)個(gè)數(shù)。這個(gè)參數(shù)主要判斷ARPC錯(cuò)誤的比例，如果一個(gè)健康狀態(tài)更新間隔現(xiàn)，查詢(xún)數(shù)量不夠，則繼續(xù)累積。
當(dāng)ARPC查詢(xún)錯(cuò)誤個(gè)數(shù)大于這個(gè)比例時(shí)，searcher的健康狀態(tài)需要降級(jí)。
當(dāng)ARPC查詢(xún)錯(cuò)誤個(gè)數(shù)小于這個(gè)比例時(shí)，searcher的健康狀態(tài)需要升級(jí)。
最多找備份searcher的個(gè)數(shù)。當(dāng)一列中的一個(gè)searcher處理不健康時(shí)，需要把分配給這個(gè)searcher的部分流量導(dǎo)到其它同列searcher中。這個(gè)參數(shù)決定當(dāng)找多個(gè)同列searcher的結(jié)點(diǎn)仍沒(méi)有找到健康結(jié)點(diǎn)時(shí)，則丟失流量
queue_size是每次查詢(xún)從searcher機(jī)器上帶回來(lái)searcher的隊(duì)列長(zhǎng)度。根據(jù)這個(gè)隊(duì)列長(zhǎng)度，QRS或PROXY會(huì)更新searcher的健康狀態(tài)。這個(gè)值主要用于配置searcher健康狀態(tài)更改需要滿(mǎn)足條件。具體的算法如下：searcher的健康狀態(tài)共為11級(jí)，每一級(jí)健康狀態(tài)的更新條件是不一樣的。例如示例中queue_size_threshold為5，其健康狀態(tài)更新的隊(duì)列長(zhǎng)度對(duì)應(yīng)的數(shù)組為q=[5,10,15,20,25,30,35,40,45,50,55], searcher健康度降級(jí)：queue_size >= q[10-H_c+1], searcher健康度升級(jí)：queue_size < q[10-H_c]，其中H_c是searcher當(dāng)前處于健康值0<= H_c <= 10
健康狀態(tài)更新的隊(duì)列長(zhǎng)度對(duì)應(yīng)數(shù)組的高級(jí)控制配置項(xiàng)，<10>是一個(gè)簡(jiǎn)單線性展開(kāi)的配置方法。當(dāng)配置這個(gè)數(shù)組時(shí)，將覆蓋<10>
配置觸發(fā)查詢(xún)提前結(jié)束檢測(cè)應(yīng)滿(mǎn)足的結(jié)果個(gè)數(shù)比例，例如查10列的內(nèi)容，如果8列結(jié)果已經(jīng)返回，則開(kāi)始觸發(fā)查詢(xún)提前結(jié)果檢測(cè)。
查詢(xún)提前結(jié)束應(yīng)等待的時(shí)間。假設(shè)查詢(xún)提前結(jié)束檢測(cè)被觸發(fā)時(shí)使用的時(shí)間為T(mén)，如果再等待3t的時(shí)間，結(jié)果還不完整，則這時(shí)會(huì)提前結(jié)束查詢(xún)處理并返回結(jié)果。如果在等待的期間結(jié)果已經(jīng)完整，則結(jié)果正常返回。t為第一個(gè)正常返回結(jié)果所需的時(shí)間。
配置觸發(fā)查詢(xún)重查檢測(cè)應(yīng)滿(mǎn)足的結(jié)果個(gè)數(shù)比例，例如查10列的內(nèi)容，如果8列結(jié)果已經(jīng)返回，則開(kāi)始觸發(fā)重查檢測(cè)。
配置查詢(xún)重查應(yīng)等待的時(shí)間。假設(shè)查詢(xún)重查檢測(cè)被觸發(fā)時(shí)使用的時(shí)間為T(mén)，如果再等待t的時(shí)間，結(jié)果還不完整，則這時(shí)會(huì)向同列另一個(gè)searcher發(fā)送查詢(xún)請(qǐng)求。如果在等待的期間結(jié)果已經(jīng)完整，則結(jié)果正常返回。t為第一個(gè)正常返回結(jié)果所需的時(shí)間。
cava_config
ha3 高級(jí)語(yǔ)言腳本相關(guān)配置, ha3 支持用戶(hù)通過(guò)cava腳本寫(xiě)插件,下面是相關(guān)配置
"cava_config" : {
"enable" : true, (1)
"ha3_cava_conf" : "../binary/usr/local/etc/cava/config/cava_config.json", (2)
"lib_path" : "cava/lib",(3)
"source_path" : "cava/src",(4)
"code_cache_path" : "cava/cache",(5)
"pool_trunk_size" : 10, //MB (6)
"pool_recycle_size_limit" : 20, //MB (7)
"alloc_size_limit" : 40, //MB (8)
"init_size_limit" : 1024, //MB (9)
"module_cache_size" : 100000 (10)
}(1)是否啟用cava功能
(2)cava語(yǔ)言配置
(3)平臺(tái)方提供的公共庫(kù),upc時(shí)編譯生效
(4)業(yè)務(wù)方提供的自定義插件,可以復(fù)用平臺(tái)方提供的公共庫(kù),upc時(shí)編譯生效
(5)提前編譯進(jìn)code cache的插件代碼,不會(huì)被cache淘汰,并且不能被別人引用
(6)cava內(nèi)存池trunk_size,默認(rèn)值10MB,無(wú)需用戶(hù)修改
(7)cava內(nèi)存池recycle_size,默認(rèn)值20MB,無(wú)需用戶(hù)修改
(8)cava query級(jí)別能分配的最大內(nèi)存
(9)cava 整體最多可以使用多大內(nèi)存,不包括上述query級(jí)別的內(nèi)存
(10)最多緩存query里面?zhèn)鬟fsource code的個(gè)數(shù),超過(guò)則開(kāi)始LRU淘汰
關(guān)于cava 的詳細(xì)介紹后續(xù)會(huì)有單獨(dú)章節(jié)來(lái)介紹
turing_options_config
turing_options_config可以覆蓋圖化相關(guān)的配置例如
"turing_options_config":{ "graph_config_path": “ssss”, // 圖的路徑 "dependency_table":[“a”,"b"] //依賴(lài)表等 }