這個(gè)也是開(kāi)放討論題泛豪，主要討論下 Kafka 在消息中是如何進(jìn)行實(shí)現(xiàn)的诡曙。
這個(gè)題目的開(kāi)發(fā)性太強(qiáng)了渊涝。
Kafka 可以用的地方非常多跨释，我經(jīng)歷過(guò)的項(xiàng)目有 Kafka 用在消息處理策略上的岁疼。這個(gè)主要是 IoT 項(xiàng)目瑰排，因?yàn)檫@個(gè)項(xiàng)目需要對(duì)溫度傳感器采集獲得數(shù)據(jù)凶伙。
當(dāng)我們有多個(gè)數(shù)據(jù)采集點(diǎn)的時(shí)候，通常是在每分鐘發(fā)送幾條數(shù)據(jù)的樣子傻挂。
哪怕是這種使用場(chǎng)景，我覺(jué)得從系統(tǒng)架構(gòu)的考慮來(lái)說(shuō)還是過(guò)于臃腫了套腹，因?yàn)?Kafka 的運(yùn)行需要 ZooKeeper幢码，一套 ZooKeeper 的運(yùn)行至少是需要 3 臺(tái)服務(wù)器。
正常的生產(chǎn)環(huán)境部署贞铣，我們可能要部署到 5 太服務(wù)器上辕坝。
對(duì)于一個(gè)每秒鐘消息都不到 1 條的消息服務(wù)器來(lái)說(shuō)，實(shí)在是太重了圣贸。
其實(shí)這種使用場(chǎng)景，我們可以用一些輕量的消息服務(wù)器矮慕，比如說(shuō) ActiveMQ痴鳄，我就覺(jué)得非常好。
可以簡(jiǎn)單到使用一個(gè) Docker 容器就可以完成了，但消息處理能力也還是強(qiáng)大的芽唇。
對(duì)于 Kafka 這種野獸級(jí)的消息處理服務(wù)器研侣，實(shí)在是用不上。
我們還經(jīng)歷過(guò)一個(gè)項(xiàng)目灌砖，Kafka 被用作緩存了傀蚌。
每次項(xiàng)目啟動(dòng)的時(shí)候，都需要從 Kafka 上獲得緩存數(shù)據(jù)箩艺，然后系統(tǒng)才能運(yùn)行宪萄。
這個(gè)也是非常痛苦的艺谆，有時(shí)候因?yàn)榫彺鏅C(jī)制的使用不確定，導(dǎo)致部分時(shí)候的數(shù)據(jù)緩存上沒(méi)有拜英。
然后在調(diào)試的過(guò)程中就非常的痛苦静汤。
根據(jù)上面的情況，對(duì)這開(kāi)放性的問(wèn)題，通常只需要說(shuō)說(shuō)你對(duì)問(wèn)題的了解情況就好了虫给。
一般來(lái)說(shuō)還是不會(huì)要求你做到具體的實(shí)現(xiàn)的藤抡，只要你對(duì)消息服務(wù)器有一些相關(guān)的知識(shí)瓷式，上面的 2 個(gè)使用案例還是比較經(jīng)典的瓤漏。
其實(shí)消息服務(wù)器還有很多可以使用的場(chǎng)景罗标，比如說(shuō)數(shù)據(jù)解耦，對(duì)爬蟲(chóng)數(shù)據(jù)的數(shù)據(jù)解耦等等锥忿，都是可以用的酪惭。
很多公司還會(huì)做一個(gè)消息服務(wù)器窥岩，比如說(shuō)對(duì)訂閱用戶的消息回復(fù)朦乏，手機(jī)消息推送等等并思，都需要我們的消息服務(wù)器去處理。
所以這個(gè)問(wèn)題為設(shè)計(jì)型問(wèn)題，只需要對(duì)相關(guān)問(wèn)題有所了解即可。
