《從架構角度看kafka(一)》
我們第一次接觸可能都是作為訊息傳輸來學，作用很簡單，就是生產者與消費者解耦，非同步操作。kafka是乙個很好地選擇，它有很高的吞吐量以及可行性。
在大資料時代，這些使用者的行為資訊是很寶貴的，kafka很適合做這件事，他可以收集多台機器的使用者行為，進行資料分析和機器學習等重要領域。書中作者說kafka最開始就主要用於這個領域。
事實上，對於分布式資料收集工作使用kafka基本都是適用的，他不會給系統帶來很大效能壓力。
這裡我就不細說了，書中給出了幾個參考點，如下圖。
很多人可能認為kafka的訊息都是持久化到磁碟的記憶體並不是很重要，其實不然，在第一篇文章中我們說到對於kafka的訊息並不會直接持久化到磁碟上，他會先放入記憶體中的緩衝區，交由作業系統來決定何時刷進磁碟中。也是因為這個機制記憶體中緩衝區的大小尤為重要。所以可以盡可能多的去分配緩衝區的大小。
對於kafka這種網路傳輸大量資料的系統來說頻寬別的尤為重要。書中作者給出了乙個例子，假如我們需要kafka每小時傳輸1tb的資料，我們的頻寬為1bg/s，假設我們給kafka分配70%的頻寬，剩下的用於其他程序使用網路且網路不能總是打滿。所以一台機器一秒傳輸速率為10240.7 ≈ 710mb/s，我們的需求是10241024/3600=290mb/s,即2336mb/s，而且我們這70%也不是總是打滿，所以需要再擷取一部分，書中作者給出的是擷取1/3，可以根據業務選擇更合適的，所以乙個broker的速率大約為710/3=240mb/s，所以我們大約需要2336/240≈10臺機器，如果有兩個副本的話那我們需要20臺機器。
上面我們簡單說了一下頻寬規劃的乙個演算法，下面是書中作者給出的頻寬規劃建議。
從架構角度看移動APP
這與c s結構是一樣的。由於使用了客戶端的眾多特性，所以客戶端的表現力相當豐富，效能較高，使用者體驗也比較出色。但劣勢也比較明顯 客戶端的開發工作量大，邏輯複雜 客戶端不利於移植，必須針對不同的作業系統進行單獨的適配開發工作 客戶端軟體公升級和維護困難 伺服器端要支援多客戶端，難於擴充套件。現在採用...
從彙編角度看引用
引用型別到底是什麼？它和指標有什麼關係？它本身占用記憶體空間嗎？帶著這些疑問，我們來進行分析。先看 include include using namespace std void main 通過彙編檢視 如下 9 int x 1 00401048 mov dword ptr ebp 4 1 10 ...
從辯證的角度看產品
從辯證的角度看產品 然而，當我們用我們自身的思維角度去看待一款產品時，往往可能由於對產品接觸的時間太少，或者是使用到功能的不全面，導致我們對一款產品的認識只能達到乙個有限的程度，這往往是不可避免的。同樣的，當我們要去開發一款產品，往往可能由於對產品真正需求的不確定，或者是考慮的不夠周全，導致我們希望...