1樓：huxihx
Linux核心和Kafka延時請求處理機制都應用了分層時間輪理論或演算法來實現各自的定時器。應該說，它們的使用場景是非常類似的。在核心和Kafka看來，它們都有一些明顯的異同：
核心採用了陣列+鍊錶方式儲存延時事件。共有8層陣列，每層陣列固定32個槽。每個槽儲存相應超時時間的所有事件。
Kafka採用DelayQueue來儲存每個Bucket。每一層時間輪固定20個Bucket，而每個Bucket下又使用雙向迴圈鍊錶來儲存具體的延時請求。因此對於第一層的時間輪來說，核心會儲存在未來0~31ms後超時的所有延時事件，而Kafka會儲存在未來0~19ms超時的所有請求。
核心只有8層，而Kafka理論上沒有上限。另外核心使用乙個Bitmap來對所有的時間輪層次做索引。而對於Kafka而言，就像我前面說的，它用的DelayQueue來定址。
核心使用這套時間輪演算法用於實現低精度的超時定時器，因此在精度上有些犧牲，即不要求那麼準確。比如第一層時間輪只能儲存超時時間在未來0~31ms的所有事件，因此未來36ms超時的事件就只能放入下一層時間輪的第乙個槽中，這個槽的過期時間是40ms（因為第二層的jiffy是第一層的8倍，即8ms，因此第二層第乙個槽涵蓋的時間範圍是[32ms, 40ms]），因此這個事件將在40ms時超時，比預期晚了4ms。核心認為這種些許的延時影響不大，因為對於很多超時事件來說，很多情況下它們在超時之前就被取消了。
因此沒必要這麼精確。但對於Kafka而言，目前沒有引入這種deferred延時的機制，它的做法類似於核心第一版的時間輪演算法，即某一層時間輪過期後，Kafka會將這層的所有未超時事件重新插入回下層的時間輪中。如果用核心語言來描述，這個過程叫向下級聯（cascading down），而這個過程是最費時的，這也是核心開發人員開發第二版時間輪演算法的初衷：
即引入適當的超時延時，從而避免這種向下級聯的操作。雖然你覺得這種記憶體級的拷貝應該很快，但對於核心來說，這種操作並不是快取友好的（cache friendly），因此還是要優化的。在我看來，這可能是核心和Kafka在應用分層時間輪上最大的區別。
Parallels 中的 Linux 如何跟 Mac 共享資料夾？
Sharing Folders and Disks http download.parallels.com desktop v4 docs en Parallels Desktop Users Guide 22907.htm A shared folder is a folder on your M...
Linux 中的 console terminal tty pty pts 有哪些區別？
藍貓淘氣三千問 說起這幾個東西，需要提一下幾十年前的計算機。40幾年前，計算機有點大，就像下圖那樣 這麼大的計算機需要控制台 console 來配置 管理和監控，所以就有了下面這個東東 console 控制台需要連線顯示裝置，當時的技術要求連線顯示裝置的線纜要短，所以控制台一般和主機放在一起。當多使...
Linux 系統 proc meminfo 中的 DirectMap2M DirectMap4k 是什麼意思？
海楓 如果了解Linux的虛擬記憶體機制，就會清楚以下事實 1 32位系統，核心態虛擬空間 3G,3G 896M 這段空間為線性對映空間，它直接對映到 0,896M 物理空間，這個空間在OS執行過程中永遠也不會變 2 64位系統，這個線性空間變大了，物理記憶體有多大，線性空間就有多大，這個對映也是不...