導(dǎo)讀：今天和大家分享京東零售OLAP平臺(tái)的建設(shè)和場(chǎng)景的實(shí)踐，主要包括四大部分：

• 管控面建設(shè)
• 優(yōu)化技巧
• 典型業(yè)務(wù)
• 大促備戰(zhàn)

01管控面建設(shè)

1. 管控面介紹

管控面可以提供高可靠高效可持續(xù)運(yùn)維保障、快速部署小時(shí)交付的能力，尤其是針對(duì)ClickHouse這種運(yùn)維較弱但是性能很高的OLAP核心引擎，管控面就顯示得尤其重要。

2. 架構(gòu)設(shè)計(jì)

管控面的整體架構(gòu)設(shè)計(jì)如上圖所示，從開(kāi)始請(qǐng)求、域名解析和分流規(guī)則，到達(dá)后端服務(wù)adminServer，adminServer有一層校驗(yàn)層，校驗(yàn)完成后會(huì)向隊(duì)列中發(fā)送任務(wù)，worker會(huì)不斷地消費(fèi)隊(duì)列中的任務(wù)，消費(fèi)完成后會(huì)將任務(wù)的結(jié)果寫(xiě)到后端的存儲(chǔ)。如果有大量的集群的部署、配額的更改，就會(huì)有一系列的任務(wù)在這里完成。完成之后，再到數(shù)據(jù)部門進(jìn)行保存，這就是整體的架構(gòu)設(shè)計(jì)。

3. 業(yè)務(wù)管理

在業(yè)務(wù)管理方面，管控面可以提供以下功能：

• 可以用于用戶的集群賬號(hào)的申請(qǐng)；
• 業(yè)務(wù)級(jí)別的登記；
• 用戶可以進(jìn)行配額查詢，這些配額主要包括查詢數(shù)、執(zhí)行的并發(fā)以及超時(shí)等；
• 用戶可以自定義監(jiān)控告警，通過(guò)這些監(jiān)控告警去實(shí)時(shí)探索自己的整體服務(wù)的可靠性和穩(wěn)定性；
• 慢查詢統(tǒng)計(jì)告警，可以通過(guò)管控面看到當(dāng)前集群業(yè)務(wù)有多少慢查詢以及錯(cuò)誤的查詢、查詢的總數(shù)等。

4. 運(yùn)維管理

在運(yùn)維管理方面：

• 第一，可以進(jìn)行新集群的部署，比如物理資源或者容器資源已經(jīng)申請(qǐng)好之后，可以及時(shí)進(jìn)行創(chuàng)建資源，并及時(shí)給用戶使用；
• 第二，比如ClickHouse有節(jié)點(diǎn)故障時(shí)（例如硬件故障如CPU、內(nèi)存或磁盤故障），要進(jìn)行及時(shí)的節(jié)點(diǎn)上下線或者節(jié)點(diǎn)替換，否則就會(huì)影響整個(gè)集群，一是影響DDL，二是影響寫(xiě)入。
• 第三，可以做配額的管控，這一點(diǎn)在大促中非常有用，它可以用于限制用戶的查詢數(shù)、并發(fā)還有超時(shí)等，防止突增的流量，導(dǎo)致集群的不穩(wěn)定。
• 第四，可以進(jìn)行集群的巡檢，集群巡檢之后，可以查看每個(gè)集群的服務(wù)狀態(tài)，比如它是否可以創(chuàng)建表、刪除表、插入數(shù)據(jù)、查詢數(shù)據(jù)是否都正常等，也有實(shí)時(shí)告警集群巡檢的服務(wù)狀態(tài)。

以上就是我們京東零售OLAP管控面核心功能，它在集群運(yùn)維方面不僅提升集群交付的效率，還節(jié)約運(yùn)維的成本。

02優(yōu)化技巧

1. 場(chǎng)景難點(diǎn)

京東零售是以電商交易和用戶流量為核心的場(chǎng)景，有以下兩方面難點(diǎn)：

• 第一點(diǎn)是交易的業(yè)務(wù)比較復(fù)雜，需要關(guān)聯(lián)多張表、sql中的邏輯多，另外就是數(shù)據(jù)會(huì)實(shí)時(shí)更新，比如交易的狀態(tài)和金額的變化、組織架構(gòu)的變化等；
• 第二點(diǎn)是流量數(shù)據(jù)，它有個(gè)特點(diǎn)，首先追加不修改，其次是量大，因?yàn)榘擞脩舻狞c(diǎn)擊和瀏覽等各類行為的數(shù)據(jù)，以及衍生的各種指標(biāo)，比如UV的計(jì)算。最后是它的數(shù)據(jù)質(zhì)量也會(huì)經(jīng)常變化。

針對(duì)以上場(chǎng)景難點(diǎn)，我們主要用到了實(shí)時(shí)的數(shù)據(jù)更新，還有物化視圖、join的優(yōu)化。接下來(lái)通過(guò)一些具體案例詳細(xì)講解。

2. 實(shí)時(shí)數(shù)據(jù)更新

首先看一下實(shí)時(shí)數(shù)據(jù)更新。我們創(chuàng)建了兩張表，一張是本地表，還有一張是分布式表。

本地表主要采用ReplacingMergeTree去重的引擎，字段分別是create_time創(chuàng)建時(shí)間、ID、comment注釋，還有數(shù)據(jù)的版本，分區(qū)是創(chuàng)建時(shí)間進(jìn)行格式化得到的天分區(qū)，然后按照ID進(jìn)行排序鍵去重。現(xiàn)在的需求是對(duì)相同的ID進(jìn)行實(shí)時(shí)的數(shù)據(jù)更新。

我們?cè)诩旱膬蓚€(gè)分片中，比如分片1插入了三條數(shù)據(jù)，分片2插入了三條數(shù)據(jù)都是相同的ID（0），但是查詢分布式表發(fā)現(xiàn)，數(shù)據(jù)并沒(méi)有去重。

第一種解決方式是使用optmize去重。通過(guò)執(zhí)行一個(gè)optmize去重之后，通過(guò)查詢本地表就發(fā)現(xiàn)optmize在多分區(qū)間和分片間不能去重，只能在同一個(gè)分區(qū)中去重。

第二種方式是使用final去重。通過(guò)查詢一個(gè)本地表的final，發(fā)現(xiàn)剛才的11日和12日的數(shù)據(jù)只保留了一條數(shù)據(jù)，這時(shí)再通過(guò)查詢分布式表final去重，發(fā)現(xiàn)有兩條12日的數(shù)據(jù)，所以我們的結(jié)論是final的方式在多個(gè)分區(qū)間可以去重，但是在多分片間不能去重。

因?yàn)槲覀兊募憾际嵌喾制?，所以還有第三種方式——使用argMax。我們通過(guò)argMax加了一個(gè)數(shù)據(jù)的版本，可以選擇最大的一個(gè)版本號(hào)，然后通過(guò)去查詢分布式表，發(fā)現(xiàn)argMax可以在多分片間去重，這也是我們推薦使用的一種方式。

所以實(shí)時(shí)數(shù)據(jù)更新方式一般有以上三種，但是各種方案更新的范圍不同，我們可以根據(jù)自己的業(yè)務(wù)場(chǎng)景去使用不同的去重方式，optmize可以在分區(qū)范圍內(nèi)去重，final可以在本地表范圍內(nèi)驅(qū)動(dòng)，而argMax可以在分布式表范圍內(nèi)去重。

3. 物化視圖

接下來(lái)，我們看一下物化視圖。使用物化視圖的場(chǎng)景，比如：業(yè)務(wù)最近3小時(shí)看小時(shí)的數(shù)據(jù)，三天之前想看天粒度的數(shù)據(jù)，這時(shí)候物化視圖，就是很好的選擇。那么物化視圖該如何使用？我們看一下這個(gè)案例，有一張明細(xì)表test，它大概有13億行左右，直接實(shí)時(shí)的count聚合進(jìn)行查詢，發(fā)現(xiàn)它的耗時(shí)大概是2.1秒左右，怎樣能讓查詢變得更快一些？

我們創(chuàng)建了一張物化視圖，對(duì)原始表進(jìn)行預(yù)聚合，物化視圖選用了SummingMergeTree，這是聚合的一種引擎，大家也可以選擇其他引擎去聚合。它會(huì)根據(jù)排序鍵進(jìn)行二次聚合，也就是 Date 字段。還有一個(gè)select語(yǔ)句，它的作用是通過(guò)批次寫(xiě)入，把這個(gè)select語(yǔ)句寫(xiě)入到物化視圖列表中。

我們創(chuàng)建物化視圖之后，再去執(zhí)行相同的語(yǔ)句，查詢性能提升了大概113倍，耗時(shí)0.002秒左右，所以物化視圖在比如量大而且可以預(yù)聚合的這種場(chǎng)景下非常好用。

那么物化視圖就又是什么原理能夠達(dá)到這樣的效果?整體如圖所示。

物化視圖會(huì)創(chuàng)建一個(gè)隱藏的內(nèi)表來(lái)保存視圖里面的數(shù)據(jù)，然后物化視圖會(huì)將寫(xiě)入原始表的數(shù)據(jù)，也就是通過(guò)select第一次聚合后的結(jié)果，寫(xiě)入物化視圖的內(nèi)表中列表，再根據(jù)排序鍵進(jìn)行二次聚合，這樣原始表的數(shù)據(jù)量會(huì)大量減少，查詢就可以得到加速。

4. join優(yōu)化

在正式介紹join優(yōu)化前先補(bǔ)充一點(diǎn)基礎(chǔ)知識(shí)：對(duì)本地表的查詢我們稱之為部分查詢，以下劃線L為結(jié)尾的表稱為本地表。在做這種優(yōu)化之前，先看一下整體的分布式表執(zhí)行的流程。

首先分布式表會(huì)將查詢拆分成對(duì)本地表的查詢。比如city在精確去重之后，查詢分布式表，通過(guò)路由下發(fā)到各個(gè)分片的本地表上面進(jìn)行查詢，然后第一個(gè)接收到的查詢的節(jié)點(diǎn)，再將本地的查詢部分的結(jié)果進(jìn)行合并，返回給用戶，這是整體分布式表執(zhí)行的流程。

join的執(zhí)行過(guò)程如上圖所示。比如select id, name, score from student join score，首先展開(kāi)分布式表，向每個(gè)分片分發(fā)請(qǐng)求，計(jì)算左表的每個(gè)本地表join的結(jié)果，第二步當(dāng)分片收到1中的請(qǐng)求后，需要計(jì)算右表的結(jié)果，向每個(gè)分片再發(fā)送請(qǐng)求。這樣假如集群有100個(gè)分片，就需要100×100的部分查詢，每一次展開(kāi)都要通過(guò)磁盤網(wǎng)卡，都會(huì)有耗時(shí)。

第一種優(yōu)化是global join。在原始的查詢中，會(huì)先計(jì)算右表結(jié)果，展開(kāi)第一個(gè)分布式表，然后合并，成為一個(gè)臨時(shí)表，假設(shè)命名為b_004，這是第一次展開(kāi)。第二次展開(kāi)時(shí)，它會(huì)將臨時(shí)表b_004發(fā)送，所有的分片計(jì)算部分的join結(jié)果，就是第二次展開(kāi)的分布式表，然后第三步，合并2中的結(jié)果，為最終的結(jié)果。這樣整體的global join就是，假如我們有100個(gè)分片，就只需要2×100次的部分查詢，大大減少了查詢。

第二種優(yōu)化方案就是本地join，將右表的分布式表改成本地表。這種方式的執(zhí)行流程是，我們展開(kāi)左表，只需要把左表的分布式表下發(fā)到各個(gè)分片上面，而右邊它本身就是本地表，就直接進(jìn)行合并計(jì)算，最后會(huì)合并整個(gè)部分結(jié)果即為最終的結(jié)果。假如總共有100個(gè)分片，只需要展開(kāi)100次，下發(fā)每個(gè)分片，100次的查詢就行了，這樣就減少了帶寬消耗，提升了性能。

可以優(yōu)先使用本地join，其次是global join，最后要小表放在右邊，這樣就可以提升join的性能。

以上就是我們針對(duì)業(yè)務(wù)場(chǎng)景難點(diǎn)的一些優(yōu)化技巧。

03典型業(yè)務(wù)

我們也希望實(shí)現(xiàn)高并發(fā)查詢，有大吞吐的寫(xiě)入，但是ClickHouse在默認(rèn)的配置下，不支持高并發(fā)的查詢，而且寫(xiě)入也很慢，這是我們業(yè)務(wù)上的兩大痛點(diǎn)。下面具體看一下兩種場(chǎng)景。

1. 高并發(fā)查詢

以廣告實(shí)時(shí)跟單項(xiàng)目為例，它是用于實(shí)時(shí)產(chǎn)生廣告效果，最終數(shù)據(jù)報(bào)表展示，幫助廣告主執(zhí)行營(yíng)銷計(jì)劃落地。如圖所示，可以看到每秒的QPS達(dá)到將近2000，這是618時(shí)候的一個(gè)截圖。我們的集群整體的配置是7分片6副本1進(jìn)程，硬件的配置是42臺(tái)32C128G，900G*3的SSD的磁盤，整個(gè)集群的QPS可以達(dá)到2000。當(dāng)然這個(gè)配置如果要達(dá)到2000的話，我們要進(jìn)行一系列的技術(shù)優(yōu)化。

首先第一點(diǎn)技術(shù)優(yōu)化就要增加副本，因?yàn)樵黾痈北究梢蕴嵘麄€(gè)集群的并發(fā)能力。第二是max_threads，減少每一個(gè)查詢所用的線程數(shù)，ClickHouse如果不設(shè)置這個(gè)參數(shù)，會(huì)用物理內(nèi)核的所有線程去進(jìn)行查詢，這樣就會(huì)導(dǎo)致有些任務(wù)無(wú)法調(diào)度，所以要設(shè)置這個(gè)參數(shù)。第三就是要調(diào)整query_thread_log的存儲(chǔ)，因?yàn)榇罅康腝PS過(guò)來(lái)，會(huì)有很多的請(qǐng)求日志，如果我們不調(diào)整存儲(chǔ)，很快就會(huì)將磁盤打滿，造成集群的不可用。

上圖展示了優(yōu)化前后的最大穩(wěn)定運(yùn)行并發(fā)數(shù)。優(yōu)化前，大概只能達(dá)到1000QPS，同樣的集群下優(yōu)化后可以穩(wěn)地運(yùn)行在2000QPS左右，可以滿足業(yè)務(wù)需求。

2. 大吞吐寫(xiě)入

第二個(gè)典型業(yè)務(wù)是大吞吐的寫(xiě)入。以京東云監(jiān)控項(xiàng)目為例，它負(fù)責(zé)京東云負(fù)載均衡訪問(wèn)日志的存儲(chǔ)，日志量極其大，單集群寫(xiě)作的峰值可以達(dá)到6000億條/天，還可以保持?jǐn)?shù)據(jù)的強(qiáng)一致?？梢钥吹郊喝粘４蟾攀?G/秒，大促可達(dá)到6G/秒。我們的集群配置是60分片兩副本1進(jìn)程，硬件配置是120臺(tái)64核的256G1T*1的SSD。這樣集群配置下，我們可以實(shí)現(xiàn)這6000億條每天的寫(xiě)入。為支持這個(gè)寫(xiě)入量，我們也需要一系列的技術(shù)優(yōu)化。

第一點(diǎn)就是引入了chproxy流量負(fù)載均衡，請(qǐng)求粒度細(xì)化至每條sql，這樣每一個(gè)sql請(qǐng)求都會(huì)路由到不同的節(jié)。如果不引入chproxy，就會(huì)通過(guò)域名的方式直連客戶端，直連集群，如果連接不及時(shí)釋放，就會(huì)一直往節(jié)點(diǎn)里寫(xiě)，很容易就把集群?jiǎn)喂?jié)點(diǎn)打爆了。引入了chproxy的流量負(fù)載平衡之后，sql就可以均衡地路由到各個(gè)節(jié)點(diǎn)。

第二點(diǎn)就是本地表的寫(xiě)入，可以提升整體的寫(xiě)入性能，大概是分布式表的兩到三倍左右。

最后我們看一下優(yōu)化前后，每天最大的寫(xiě)入量，優(yōu)化前大概是1000億每天，優(yōu)化后可以達(dá)到6000億每天，這樣就實(shí)現(xiàn)了大吞吐的寫(xiě)入。

04大促備注

電商場(chǎng)景下，經(jīng)常遇到大促備戰(zhàn)，需要保證olap服務(wù)的穩(wěn)定性。

大促備戰(zhàn)的整體流程如圖所示，我們?cè)诓煌臅r(shí)間段需要做不同的事情。一開(kāi)始是啟動(dòng)備戰(zhàn)制定備戰(zhàn)方案，收集業(yè)務(wù)的資源需求，梳理業(yè)務(wù)等級(jí)，接下來(lái)是集群的擴(kuò)容壓測(cè)，還有故障演練優(yōu)化等，最后迎來(lái)開(kāi)門紅，決戰(zhàn)618。

我們的OLAP是如何保證業(yè)務(wù)的呢？

第一，業(yè)務(wù)資源收集以及等級(jí)確認(rèn)。大促前，我們平臺(tái)會(huì)向業(yè)務(wù)收集有資源的需求以及等級(jí)確認(rèn)，并做合理的規(guī)劃和分配，來(lái)保障大促的流量急增時(shí)有足夠的資源支撐運(yùn)轉(zhuǎn)。比如資源需求，可能有新上線的業(yè)務(wù)、擴(kuò)容的業(yè)務(wù)、遷移的業(yè)務(wù)，還有替換已有集群的業(yè)務(wù)，這些都是我們大促之前要進(jìn)行梳理的，這樣可以提前做好預(yù)案。

第二，業(yè)務(wù)方要及時(shí)的訂閱監(jiān)控和報(bào)警。比如監(jiān)控有CH系統(tǒng)層的、服務(wù)層的，還有CH查詢和寫(xiě)入層的監(jiān)控。我們有兩個(gè)告警系統(tǒng)：一個(gè)是服務(wù)層的，比如監(jiān)控CH的一些重要的指標(biāo)，ZK的一些監(jiān)控告警，以及chproxy流量負(fù)載的一些監(jiān)控報(bào)警等；另一個(gè)是系統(tǒng)層的MDC告警，例如CPU、內(nèi)存、磁盤、連通性，這些主要是監(jiān)控硬件是否有故障。右圖就是報(bào)警和監(jiān)控的樣例，我們可以通過(guò)它們來(lái)及時(shí)修復(fù)集群故障，也需要業(yè)務(wù)方去訂閱這些監(jiān)控和報(bào)警，來(lái)一起監(jiān)督整個(gè)集群的穩(wěn)定性和可靠性。

大促集群是如何保障的呢？

第一點(diǎn)是壓測(cè)，我們要進(jìn)行高保真的一些壓測(cè)，壓測(cè)的結(jié)果，要設(shè)置合理的配額，比如我們共享集群的CPU一般是40%，獨(dú)占集群是80%，我們通過(guò)這些目標(biāo)值設(shè)置業(yè)務(wù)的合理的配額。如果壓測(cè)有問(wèn)題，我們可以及時(shí)的協(xié)助業(yè)務(wù)方進(jìn)行優(yōu)化，來(lái)滿足他們的QPS和集群的穩(wěn)定性。

第二點(diǎn)是故障演練。我們的故障演練有很多，其中第一就是雙流切換。比如我們的零級(jí)業(yè)務(wù)就是非常核心的業(yè)務(wù)，要進(jìn)行主備雙流，在不同的機(jī)房分別部署了兩個(gè)集群，如果同一個(gè)機(jī)房有問(wèn)題，要及時(shí)切到備用集群去。另外就是故障的修復(fù)。故障發(fā)生后，我們要通過(guò)管控面進(jìn)行及時(shí)下線或者替換，來(lái)保證集群的穩(wěn)定性和業(yè)務(wù)的可用性。

第三點(diǎn)就是降級(jí)措施。我們的降級(jí)措施會(huì)針對(duì)不同的業(yè)務(wù)等級(jí)進(jìn)行合理分配，尤其是大促的時(shí)候不參加壓測(cè)的業(yè)務(wù)。如果不參加壓測(cè)，我們就會(huì)在大促前期進(jìn)行業(yè)務(wù)降級(jí)，防止他們的突增流量影響大促核心業(yè)務(wù)，以保證大促時(shí)整體的集群穩(wěn)定性。

以上三點(diǎn)就是我們集群保障最核心的三個(gè)步驟，從一開(kāi)始的高保真壓測(cè)，到故障的演練，再到最后的降級(jí)措施，我們都會(huì)和業(yè)務(wù)方一起去完成，以保證整體穩(wěn)定運(yùn)行。

05精彩問(wèn)答

Q：請(qǐng)問(wèn)老師您在這個(gè)話題中遇到的最大的挑戰(zhàn)是什么？

A：我遇到的最大挑戰(zhàn)就是解決高并發(fā)的問(wèn)題，因?yàn)楦卟l(fā)瞬間QPS能達(dá)到2000以上，而我們的ClickHouse默認(rèn)就是100個(gè)并發(fā)。我們?cè)诟卟l(fā)方面做出了很多技術(shù)調(diào)優(yōu)，可以讓業(yè)務(wù)達(dá)到高并發(fā)的場(chǎng)景。高并發(fā)的場(chǎng)景，遇到過(guò)很多問(wèn)題，我們首先增加了多副本（一般默認(rèn)情況下就是三副本或者兩副本來(lái)保證數(shù)據(jù)的安全），因?yàn)槊吭黾右慌_(tái)副本，就可以提升整體的一個(gè)分片的查詢能力。我們還進(jìn)行了一些參數(shù)調(diào)優(yōu)，比如如果高并發(fā)過(guò)來(lái)，有很多的隊(duì)列，這些線程我們都要去控制好，不然很容易就無(wú)法調(diào)度了。另外，高并發(fā)場(chǎng)景會(huì)很容易把集群的一些日志給打滿，因?yàn)槲覀兊拿恳粭l查詢都會(huì)記錄一條日志，我們要把日志的表的存儲(chǔ)周期設(shè)置小一點(diǎn)。還要加快它的merge，因?yàn)槿绻患涌靘erge，刪除數(shù)據(jù)就很慢，也很容易將磁盤打滿，這是查詢?nèi)罩镜姆矫?。第三點(diǎn)就是高并發(fā)很容易觸發(fā)我們的一些配額的限制，我們要對(duì)它進(jìn)行一些放大。我們要進(jìn)行內(nèi)存的一些限制，如果不進(jìn)行這些限制，或者是不放大這些限制都會(huì)引發(fā)QPS達(dá)不到，造成整體的穩(wěn)定性和可用性不夠。

還有一個(gè)難點(diǎn)是join的優(yōu)化，效能優(yōu)化里面其中有一個(gè)是本地join，本地join我們也做了很多的測(cè)試。比如和字典表做對(duì)比，我們發(fā)現(xiàn)字典表在100萬(wàn)以下的數(shù)據(jù)量，就是使用字典表做join性能較好，100萬(wàn)以上我們發(fā)現(xiàn)用本地join就非常好，我們通過(guò)一系列的測(cè)試實(shí)驗(yàn)才得到這個(gè)結(jié)論。一開(kāi)始我們都是用字典表去進(jìn)行黃金眼刷，但是我們最后發(fā)現(xiàn)在一定的性能之上，字典表還不如本地表的join。大量的POC才得到了這個(gè)結(jié)論。所以大家在字典表和本地join，也可以自己做一下全面的性能測(cè)試。

以上就是我們的兩點(diǎn)挑戰(zhàn)。

Q：OLAP是什么？主要用哪些引擎？

A：OLAP是在線的多維高性能實(shí)時(shí)分析服務(wù)，專業(yè)術(shù)語(yǔ)就是在線聯(lián)機(jī)查，和mysql OLTP在線事務(wù)查詢是兩種不同的類型。OLAP主要面向海量數(shù)據(jù)。

我們京東零售主要用clickhouse為主、doris為輔的兩個(gè)引擎?，F(xiàn)在最流行的就是ClickHouse，其次是doris和druid這兩個(gè)引擎，但是現(xiàn)在很多大廠，包括騰訊阿里字節(jié)都在往ClickHouse上面轉(zhuǎn)，當(dāng)然京東零售也應(yīng)用ClickHouse兩三年了。我們也進(jìn)行了一系列的內(nèi)核的研發(fā)，解決一些zookeeper的性能，還有在線彈性伸縮系統(tǒng)的一些東西，因?yàn)镃lickHouse在彈性伸縮系統(tǒng)方面不太好，所以我們也在做這方面的工作。

Q：看到有一個(gè)業(yè)務(wù)場(chǎng)景中使用了120臺(tái)高配置的機(jī)器，那么如果申請(qǐng)到這么多的資源進(jìn)行業(yè)務(wù)支持，怎么考慮投入產(chǎn)出？

A：我們投入了120臺(tái)，產(chǎn)出就是可以把整個(gè)京東云的所有的負(fù)載均衡。第一，我們?yōu)槭裁匆?20臺(tái)，為什么要用SSD的機(jī)型？還有為什么這么高配的機(jī)器？因?yàn)樗膶?xiě)入量很大，平均每天大概6000億，算出每秒大概有1000萬(wàn)的數(shù)據(jù)量在往集群里寫(xiě)，如果不用這么高配的機(jī)器，磁盤已經(jīng)是SSD了，它的性能永遠(yuǎn)達(dá)不到這個(gè)效果。第二點(diǎn)就是投入產(chǎn)出比，我們可以通過(guò)這個(gè)集群監(jiān)控整個(gè)京東云的日志，還有負(fù)載均衡的效果。比如京東云，一是對(duì)外，二是對(duì)內(nèi)，監(jiān)控和負(fù)載均衡都是非常重要的，所以用了我們的京東零售的OLAP來(lái)實(shí)監(jiān)控京東云的一個(gè)整體效果，還有整體穩(wěn)定性，這樣產(chǎn)出比就非常大。

Q：主備庫(kù)切換時(shí)數(shù)據(jù)有延遲嗎，如何做到讓用戶感知最??？

A：主備庫(kù)切換，我們采用的是雙寫(xiě)的流程，我們核心的業(yè)務(wù)都是雙寫(xiě)的，就算在日常也都是雙寫(xiě)，然后分流去查詢，不會(huì)造成主備儲(chǔ)備的集群的空閑。大促的時(shí)候，會(huì)采用一個(gè)百分比，比如說(shuō)或者100%在主機(jī)型另一個(gè)集群就是當(dāng)做備用，或者是會(huì)按照一定的比例80%-20%左右采用雙寫(xiě)。業(yè)務(wù)方切換的時(shí)候基本上沒(méi)有任何延遲，只是將域名切換了一下，數(shù)據(jù)都是在實(shí)時(shí)寫(xiě)入，兩個(gè)集群，基本上沒(méi)有延遲。這是我們準(zhǔn)備切換的一個(gè)功能。

Q：想問(wèn)一下咱們的調(diào)優(yōu)過(guò)程是怎么樣的？

A：我們的調(diào)優(yōu)過(guò)程先是結(jié)合自己的經(jīng)驗(yàn)，去優(yōu)化一些參數(shù)，業(yè)務(wù)再進(jìn)行壓測(cè)。因?yàn)橄脒_(dá)到這么大的QPS和這么高的大吞吐的寫(xiě)入，要時(shí)常進(jìn)行壓測(cè)，壓測(cè)時(shí)如果遇到問(wèn)題，會(huì)進(jìn)行內(nèi)核源碼的分析，然后再進(jìn)行一系列參數(shù)調(diào)優(yōu)或者內(nèi)核優(yōu)化。

今天的分享就到這里，謝謝大家。