柚子快報(bào)激活碼778899分享：分布式 Kafka 線上問(wèn)題

http://yzkb.51969.com/

訂單寬表數(shù)據(jù)不同步

事情的起因是用戶在 app 上查不到訂單了，而訂單數(shù)據(jù)是從 mysql 的 order_search 表查詢的，order_search 表的數(shù)據(jù)是從 oracle 的 order 表同步過(guò)來(lái)的，查不到說(shuō)明同步有問(wèn)題

首先重啟，同步數(shù)據(jù)，問(wèn)題解決，然后查找原因。首先看日志，有如下兩種情況

有的容器消費(fèi)消息的日志正常打印有的容器很長(zhǎng)時(shí)間沒(méi)有消費(fèi)消息的日志（看著像是消息丟失，找運(yùn)維確認(rèn)后明確發(fā)送沒(méi)問(wèn)題，只能是消費(fèi)的問(wèn)題）

接著看容器的狀況

查看了應(yīng)用重啟前各個(gè)容器的 CPU 和內(nèi)存情況，發(fā)現(xiàn)并不均勻，有如下三種情況

CPU一直很高（內(nèi)存穩(wěn)定）CPU和內(nèi)存一直穩(wěn)定上升CPU一直很低（內(nèi)存穩(wěn)定）

看監(jiān)控發(fā)現(xiàn)消息在分區(qū)中分布的也不均衡

問(wèn)題排查

接著就按照如下現(xiàn)象來(lái)進(jìn)行排查問(wèn)題

為什么消息發(fā)送不均衡為什么有的容器CPU一直很高，有的一直很低，有的持續(xù)升高（CPU飆高的機(jī)器，內(nèi)存也不斷上漲）

為什么會(huì)出現(xiàn)這些現(xiàn)象？

producer發(fā)送消息和consumer消費(fèi)消息都有對(duì)應(yīng)的負(fù)載均衡策略，既然消息發(fā)送不均衡，只需要看producer的負(fù)載均衡策略即可

producer的負(fù)載均衡實(shí)現(xiàn)類為 DefaultPartitioner，具體實(shí)現(xiàn)為

如果 key 為 null：消息將以輪詢的方式，在所有可用分區(qū)中分別寫入消息如果 key 不為 null：對(duì) Key 值進(jìn)行 Hash 計(jì)算，從所有分區(qū)中根據(jù) Key 的 Hash 值計(jì)算出一個(gè)分區(qū)號(hào)；擁有相同 Key 值的消息被寫入同一個(gè)分區(qū)；

所以推測(cè)發(fā)送的消息指定了key，看消費(fèi)日志確定了猜想，key的名字為表名

這樣就明確了，同一張表的數(shù)據(jù)只會(huì)被發(fā)送到同一個(gè)分區(qū)，同一個(gè)分區(qū)的數(shù)據(jù)只能被一個(gè) Consumer 消費(fèi)

接著我們查到 CPU 一直比較高的容器，消費(fèi)的是合同表的數(shù)據(jù)，合同表的數(shù)據(jù)變更比較頻繁，所以CPU比較高

而 CPU 持續(xù)飆升的容器，消費(fèi)的是訂單表的數(shù)據(jù)。

接著就是排查消費(fèi)訂單表的容器為什么CPU和內(nèi)存持續(xù)飆升

首先用生成 dump 文件，用 Eclipse Memory Analyzer 分析一下看是否發(fā)生了內(nèi)存泄露

點(diǎn)擊 Leak Supects 查看內(nèi)存泄漏分析

總共使用了110MB內(nèi)存，Thread線程占用了29M，總共創(chuàng)建了2686個(gè)線程，看一下這些線程是哪些？

線程數(shù)量最多的線程名字為datasync-execuotr-1，到代碼中查看是否有類似線程

每消費(fèi)一次訂單表的數(shù)據(jù)，調(diào)用一次 asyncConfig.getAsyncExecutor()方法，就會(huì)新創(chuàng)建一個(gè)線程池，核心線程數(shù)為10，不斷創(chuàng)建線程導(dǎo)致內(nèi)存和 CPU 不斷飆升，消息不能正常消費(fèi)，后續(xù)消費(fèi)消息改成使用一個(gè)固定的線程池后，消息正常消費(fèi)

柚子快報(bào)激活碼778899分享：分布式 Kafka 線上問(wèn)題

http://yzkb.51969.com/

好文閱讀