Discord WebHook處理流程(Guess??)

 

最近加了不少群組，也看到有些群組在使用webHook進行跨伺服器聊天，所以才有感而發地想寫一下跟測試一下處理流程到底是怎麼進行的。

(但說實在的我也不知道我測出來的理解對不對)

首先是簡單的點對點，一般理解下的運作是像下圖

使用者1在A群組頻道中發文，傳給discordBot，轉交給B群組的webHook進行發文。反之亦然。

可是當兩個頻道間訊息過度頻繁，抑或是A群組頻道過度頻繁發話，會造成訊息無法傳至另一端的狀況，但此情形過一段時間即會解決，中間漏傳的也會隨之補上。

此情境發生的原因應是WebHook的cache堆積，或是過度頻繁傳送訊息，導致伺服器端認為被DDoS攻擊之類的。但如果假設我們在設定的ClientOptions是給WebHook的，而不是給Discord Bot的呢？以下是我以上圖為例思考的分流傳送方式。

以一開始我的預想，這樣進行分流的話兩個WebHook的負擔應該會分擔處理，也可以發送更多的訊息而不會出現cacheMemory溢出的狀況。

因為我只有一個人，也沒辦法測試多人發話的狀況，所以以下是我寫的SourceCode，用迴圈跟TimeOut的方式輪流跑兩個webHook。

結果大概跑到第30則訊息的時候就卡住了....這什麼狀況？回頭看DiscordServer想重新建立WebHook重跑，結果出現

然後我就有疑問了，既然我們在new Discord.WebhookClient的時候可以設定ClientOptions，那為什麼這邊兩個有分別設定了，可是跑的訊息數卻跟單個WebHook時一模一樣？

還是說這邊設定的ClientOptions不是給WebHook的而是給server的？那稍微調整一下的話呢？

測試完畢後發送訊息數有增加了，但還是會卡住，已經設定是最低了還是會造成訊息卡住的問題，看來是無法使用分流的方式來解決問題了。

於是我轉念一想，多開幾個機器人處理看看呢？

然後發不到五個訊息，兩邊的WebHook就都掛了，真棒。