原创 NSQ 源碼分析之NSQD--ProtocolV2

今天來說說NSQD.TCPServer中的核心函數IOLoop的具體實現,IOLoop主要的工作是接收和響應客戶的命令。同時開啓messagePump goroutine 進行心跳檢查,給訂閱者發生消息等操作。 詳細流程參考 https:

原创 NSQ 源碼分析之NSQD--lookup

今天主要講的是 NSQD 中 lookup, 其主要作用是告知 Lookupd,當前 NSQD 實例的情況,包括心跳檢測,Topic 和 Channel 的變化。 主要代碼文件: 1.nsqd/lookup_peer.go  主要定義了一

原创 NSQ 源碼分析之NSQD--TCPServer

今天來說說NSQD中的TCP 服務,TCP服務的任務包括接收/處理/響應發佈、消費、延時、消費確認等命令。 詳細流程參考 https://blog.csdn.net/H_L_S/article/details/104709619 中的邏輯

原创 MQ與RPC的區別

背景      曾經傻傻的分不清 MQ 與 RPC 的區別到底是什麼,我一直理解的是 MQ 和 RPC 都是將請求或者消息封裝( json/xml/probuffer 等),然後通過TCP或者HTTP等協議將請求交給另一個節點處理,從而實

原创 NSQ 源碼分析之NSQD--Exec相關函數

在NSQD的TCPServer,當客戶端與服務連接成功之後,會有一個goroutine專門處理這個連接的請求,在上篇中的IOLoop中,可看出服務以\n 爲分隔符作爲一條命令的結束(協議)讀取客戶請求,然後在將命令分解成 “命令 參數 參

原创 NSQ 源碼分析之NSQD--Topic

今天主要講的是NSQ topic 的代碼實現,topic作爲MQ的重要概念,瞭解它的實現,對我們理解其他MQ的topic,有很多的益處。 主要代碼文件: 1.nsqd/topic.go topic結構體 type Topic struc

原创 工作六年的一些迷茫與想法

   如果你是一個有追求的人,在人生的每個階段,每個隔一段時間會感到一陣迷茫,這是一種常態,這說明你對你的人生負責,它往往會成爲你一個“新”的起點。    作爲一個程序員,一個PHPER,已工作六年,在過去的六年時間,總會感到迷茫,不知所

原创 NSQ 源碼分析之NSQD--消息協議 Message

今天主要講的是 NSQD 中 消息協議 Message,Message 主要作用是對客戶端發送過來的消息進行Message 封裝,然後等待消費者消費 或者將 Message 轉換爲字節流發送客戶端。 主要代碼文件: 1.nsqd/mess

原创 NSQ 源碼分析之NSQD--queueScanLoop

今天主要講的是 NSQD 中 queueScanLoop代碼實現,這個函數的作用是用來維護 channel 中的延時隊列和等待消費確認隊列。將超時的消息重新加入消費隊列中。 主要代碼文件: 1.nsqd/nsqd.go queueScan

原创 NSQ 源碼分析之Lookupd--DB

今天主要講的是 Lookupd數據存儲方式(DB)。Lookupd主要保存三種信息,一是 NSQD 身份信息,二是 NSQD Topic 信息,三是 NSQD Topic 中 Channel 信息。 主要代碼文件: 1.nsqlookup

原创 NSQ 源碼分析之Lookupd--lookup啓動

今天主要講的是 NSQD 中 Lookupd, NSQD通過Lookupd實現分佈式集羣。從前幾篇的源碼分析中可知 NSQD 與 Lookupd 的協作方式有以下幾點: 1.NSQD啓動時,會通過 TCP 上報它自己的身份信息給所有的Lo

原创 單點登錄的簡單理解(SSO)

實現原理 1.SSO的實現主要是通過cookie機制實現,當瀏覽器與後臺服務交互時,瀏覽器會將該域名下的所有cookie鍵值攜帶到服務器,這樣服務器就可以獲得cookie的鍵值。 2.cookie的鍵值會保存的瀏覽器指定的目錄中,所以在同

原创 RabbitMQ/RocketMQ/Kafka 如何提高消費速度

RabbitMQ 1.RabbitMQ 無法向Kafka or RocketMQ 一樣提高並行速度。 2.RabbitMQ中,一個Queue 可以被多個消費者同時消費。所以可以增加消費者的數量來提高消費速度。 3.那麼如何提高單個消費者

原创 RabbitMQ/RocketMQ/Kafka 消息順序

RabbitMQ RabbitMQ 無法做到消息有序的原因: 1.RabbitMQ支持一個隊列多個消費者進行消費,並行處理消息無法保證順序。 2.RabbitMQ支持重試及超時重試機制,這也是導致無法順序消費的原因(即使只有一個隊列一個消

原创 MySQL SQL查詢時間評估

提前說明: 1.TR  表示隨機I/O查找(假設爲10ms) 2.TS  表示順序I/O查找(0.01ms) 3.TR查詢的速度遠遠小於TS 4.一次的查詢,最少一次隨機I/O 5.通過索引查詢,如果無法滿足覆蓋索引條件,需要進行一次回表