前言
最近工作中在做一個場景的pulsar性能調(diào)優(yōu)赵抢，解決了一些問題驹溃，分享給大家
業(yè)務(wù)場景
其中producer，pulsar，consumer均為多實例简烤，4U16G部署
雖然消息量不是很大猴凹，但主要topic數(shù)目大萝招，還要讓producer玩荠，pulsar，consumer協(xié)同工作好浊猾，架構(gòu)無單點問題抖甘，無損升級，這是我們的主要挑戰(zhàn)
問題列表
Pulsar客戶端連接不上broker
剛剛把測試數(shù)據(jù)準備好与殃，我們就碰到了第一個問題单山，pulsar客戶端連接broker困難，測試無法進行幅疼。我們根據(jù)健康檢查米奸，curl命令排查出問題在pulsar的8080端口hang住，不給響應(yīng)爽篷。
這里值得一提的是悴晰，我們使用了8080端口而不是6650端口連接broker，原因主要有兩點:
- 8080的日志詳細逐工，而且大部分發(fā)向8080的請求都是元數(shù)據(jù)請求铡溪，在排查問題的時候比較關(guān)鍵，也容易監(jiān)控泪喊。比如棕硫，創(chuàng)建topic失敗，創(chuàng)建producer超時袒啼，這些事件在jetty的requestLog都能很容易地監(jiān)控起來
- 數(shù)據(jù)請求和元數(shù)據(jù)請求可以隔離哈扮，避免在6650端口繁忙的時候，創(chuàng)建topic蚓再，刪除topic等功能受到影響
然而8080端口效率相對6650性能差滑肉，默認的線程數(shù)不滿足5w topic量級下，consumer摘仅，producer建立的請求數(shù)（每個consumer的建立都有partitions和lookup請求等）靶庙，這里我們把jetty的線程數(shù)調(diào)大，解決了這個問題
生產(chǎn)消費時延大
然后娃属，我們通過測試工具發(fā)現(xiàn)消息從生產(chǎn)者到消費者六荒，整個端到端延遲較大护姆。
這里我們?yōu)榱硕ㄎ粏栴}方便，開發(fā)了單topic debug特性恬吕，在海量消息的場景下签则，無論是測試環(huán)境還是生產(chǎn)環(huán)境，都不敢輕易在broker開啟全局debug铐料。我們在自己的配置中心做了個配置，在配置上的topic豺旬，就會打印debug日志钠惩。
在單topic debug特性的配合下， 我們很快發(fā)現(xiàn)消息的最大延遲出現(xiàn)在producer發(fā)送完消息族阅，服務(wù)端接收到消息之間篓跛，由此推測到是netty的acceptor配置不夠，調(diào)高后解決了部分問題坦刀。我們選用的版本愧沟，acceptor配置還是寫死在代碼里為1的。提交了PR鲤遥，使之變?yōu)榭膳渲?strong>https://github.com/apache/pulsar/pull/9061,也解決了創(chuàng)建生產(chǎn)消費者慢的問題
解決了這個問題后沐寺，我們就發(fā)現(xiàn)瓶頸出現(xiàn)在單個JVM實例上，啟動5w個消費者存在很大的隱患盖奈，如內(nèi)存不足混坞，5w消費者下所需的業(yè)務(wù)線程調(diào)度導致延遲還是較大。我們決定對消費者進行分組钢坦，每個實例負責約1w個消費者究孕，解決了生產(chǎn)消費時延大的問題。
創(chuàng)建生產(chǎn)消費者慢
調(diào)整netty參數(shù)配置后解決
升級呼損時間長
在測試pulsar升級的過程中爹凹，我們發(fā)現(xiàn)單topic不可用時間峰值竟達到過127秒厨诸，這幾乎是不可接受的。隨后排查發(fā)現(xiàn)禾酱，pulsar的優(yōu)雅啟停并沒有執(zhí)行完畢就退出了（注：pulsar的優(yōu)雅啟停微酬，需要在zk上進行兩次操作，我們也在實測中發(fā)現(xiàn)宇植，pulsar升級過程中得封，zk的p99延遲會增加）隨后我們調(diào)大了pulsar的優(yōu)雅啟停時間到180s。將單topic不可用時間控制在17s左右指郁，再在生產(chǎn)者重試忙上，保證無呼損。接下來還要繼續(xù)優(yōu)化這個數(shù)字闲坎。
ZooKeeper升級部分Pulsar重啟
當前如果和ZooKeeper斷鏈疫粥，pulsar就會重啟茬斧，重連目前還是beta配置。當zooKeeper升級的過程中梗逮，zookeeper客戶端和zookeeper服務(wù)器重連是依次重連的项秉，間隔為1s內(nèi)隨機，并且每次輪完一圈后會等待1s（注：我們采用靜態(tài)ZooKeeper配置慷彤，并且用域名訪問娄蔼，Ex: ZooKeeper-0.zookeeper:2181,ZooKeeper-1.zookeeper:2181,ZooKeeper-2.zookeeper:2181)。我們升級zookeeper的時候底哗，重新選主大概需要0~2s岁诉。
默認的pulsar超時時間是5s，本來就算是最差的場景跋选，以zookeeper-0升級舉例: zookeeper-0=>zookeeper-1=>zookeeper-2=>sleep1s=>zookeeper-0涕癣，這樣子大概4秒也是能連上來的，但是因為我們配置的域名前标，jvm刷新域名不及時坠韩，導致第二次重連zookeeper-0也失敗了。
解決方案：把jvm的dns超時配置成5s炼列，并且把zookeeper的session超時配成15s
健康檢查波動
Pulsar自帶的健康檢查腳本只搁，需要拉起一個jvm運行，在1U的場景下會造成較大的cpu波動唯鸭，4U的場景下也有較大影響须蜗。我們本來就就在容器內(nèi)除了pulsar進程，還拉起了一個進程目溉，負責對接我們的告警明肮，kpi系統(tǒng)等，讓這個進程負責健康檢查的工作（也是生產(chǎn)消費pulsar）避免了每次都動態(tài)拉起jvm缭付，降低了cpu的波動
Recycled Already
這個問題比較簡單柿估，使用了TypedMessageBuilder進行重試，陷猫，提醒小伙伴們不要使用TypedMessageBuilder進行重試
普羅指標裁剪
50ktopic數(shù)量大秫舌，指標多，都進行采集绣檬，會導致我們的普羅占用資源非常大足陨，我們根據(jù)自己的業(yè)務(wù)特點，比如每條消息大小都差不多娇未，裁剪掉了storageSize的相關(guān)指標墨缘，忍痛裁掉了每個ml的指標，認為topic級別的監(jiān)控+全局監(jiān)控+bk監(jiān)控足以網(wǎng)上運維。將普羅的占用資源控制在了8U32G镊讼。
