當前位置：首頁 > 科技 > 軟件

常用性能優(yōu)化手段及在風控系統(tǒng)中的應用

來源：責編：時間：2023-10-26 17:12:26 369觀看

導讀引言性能優(yōu)化是個恒久的話題，隨著產(chǎn)品的演進，業(yè)務的增長，系統(tǒng)能力總有達到瓶頸的一天，它不可或缺的陪伴著我們走向壯大再走向衰敗，是我們面臨的不可回避的問題。下圖1展示了風控系統(tǒng)近半年來承載流量的增長趨勢，可見最近半

引言

性能優(yōu)化是個恒久的話題，隨著產(chǎn)品的演進，業(yè)務的增長，系統(tǒng)能力總有達到瓶頸的一天，它不可或缺的陪伴著我們走向壯大再走向衰敗，是我們面臨的不可回避的問題。下圖1展示了風控系統(tǒng)近半年來承載流量的增長趨勢，可見最近半年來流量高速增長，且對于可預見的未來而言，接入流量還會持續(xù)高增。伴隨著流量的增長，系統(tǒng)各方面--存儲、計算、IO等都表現(xiàn)出一定的瓶頸，通過原始簡單的水平擴容并不能解決所有的問題，而且還會帶來成本的上升。因此，我們近期對系統(tǒng)進行了一系列優(yōu)化改造，目的是滿足未來一段時間內(nèi)業(yè)務的增長使用，降低接口的耗時滿足某些延時敏感型業(yè)務的需要，同時也伴隨著一定的IT成本優(yōu)化。本文結合常見的性能優(yōu)化手段(預取、批量、異步、壓縮、緩存)，及在風控系統(tǒng)中的實踐進行總結，希望能給讀者對于性能優(yōu)化實踐帶來一些參考。

圖1：風控引擎流量增長趨勢

預取——特征預計算

預取作為一種提速手段，通常與緩存搭配使用，在緩存空間換時間的基礎上更進一步，以時間換時間，通過預加載來提升性能。常見的使用有，數(shù)據(jù)庫從磁盤加載頁時的預讀多個頁減少磁盤IO、CPU緩存加載一片連續(xù)的內(nèi)存空間提高計算的速度，也就是我們常說的CPU對數(shù)組友好對鏈表不友好的原因。

在Gaia風控引擎中，一次業(yè)務請求在引擎內(nèi)部的執(zhí)行流程如下圖2所示，會經(jīng)歷場景因子(特征)->規(guī)則->決策的計算過程，而計算因子是整個鏈路最耗時的部分，通常占請求響應時間的70%以上，包括對賬號信息、名單庫、模型數(shù)據(jù)、用戶畫像、設備指紋、三方特征等多個下游的讀擴散–特征因子獲取，加上場景的上百條規(guī)則執(zhí)行，請求耗時常規(guī)在250ms左右，這也是22年中以前我們承諾給主站大部分業(yè)務的響應時間，直到電商業(yè)務的接入，對我們引擎的響應時間提出了100ms以內(nèi)響應的要求，迫使我們對引擎進行了一些優(yōu)化，其中之一就是近線引擎帶來的特征預取優(yōu)化，其演進流程如下圖3示：

圖2：風控引擎一次請求執(zhí)行過程

圖3：風控特征獲取流程

基于一個前提：對同一個主體，按照其行為時序數(shù)據(jù)消費，slb數(shù)據(jù)源消費處理完成大多數(shù)時候都要比業(yè)務請求風控早。因此，我們通過對slb實時流數(shù)據(jù)消費預讀取下游特征，并將結果緩存在redis中，當業(yè)務請求風控時，直接獲取redis的數(shù)據(jù)，避免或減少rpc回源特征，以此來降低風控接口的耗時。

通過這套機制，我們按照特征變動頻率對特征分層設置不同的緩存時間，同時在一些對數(shù)據(jù)一致性要求較低的場景對特征開啟緩存讀，其緩存命中率能達到90%以上，核心業(yè)務場景如電商交易，接口響應耗時從80ms下降到25ms。

圖4：特征緩存命中率

圖5：電商交易場景請求風控接口TP99耗時曲線圖

批量——特征批量獲取

批量一般是對I/O操作的優(yōu)化，同樣可看作是時間換時間，通過合并、批量進行讀取或?qū)懭胍詼p少對I/O的操作來提升吞吐和性能。常見的使用有，kafka消費數(shù)據(jù)的時候批量拉取指定的數(shù)據(jù)條數(shù)，mysql寫入redolog/binlog時的組提交(group commit)機制，都是通過批量的優(yōu)化來減少I/O提升性能的。

在Gaia引擎中最常用的特征為對賬號管控/風控名單值的獲取，一次業(yè)務風險判斷請求會涉及到對請求主體(mid、buvid、ip、ua)的各種黑/白名單值獲取，以主體mid為例，往往會并發(fā)調(diào)用下游名單接口多次，判斷mid是否在同設備多賬號黑名單、虛假賬號黑名單、通用白名單等名單中，從而形成不同的因子供規(guī)則使用，這種方式就會造成對同下游的同接口的讀擴散流量放大浪費資源，且要保持下游接口低延遲往往需要下游進行擴容保證CPU等資源使用率在一定的水位以下。因此，為了降低自身及下游的服務資源和I/O，優(yōu)化的手段就是將多次請求合并為一次請求，其優(yōu)化流程如下圖6所示：

圖6：名單類因子讀取優(yōu)化流程

通過將多次獨立下游請求獲取給定黑/白名單轉(zhuǎn)化為一次批量請求獲取主體所有有效名單，同時結合本地內(nèi)存判斷因子請求名單與所有名單是否有交集來實現(xiàn)原有相同的功能，并通過local cache及singleflight優(yōu)化，降低對下游接口調(diào)用量69%。

圖7：實驗環(huán)境名單庫接口批量優(yōu)化效果

異步——累積因子同步改異步計算優(yōu)化

異步通常和同步一起對比，其區(qū)別在于發(fā)起請求之后是立即返回還是等待結果，常用于在系統(tǒng)內(nèi)部有大量I/O操作時，通過異步提升吞吐。常見的使用有，基于write-back模式向緩存寫入數(shù)據(jù)，mysql異步傳輸binlog進行主從復制等。

在Gaia引擎中，一次請求會涉及對很多特征因子的計算，其中，最常用的是基于redis實現(xiàn)的累積因子，其包含如下幾種類型(見表1)，以count(distinct)類型為例，一次計算過程包含1寫zadd，1讀zcount，概率觸發(fā)zrem清除不在有效時間窗口內(nèi)的過期數(shù)據(jù)，其最多對redis請求3次，最少/均攤2次，且zset這幾個操作的時間復雜度都在O(log n)以上，加上一次請求往往會對多個累積因子進行計算(讀寫擴散)，這給redis集群帶來了較大的計算壓力，由于overload對集群實例擴容的限制，我們對redis集群的水平擴容也遇到了瓶頸。考慮當前引擎流量的情況：爬蟲類業(yè)務與常規(guī)業(yè)務流量占比為1.5:1，且爬蟲類業(yè)務流量還在持續(xù)高漲，鑒于爬蟲類業(yè)務風控的特性(非資產(chǎn)安全，容忍一定的漏過)，我們以犧牲數(shù)據(jù)一致性為代價，對爬蟲類業(yè)務的累積因子進行了異步計算優(yōu)化，以減少對redis的調(diào)用，其計算演進流程如下圖8所示：

類型	功能	底層實現(xiàn)	使用頻率
count	計數(shù)	incr	高
count(distinct)	去重計數(shù)	zset	高
sum	累積求和	incrby	低
avg	累積求平均	incrby	低

表1：風控引擎支持累積因子類型

圖8：累積因子計算(優(yōu)化前/后)流程

基于railgun（關于B站自研異步事件處理平臺,可參閱：從1到億，如何玩好異步消息？CQRS架構下的異步事件治理實踐）提供的內(nèi)存隊列聚合功能，我們對累積因子寫操作進行了異步化改造，并結合聚合功能，在設置的時間/數(shù)量閾值條件下，對相同累積key進行聚合并在內(nèi)存中去重后批量寫入redis，將多次同步redis I/O減少為異步寫1次。而優(yōu)化的效果從三個角度評估，從成本角度看：其對redis的調(diào)用qps減少了35%以上(如圖9)；從接口耗時看：TP99有一定的下降; 從對風控規(guī)則的召回影響看，前后召回趨勢基本一致，且打擊總量差距不大，在可接受的范圍內(nèi)。

圖9：單場景累積因子計算優(yōu)化前/后對redis的調(diào)用量情況

圖10：累積因子計算優(yōu)化前/后接口耗時情況

圖11：累積因子計算優(yōu)化前/后規(guī)則召回的情況

壓縮——日志存儲優(yōu)化

壓縮是常見的用于數(shù)據(jù)傳輸、持久化等過程中減少帶寬、存儲占用的方法，本質(zhì)是通過編碼的方式提高數(shù)據(jù)密度，減少數(shù)據(jù)的冗余度，一般以數(shù)據(jù)壓縮速度和壓縮率兩個指標來衡量壓縮過程的效能。常用的無損壓縮方式有：gzip、xz、lz4、zlib、zstd等。

對于風控業(yè)務來說，每一次風控請求會產(chǎn)生包含輸入?yún)?shù)、計算詳情（計算規(guī)則、特征因子等中間結果的快照）、打擊決策等多個維度的日志數(shù)據(jù)。我們需要提供準實時的查詢能力，用于輔助人工判定風控決策的召回和誤傷等情況。由于一次風控分析可能經(jīng)歷了上百條規(guī)則、上千個特征的計算，單條日志數(shù)據(jù)的平均大小達到了11KB左右，最大的高達幾十KB。基于風控日志的特點，我們把常用特征值（mid、buvid、ip等）和日志主體精簡出來，使用ES存儲并提供關鍵字查詢。其他詳情（參數(shù)、中間結果等）則依托于B站自研的KV存儲taishan KV，以請求traceId為key進行gzip壓縮后存儲。查詢時先基于ES查詢?nèi)罩局黧w，再對分頁記錄點查日志詳情并合并展示，其流程如圖12所示。這些優(yōu)化幫助風控度過了22年之前接入場景大量增長的階段，但隨著持續(xù)接入反爬蟲等大流量讀場景與降本增效帶來的雙重壓力下，風控日志存儲陷入了瓶頸。

圖12：舊風控日志詳情存儲與查詢過程

以taishan KV存儲的日志詳情為例，總存儲達到了16TB左右。因此，我們期望能夠利用壓縮率更高的編碼方式和壓縮算法替代json+gzip的組合，進一步優(yōu)化日志存儲。通過調(diào)研常見壓縮算法，結合日志詳情無壓縮速度要求的特點，我們采集了線上真實日志作為實驗集，選取了protobuf、msgpack等編碼方式和xz、zstd兩種算法進行了多次對比實驗。

在第一輪實驗中，我們對比了單條日志在不同編碼方式下不同壓縮算法的壓縮率。實驗隨機取同一場景下任意一條日志詳情進行編碼和壓縮，重復多次后取各階段數(shù)據(jù)長度平均值。其中，由于風控日志包含了許多嵌套和非固定結構，難以使用protobuf等需要預定義結構的序列化方式。因此我們嘗試了另一種高效的通用序列化框架msgpack。結果如表2所示。從結果上看，msgpack雖然編碼后比json更簡短，但由于產(chǎn)生了許多非文本結構，最終壓縮率不及json。xz算法由于壓縮率無明顯優(yōu)勢且內(nèi)存占用較大而被棄用（圖13）。無字典模式下的zstd壓縮率略弱于gzip。

編碼方式	消息長度	gzip	xz	zstd(無字典)
json	2255	1028	1092	1075
msgpack	1938	1088	1132	1119

表2：風控日志在不同編碼方式、壓縮算法下的壓縮效果（單位：字節(jié)）

圖13：各壓縮算法壓縮風控日志的內(nèi)存占用

在第二輪實驗中，我們使用json編碼方式，對比了gzip和zstd有無字典兩種模式下的壓縮率。其中，字典1由1萬條UAT爬蟲場景日志訓練獲得，與線上日志差異較大。字典2由10000條線上爬蟲場景日志訓練。首先是單條日志壓縮時不同zstd字典的影響，如表3所示。結果上，不使用字典時壓縮率最差，使用不匹配的字典略有提升。而使用匹配的字典后，zstd的壓縮率有顯著的提高。然后是對爬蟲場景不同數(shù)量的日志進行批量壓縮對壓縮率的影響，如表4所示。zstd在小日志壓縮上使用匹配的字典壓縮效率較好，隨著每批次數(shù)量增多，壓縮率會相對降低，最終與gzip相當。批量壓縮能夠顯著提高兩種算法的總體壓縮率，但單次超過10條以后遇到了邊際效應，收益急速降低。此外，我們基于任意單條日志進行了多輪性能測試，表5展示了其中5輪測試結果。從壓縮性能角度分析，無論是否使用字典，zstd壓縮的效率都遠超過gzip。

日志來源場景	消息長度	gzip	zstd (無字典)	zstd (字典1)	zstd (字典2)	說明
裂變拉新分享	25277	3869	4564	4236	4412	非同場景字典
爬蟲	4283	1434	1503	996	438	同場景字典

表3：風控日志詳情在zstd算法下使用不同字典的壓縮效果

（單位：字節(jié)）

每批日志數(shù)	總計日志數(shù)	gzip	zstd (無字典)	zstd (字典1)	zstd (字典2)
1	100	154370 (1.000)	160582 (1.040)	111708 (0.723)	59195 (0.383)
10	100	58984 (1.000)	67036 (1.137)	59942 (1.016)	47684 (0.808)
20	100	56085 (1.000)	63103 (1.125)	58509 (1.043)	56085 (1.000)
50	100	49152 (1.000)	55107 (1.121)	52927 (1.077)	48891 (0.995)
100	100	52439 (1.000)	56926 (1.086)	56076 (1.069)	53624 (1.023)
1	1000	1607512 (1.000)	1668363 (1.038)	1154260 (0.718)	629463 (0.392)
100	1000	536579 (1.000)	580076 (1.081)	572053 (1.066)	547021 (1.019)
500	1000	546506 (1.000)	570690 (1.044)	571252 (1.045)	565319 (1.034)

表4：不同數(shù)量的日志壓縮后數(shù)據(jù)大小總和與壓縮率對比（單位：字節(jié)）

測試序號	gzip	zstd (無字典)	zstd (字典1)	zstd (字典2)
1	123142	27509	31425	24474
2	139387	28246	31014	22763
3	148184	37118	37409	60840
4	158618	25168	29369	26504
5	170312	33782	47756	28951

表5：風控日志在gzip與zstd算法壓縮性能對比（單位：ns/op）

綜合以上實驗，雖然zstd算法在壓縮效率上遠優(yōu)于gzip，但僅在使用匹配的字典集時，對單條日志的壓縮率遠優(yōu)于gzip。另外，無論哪種壓縮算法都在批量壓縮中收益明顯，最高能夠減少60%的存儲。最后，由于我們對壓縮效率的需求較低，且訓練zstd字典等改造成本較大等原因，我們選擇對現(xiàn)有的風控日志詳情進行批量壓縮改造(圖14)。實現(xiàn)上，基于railgun提供的聚合隊列功能，我們將消費的日志分成n條若干批次，分配一個批處理ID(BatchId)并存儲到日志主體中，日志以BatchId為key批量gzip壓縮后存入taishan KV。查詢時，獲取分頁下待查的BatchId，去重后批量從taishan KV拉取數(shù)據(jù)，解壓后合并到日志中。對于查詢效率，最差情況下，每個BatchId都沒有去重，即每條數(shù)據(jù)多查詢了n-1條，請求數(shù)量不變，數(shù)據(jù)量變大N倍。實際查詢中，由于大多數(shù)查詢結果都是同一時段的連續(xù)數(shù)據(jù)集，因此實際去重效果較好，查詢效率略有提升。從存儲優(yōu)化上看，taishan KV寫入QPS由8k下降至1k左右，每秒寫入量由78MB下降為55MB，降幅約30%。表存儲TTL為7天，7日存儲下降約6TB，降幅約38%。

圖14：風控日志詳情批量存儲與查詢過程

緩存——多級緩存+布隆過濾器

緩存是最常見的加速數(shù)據(jù)交換的技術，通?；趦?nèi)存等高速存儲器實現(xiàn)，其本質(zhì)就是用空間換時間，犧牲一定的數(shù)據(jù)實時性，以減少各類IO的頻率，提升整體響應速度。常見的緩存方案包括Cache Aside、Read/Write Through、Write-back等，適用于不同的業(yè)務場景。

在Gaia引擎中，名單庫服務是風險特征判斷的重要組成部分，采用了最常用的Cache Aside模式。名單庫服務的需求是一種經(jīng)典的讀多寫少場景：引擎將分屬不同名單的風險主體持久化存儲（100QPS以下），同時提供接口查詢指定主體是否屬于某一名單（上萬QPS）。因此，初期的名單庫采用了localCache+Redis Cache+MySQL存儲的模式實現(xiàn)查詢過程：寫入時刪除緩存，查詢時依次查詢Cache，直到回源DB查詢，并將實際值或空值寫入Cache。這一模式在低流量條件下表現(xiàn)優(yōu)異，直到風控接入流量急速增長至十萬以上時，出現(xiàn)了越來越多的瓶頸問題，如：Redis CPU負載高、內(nèi)存占用高、DB回源超時等，DB存儲的名單個體數(shù)目也超過了3千萬并且持續(xù)快速增長。這迫使我們做了許多優(yōu)化來滿足后續(xù)潛在的百萬級QPS查詢需求。其中最有效的就是布隆過濾器（Bloom Filter，BF）多級緩存優(yōu)化，具體的優(yōu)化過程如圖15所示。對于寫過程來說，新增更新服務訂閱了名單表的binlog，提供BF的全量/增量更新。對于讀過程來說，在原有多級緩存前新增BF Cache查詢，在確認特征不存在的情況下直接返回結果。

圖15：名單庫服務BF多級緩存優(yōu)化過程——新老流程對比

由于名單庫查詢時，大多數(shù)用戶并無風險，名單庫查詢存在普遍的緩存穿透問題。因此名單庫查詢天然配適BF的使用場景，但要實際落地，仍然面臨著許多問題：

HotKey和BigKey問題。由于全集記錄超過3千萬條，單個BF容量越大，value越大，越容易出現(xiàn)集中訪問同一個key的熱點問題。因此需要對BF進行合理的拆分。
維護問題。BF需要維護一個全集數(shù)據(jù)，因此無論是本地還是分布式實現(xiàn)，都需要具備基于全量數(shù)據(jù)構建的能力。從數(shù)據(jù)安全性角度出發(fā)，BF存在人為操作等導致非預期異常的可能，BF需要具備備份和快速恢復能力。
數(shù)據(jù)一致性問題。一方面，由于BF能夠確定的表述一個key不存在于全集中，因此需要保證DB與BF的最終一致性。為了保證新記錄一定存入BF，插入BF需要支持無限重試。另一方面，由于BF存在假陽率，且不能刪除個體，隨著名單過期、key數(shù)量逼近BF容量等情況的發(fā)生，BF實際假陽率會逐級升高導致過濾效果變差。因此需要支持BF容量擴充和實現(xiàn)定期重建的能力。

由于Redis布隆過濾器插件完整的支持了BF的操作和自動擴容，我們選擇使用Redis作為BF的分布式實現(xiàn)。對于HotKey和BigKey問題，我們對BF進行了隨機分片。為了保證BF Key分布均勻，人為的將分片總數(shù)BF_SLICE_SIZE定義為4倍Redis Slot數(shù)量，即65536個。每一個分片Key的命名格式為"{libKey_bf_" + sliceIndex + "}"，其中sliceIndex為分片序號，使用花括號來保證相同前綴的BF利用rename命令迭代替換時處于同一個Slot中。名單個體將按照sliceIndex = HashKey % BF_SLICE_SIZE計算自己所屬的分片，其中HashKey的取值為名單個體值的IEEE CRC32絕對值。此外，我們對BF設置了獨立的本地緩存以減少實際調(diào)用。由于BF只增不減的特點，對于陽性結果，我們設置了較長TTL。而對于陰性結果，則按業(yè)務容忍度設置了秒級TTL，保證及時獲取新插入個體。

對于維護問題，我們實現(xiàn)了完整的構建工具。同時，基于安全性考慮實現(xiàn)了備份和快速恢復流程?；跔顟B(tài)機，我們定義了BF的構建過程：初始化、異步構建、同步測試、BF更新等。整個構建過程使用分布式鎖保證唯一性，基于railgun定時任務周期性觸發(fā)，整個過程記錄構建進度并提供實時展示和查詢。全過程如圖16所示。初始化時，會Dump生成正在運行的BF備份文件并存儲到對象存儲。生成新的BF臨時分片，以"_temp"尾綴區(qū)分。更新服務基于狀態(tài)變化將增量個體雙寫到臨時BF中。異步構建過程會分批獲取完整的名單表，批量寫入存量個體到臨時BF中。之后進行同步測試，利用少量增量和存量個體模擬查詢臨時BF，當所有測試個體都存在于BF時通過測試。最后，將臨時BF原子性地替換正式BF，完成構建過程。快速恢復過程基于構建的整體流程，部分模塊略有差異：初始化階段會獲取備份文件并嘗試restore數(shù)據(jù)到臨時BF中。異步構建時則基于備份時間點開始獲取存量數(shù)據(jù)。

圖16：BF構建與快速恢復流程

對于數(shù)據(jù)一致性問題，我們提供了完整的控制、評估和測試BF一致性的流程。為了保證數(shù)據(jù)安全，我們定義了BF測試模式和正常模式兩種運行方式，并可以按比例配置運行，如圖17所示。測試模式下，查詢的BF值不會生效，流量進入緩存查詢流程。之后基于查詢實際值對比結果進行監(jiān)控報點并建立真陰性比例四個9等監(jiān)控告警。處于正常模式則會對BF假陽等情況進行報點等。實際上線后，服務長期保持一定比例的流量（當前為0.1%）運行測試模式，用于持續(xù)評估線上BF運行狀態(tài)。圖18展示了BF查詢結果占比，約95%的查詢?yōu)殛幮?，?yōu)化收益明顯，如表6所示。在后續(xù)壓測中，名單庫服務具備了支撐百萬級流量的能力。

圖17：名單庫服務BF多級緩存優(yōu)化過程

圖18：名單庫服務線上流量BF查詢結果占比

優(yōu)化項目	優(yōu)化前	優(yōu)化后	降幅	說明
服務CPU使用率	50.5%	17.5%	65%	日峰值同比
Redis 內(nèi)存占用	256GB	50GB	80%	日峰值同比
Redis 網(wǎng)絡IO	174/187Mbps	13.7/6.7Mbps	92%/96%	日峰值同比
Redis CPU使用率	42%	4%	90%	日峰值同比
BF Redis 內(nèi)存占用	0	7GB	-	新增10個節(jié)點
BF Redis 網(wǎng)絡IO	0	71.4/7.5Mbps	-	新增10個節(jié)點
BF Redis CPU使用率	0	10%	-	新增10個節(jié)點
MySQL 讀QPS	12k	600	95%	日峰值同比

表6：名單庫BF多級緩存優(yōu)化收益對比

總結

性能優(yōu)化的手段有多種方式，本篇文章只是結合近期在風控系統(tǒng)中的應用實踐進行的一個總結，需要說明的是，其中有的優(yōu)化手段有利也有弊，得到的同時也在失去，可見，任何優(yōu)化手段都得以業(yè)務可接受為前提，因地制宜才是正道。正如Linux性能優(yōu)化大師Brendan Gregg一再強調(diào)的：切忌過早優(yōu)化、過度優(yōu)化。

本文鏈接：http://www.www897cc.com/showinfo-26-15233-0.html常用性能優(yōu)化手段及在風控系統(tǒng)中的應用

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：技術團隊運用度量驅(qū)動開發(fā)提升質(zhì)量：策略與實踐

下一篇：兩年過去了，React Forget 涼了么？

標簽：

熱門焦點

MIX Fold3包裝盒泄露新機本月登場

小米的全新折疊屏旗艦MIX Fold3將于本月發(fā)布，近日該機的真機包裝盒在網(wǎng)上泄露。從圖上來看，新的MIX Fold3包裝盒在外觀設計方面延續(xù)了之前的方案，變化不大，這也是目前小米旗艦
Raft算法：保障分布式系統(tǒng)共識的穩(wěn)健之道

1. 什么是Raft算法？Raft 是英文”Reliable、Replicated、Redundant、And Fault-Tolerant”（“可靠、可復制、可冗余、可容錯”）的首字母縮寫。Raft算法是一種用于在分布式系統(tǒng)
從 Pulsar Client 的原理到它的監(jiān)控面板

背景前段時間業(yè)務團隊偶爾會碰到一些 Pulsar 使用的問題，比如消息阻塞不消費了、生產(chǎn)者消息發(fā)送緩慢等各種問題。雖然我們有個監(jiān)控頁面可以根據(jù) topic 維度查看他的發(fā)送狀態(tài)，
三言兩語說透設計模式的藝術-單例模式

寫在前面單例模式是一種常用的軟件設計模式，它所創(chuàng)建的對象只有一個實例，且該實例易于被外界訪問。單例對象由于只有一個實例，所以它可以方便地被系統(tǒng)中的其他對象共享，從而減少
一文掌握 Golang 模糊測試（Fuzz Testing）

模糊測試（Fuzz Testing）模糊測試（Fuzz Testing）是通過向目標系統(tǒng)提供非預期的輸入并監(jiān)視異常結果來發(fā)現(xiàn)軟件漏洞的方法?？梢杂脕戆l(fā)現(xiàn)應用程序、操作系統(tǒng)和網(wǎng)絡協(xié)議等中的漏洞或
重估百度丨“晚熟”的百度云，能等到春天嗎？

©自象限原創(chuàng)作者｜程心排版｜王喻可2016年7月13日，百度云計算戰(zhàn)略發(fā)布會在北京舉行，宣告著百度智能云的正式啟程。彼時的會場座無虛席，甚至排隊排到了門外，在場的所有人幾乎都
消費結構調(diào)整丨巨頭低價博弈，拼多多還卷得動嗎？

來源：征探財經(jīng)作者：陳香羽隨著流量紅利的退潮，電商的存量博弈越來越明顯。曾經(jīng)主攻中高端與品質(zhì)的淘寶天貓、京東重拾“低價”口號。而過去與他們錯位競爭的拼多多，靠
馮提莫簽約抖音公會前“斗魚一姐”消失在直播間

來源：直播觀察提起“馮提莫”這個名字，很多網(wǎng)友或許聽過，但應該不記得她是哪位主播了。其實，作為曾經(jīng)的“斗魚一姐”，馮提莫在游戲直播的年代影響力不輸于現(xiàn)
三星獲批量產(chǎn)iPhone 15全系屏幕：蘋果史上最驚艷直屏

按照慣例，蘋果將繼續(xù)在今年9月舉辦一年一度的秋季新品發(fā)布會，有傳言稱發(fā)布會將于9月12日舉行，屆時全新的iPhone 15系列將正式與大家見面，不出意外的話

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

常用性能優(yōu)化手段及在風控系統(tǒng)中的應用

引言

預取——特征預計算

批量——特征批量獲取

異步——累積因子同步改異步計算優(yōu)化

壓縮——日志存儲優(yōu)化

緩存——多級緩存+布隆過濾器

總結

MIX Fold3包裝盒泄露新機本月登場

Raft算法：保障分布式系統(tǒng)共識的穩(wěn)健之道

從 Pulsar Client 的原理到它的監(jiān)控面板

三言兩語說透設計模式的藝術-單例模式

一文掌握 Golang 模糊測試（Fuzz Testing）

重估百度丨“晚熟”的百度云，能等到春天嗎？

消費結構調(diào)整丨巨頭低價博弈，拼多多還卷得動嗎？

馮提莫簽約抖音公會前“斗魚一姐”消失在直播間

三星獲批量產(chǎn)iPhone 15全系屏幕：蘋果史上最驚艷直屏

最新推薦

猜你喜歡

熱門推薦

相關資訊