gusher.cluster 介紹
之前有寫一篇文章介紹自己的練習專案 gusher,沒想到過沒多久,竟然朝著要cluster方向前進,所以理論當然它就進化了,稍微紀錄一下這兩年來的變化。
首先,我們先來看看下面這張架構變化圖,左邊為舊的gusher,右邊為gusher.cluster
為了因應連線上越來越大的需求,在gusher推出後,就開始設計如何能夠簡易的橫向擴充機制,由上圖可以看出,原本的機制必須要由gusher,承受全部流量,改成右邊gusher.cluster的狀態後,透過redis當作平行擴充的一個轉接,gusher.cluster,主要分成兩個mode:
- slave mode: 只提供一個功能,客戶端websocket連線,每一個slave mode server,各自管理自己的連線,接收到來自redis推播來的訊息,再透過演算法把訊息個別送到該訊息的訂閱客戶端。
- master mode: 則是接收其他服務想要對客端傳送訊息,把訊息推入redis。
目前這個架構下,還是無法避免單點故障(SPOF),只要redis死掉,服務會全部死掉,未來的改版會朝這個方向去改進去。
在這個版本gusher.cluster實現了channel機制,客戶端可以依照自己權限,訂閱自己想要聽的channel,沒訂閱到的channel,客戶端並不會收到。與舊版本gusher的差異在於,舊版本一條連線建立後,所有需求都必須要在這條線上傳送,如果有新增業務邏輯,除非多加連線,否則客端的js需要實作很多特殊邏輯去繞過。在這點上節省了非常多不必要的開銷。
當然原本的gusher對客戶端完全單是單向溝通,客戶端無法反向傳訊息回server,在gusher.cluster改善了這一點,新增的remote的命令,做到可以跟server雙向同步溝通。以達到更多的應用。
下一篇會介紹有關於remote的進階應用。