如何刪除weblogicjmsdelayed狀態(tài)的消息？消消氣~你注意到的“Topichtmltrack_errorisn'talreadymarkedafterdeletion”是正常的。Kafka

如何刪除weblogicjmsdelayed狀態(tài)的消息？

消消氣~

你注意到的“Topichtmltrack_errorisn'talreadymarkedafterdeletion”是正常的。Kafka刪掉topic的過(guò)程事實(shí)上是異步的：命令行單單是遞交一個(gè)刪除再申請(qǐng)給到controller，并標(biāo)志該topic為“待刪除”狀態(tài)。當(dāng)然在Kafka服務(wù)器端唯一的刪除掉邏輯應(yīng)該要早傳送，正常情況下您不需要多等待一段時(shí)間topic自然會(huì)被完成刪掉。

kafka broker與topic的關(guān)系？

另一個(gè)相當(dāng)于的kafka服務(wù)器被被稱broker。broker收得到來(lái)自生產(chǎn)者的消息，為消息設(shè)置中偏移量，并并提交消息到磁盤保存到。broker為消費(fèi)者提供服務(wù)，對(duì)讀取數(shù)據(jù)主分區(qū)的請(qǐng)求做出了決定相應(yīng)，前往也并提交到磁盤上的消息。

Kafka的消息按照主題（Topic）并且分類，就好比是數(shù)據(jù)庫(kù)的表，也可以是文件系統(tǒng)里的文件夾。主題是可以被分為若干個(gè)分區(qū)（Partition），一個(gè)分區(qū)應(yīng)該是個(gè)遞交日志。消息以賞分的讀取分區(qū)，然后以先進(jìn)先出的順序讀取。特別注意，的原因一個(gè)主題像是包涵幾個(gè)分區(qū)，但根本無(wú)法在整個(gè)主題范圍內(nèi)可以保證消息的順序，但可以只要消息在單個(gè)分區(qū)內(nèi)的順序。主題是邏輯上的概念，在物理上，一個(gè)主題是橫跨多個(gè)服務(wù)器的。

云計(jì)算分布式消息隊(duì)列有哪些？

有以下幾種：

ActiveMQ：每個(gè)人一開(kāi)始都建議使用ActiveMQ，但現(xiàn)在的確每個(gè)人都還沒(méi)有使用太。已通過(guò)如此大規(guī)模吞吐量方案不驗(yàn)證，社區(qū)也不是很活躍。單臺(tái)機(jī)器的吞吐量為10,000級(jí)，并且吞吐量低的RocketMQ和Kafka。這是一個(gè)數(shù)量級(jí)，吶喊之聲為ms級(jí)，有較低數(shù)據(jù)丟失的可能性。

RabbitMQ：?jiǎn)螜C(jī)吞吐率是萬(wàn)級(jí)，吞吐率比RocketMQ和Kafka低一個(gè)數(shù)量級(jí)，但是它適合中小企業(yè)，因?yàn)樗哂杏押玫谋O(jiān)視和能維護(hù)界面，社區(qū)總體活躍，全都每月都有都會(huì)查找?guī)讉€(gè)版本，近年來(lái)，一些國(guó)內(nèi)的互聯(lián)網(wǎng)公司更多地建議使用了rabbitmq，但問(wèn)題也很的確。RabbitMQ的吞吐量雖然相對(duì)較低。這是畢竟他做的實(shí)現(xiàn)機(jī)制比較比較忙碌不堪，但是該語(yǔ)言國(guó)內(nèi)會(huì)的太少。

RocketMQ：?jiǎn)螜C(jī)吞吐量為100,000級(jí)。RocketMQ還是奇異也可以支持高吞吐量的MQ。主題是可以都沒(méi)有達(dá)到數(shù)百或數(shù)千個(gè)級(jí)別，另外吞吐量將略微降到。這是RocketMQ的通常優(yōu)勢(shì)。在同一臺(tái)機(jī)器上，它也可以意見(jiàn)大量topic，可用性太高，源代碼是JAVA。

Kafka：?jiǎn)螜C(jī)吞吐量為100,000級(jí)。這是Kafka的的最優(yōu)勢(shì)，即高吞吐量。通常與大數(shù)據(jù)系統(tǒng)依靠先執(zhí)行實(shí)時(shí)數(shù)據(jù)算出，日志收集等場(chǎng)景。當(dāng)topic從數(shù)十個(gè)時(shí)變數(shù)百個(gè)時(shí)，吞吐量將大嚇會(huì)下降