[Heroku]DiscordJS上版流程紀錄

  • 第一次上版

heroku login

git init

heroku git:remote -a <app_name>

git add .

git commit -am "make it better"

git push heroku master

以上執行完畢後回到Heroku App畫面

在Resources的地方將web npm start關閉

Protfile中的worker打開

  • 後續更版

heroku login

git add .

git commit -am "make it better"

git push heroku master

 

留言

張貼留言

這個網誌中的熱門文章

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就都掛了，真棒。
閱讀完整內容