讀完本文需要1分鐘
程序員崗位太多了，前端後端算法大數據，每個崗位的要求都不一樣，所以對於整個公司的架構理解也不一樣。
我曾經也是個程序員，就和大家講講如何從程序員的角度理解企業為什麼需要Kafka。
先從數據庫說起。
我們都知道，數據庫中的數據，只要應用程序員不主動刪除，就可以任意次讀寫，多少次都行。數據庫還對外提供了很漂亮的接口——SQL ——讓程序員操作數據。
但是數據庫不擅長做“通知”（人家也不是幹這種事的）：例如，程序A向數據庫插入了一條數據， 然後程序B想知道這次數據更新，然後做點事情。
這種"通知"的事情，一種辦法是用輪詢實現， 程序B不斷地查數據庫，看看有沒有新數據的到來， 但是這種方法效率很低。
更直接的辦法是讓應用程序之間直接交互，例如程序A調用程序B的RESTful API。
但問題是程序B如果暫時不可用，程序A就會比較悲催，怎麼辦呢？等一會兒再試？ 如果程序B還不行，那就循環再試。調用方的責任太大。
於是消息隊列(MQ)就出現了，程序A把數據往消息隊列中一扔，完事走人，程序B想什麼時候讀就什麼時候讀，極其靈活。
所以MQ的重要功能就是解耦，讓兩個系統可以獨立運行，異步操作，互不影響。
MQ還有一個好處就是允許程序A瘋狂地向其中放消息，程序B 可以慢悠悠地處理，這就起到了“消峰”的效果。
可是傳統的MQ也有問題，通常情況下，一個消息確認被讀取以後，就會被刪除。如果來了一個新的程序C，也想讀之前的消息，或者說之前一段時間的消息，傳統MQ表示無能無力。
能不能把數據庫的特點和MQ的特點結合起來呢？
消息可以持久化，讓多個程序都可以讀取，並且還支持發佈-訂閱這種模式。
Kafka出現了，它也是一個消息隊列，但是它能保存很長一段時間的消息（因為在硬盤上），隊列中每個消息都有一個編號1,2,3,4.... ，這樣就支持多個程序來讀取。
只要記錄下每個程序都讀到了哪個編號， 這個程序可以斷開和Kafka的連接，這個程序可以崩潰，下一次就可以接著讀。
新的消費者程序可以隨意加入讀取，不影響其他消費者程序， 是不是很爽？
例如：程序B讀到了編號為3的消息， 程序C讀到了編號為5的消息， 這時候來了一個新的程序D，可以從頭開始讀。
這其實和數據庫複製有點像：Kafka維護者“主數據庫”， 每個消費者程序都是“從數據庫”， 只要記住編號，消息都可以從“主數據庫”複製到“從數據庫”。
當然，Kafka做的遠不止於此，它還充分利用硬盤順序化讀取速度快的特性，再加上分區，備份等高可用特性， 一個高吞吐量的分佈式發佈訂閱消息系統就誕生了。
閱讀更多 IT技術管理那些事兒 的文章
