幹壞事是進步最大的原動力
RabbitMQ 要在 3.9 版推出 Streams (目前 3.9 還在 RC)：「RabbitMQ Streams Overview」，在 Hacker News 上有一些討論可以看：「RabbitMQ Streams Overview (rabbitmq.com)」。
這樣 RabbitMQ 可以同時有 queue 與 stream 的能力，對於一些小專案應該會方便不少，算是打隔壁棚 Kafka 的痛點之一，弄一組 HA cluster 至少要三台 ZooKeeper 加上兩台 Broker，基礎建設還要有對應的 HA load balancer 機制，在 AWS 上可以拿 ELB 偷懶，如果是實體機房的話也許用 F5 擋，或是用 open source 的 Keepalived (或是老一點的 Heartbeat) + nginx。
目前還不知道 scalability 的能耐，不過印象中在 queue 的單台 throughput 不差，如果沒有意外的話，streaming 的部份對小型專案應該夠用。
在 Hacker News 上看到「I wrote a children's book / illustrated guide to Apache Kafka (gentlydownthe.stream)」這篇，用繪本的方式解釋 Apache Kafka 的運作方式：「Gently Down the Stream」，非常值得一看。
以 Hacker News 上 upvote 的數量來看，應該也會上明天的 Hacker News Daily。
這繪本還帶有一些動畫效果，而且把需要提到的東西都有帶出來 (像是 Kafka Connector 都有提到)，不過雖然作者目標群是小朋友，看起來大人還比較興奮？
差不多一年前提到了 Kafka 打算拔掉 ZooKeeper 的計畫 (在「Kafka 拔掉 ZooKeeper 的計畫」這邊有提到)，昨天 Confluent 發了一篇進展：「Apache Kafka Made Simple: A First Glimpse of a Kafka Without ZooKeeper」。
這件事情可以在「KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum」這邊看到說明，另外在 Jira 上面則是在 KAFKA-9119 這邊追蹤。
目前的好消息就是 KIP-500 的程式碼都已經推進 trunk，目標在 2.8 釋出時就可以用：
So we’re very pleased to say that the early access of the KIP-500 code has been committed to trunk and is expected to be included in the upcoming 2.8 release.
文件裡面會用「Kafka Raft Metadata mode」或是「KRaft」稱呼這種模式：
For the first time, you can run Kafka without ZooKeeper. We call this the Kafka Raft Metadata mode, typically shortened to KRaft (pronounced like craft) mode.
然後有缺一些功能，另外就是常態性宣導這是測試版，建議不要在 production 環境用：
Beware, there are some features that are not available in this early-access release. We do not yet support the use of ACLs and other security features or transactions. Also, both partition reassignment and JBOD are unsupported in KRaft mode (these are anticipated to be available in an Apache Kafka release later in the year). Hence, consider the quorum controller experimental software—we don’t advise subjecting it to production workloads. If you do try out the software, however, you’ll find a host of new advantages: It’s simpler to deploy and operate, you can run Kafka in its entirety as a single process, and it can accommodate significantly more partitions per cluster (see measurements below).
目前丟出來的測試數據可以看到有大幅改善，但仔細看居然是停機與恢復時間：
不知道實際的效能上有多少影響 (正面或是負面)，還是得等了...
在 Hacker News 首頁上看到的東西，看起來是 C++ 版本的 Apache Kafka 替代品 Redpanda，要注意的是這不是 open source license 軟體：「Redpanda – A Kafka-compatible streaming platform for mission-critical workloads (vectorized.io)」。
目前網站上可以看到，最主要的特點是不需要 Apache ZooKeeper，不過這點在 Kafka 這邊也正在進行了 (之前在「Kafka 拔掉 ZooKeeper 的計畫」這篇有提到)，雖然進度有點慢...
另外目前完全沒有 benchmark 資料，只有宣稱 10x 更快，官方在 Hacker News 上的回應是說十二月會有公開的測試報告，這樣我會把 10x 當廣告詞看了，應該會更快，但大概是某種特殊情境下才會達到...
目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料，但眾所皆知的，ZooKeeper 實在是不好維護，所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。
這篇算是其中一塊：「Kafka Needs No Keeper」。
真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護，尤其是 Apache 官方版本的軟體與文件常常脫勾，設定起來就很痛苦。所以一般都會用 Confluent 出的包裝，裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過，不太會遇到官方文件與軟體之間搭不上的問題。
另外一個常見的痛點是，因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了)，但進展不快，所以有時候會發現在 command line 下，有些指令會把 API endpoint 指到 ZooKeeper 伺服器上，但有些指令卻又指到 Kafka broker 上，這點一直在邏輯上困擾很久，直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...
給需要的人參考，當初在架設 Kafka cluster 時寫下來的筆記：「Confluent」。
AWS 發表把 Kafka 包起來當服務賣的 Amazon MSK：「Introducing Amazon Managed Streaming for Kafka (Amazon MSK) in Public Preview」。
另外 Kafka 所需的 ZooKeeper 部份已經被包進去了，不需要另外付費：
You do not pay for Apache Zookeeper nodes that Amazon MSK provisions for you, or data transfer that occurs between brokers and nodes within clusters.
目前看起來只提供 us-east-1 區域使用。
Apache Kafka 是個 pub-sub 系統：
Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.
而 Yelp 的人想要將 MySQL 的更新資訊送一份到 Kafka 就可以做很多應用。文章前面介紹了很多原理以及理論，像是講 MySQL 的 replication：
但讀這篇文章發現重點在於他介紹了 GitHub 上的「noplay/python-mysql-replication」這個專案：
Our stream reader is an abstraction over the BinLogStreamReader from the python-mysql-replication package.
這個專案可以解析 MySQL 的 replication protocol：
Pure Python Implementation of MySQL replication protocol build on top of PyMYSQL. This allow you to receive event like insert, update, delete with their datas and raw SQL queries.
馬上就感覺到可以透過這個 library 做不少事情，像是直接接到 worker，再更新 Elasticsearch 上的資料，這樣就是 100% 確保不會漏更新...
在「Benchmarking Message Queue Latency」這篇看到作者測了一輪 Message Queue 軟體：
RabbitMQ (3.6.0), Kafka (0.8.2.2 and 0.9.0.0), Redis (2.8.4) pub/sub, and NATS (0.7.3)
測試包括了從一個 9 到六個 9 的 latency (i.e. 90%、99%、99.9%、99.99%、99.999%、99.9999%)，另外也測了 message 大小帶來的效能差異。
99.9% 表示 1/1000，而 99.99% 表示 1/10000，如果差距跟 90% 很大，表示系統反應時間會很不一致。另外有些 Message Queue 軟體有 disk persistence 的功能，也因為寫入資料，會看到更大的差距。
善用或是避開這些特性去規劃才能減少問題，像是關掉 disk persistence 之類的方法。