
我是名為 Simplex 的開源 Discord 機器人的建立者 / 開發者。在這篇文章中,我想帶你瞭解一下這個專案所做的一些決定、問題和缺陷修復,以及專案啟動的原因。Simplex 是我 14 歲時建立的一個機器人,現在它執行在 500 臺伺服器上擁有 8.4 萬用戶。我希望你們和我一樣享受我的開源之旅。
我 3 年前(2021 年 10 月 15 日)創辦了 Simplex。那時候,它還不叫 Simplex;這是 Michael Media Group 的教程機器人,我在那裡製作 Python 教學影片。目前還不清楚這個教程機器人在哪裡結束的,Simplex 又是從哪裡開始。第一次 GitHub 提交的日期為 2021 年 10 月 25 日。Simplex 是一個我可以據此製作教程的想法試驗場。然而,教程一直沒有做出來;但我不斷地將想法打包到這個測試機器人中。
最初的目標是幫助人們製作一些東西,而不是每月為 Mee6 這樣的機器人支付大筆訂閱費。我釋出了這個機器人之後,一個很大的驅動因素就是用一個關心社群的開源機器人取代了我朋友所使用的所有付費工具。
剛開始的時候,我曾經認為所有的費用都是隨意的。成本莫名其妙地高得離譜。當我的機器人開始獲得一些吸引力時,我意識到需要某種形式的收入來支付成本,所以我建立了一個“給我買杯咖啡”專案。我還意識到,一些機器人(如 Mee6)沒有理由向終端使用者收取隱藏費用。像這樣的機器人讓我很不安,因為它們的目標顯然是想從那些不那麼瞭解自己支出情況的年輕人那裡賺走儘可能多的錢。
Simplex 最初執行的是 discord.py,並在我的計算機上本地託管。它工作得很好——那時只有我和我的幾個朋友在使用這個機器人,我比其他任何人起得都早,並且是最後上床睡覺的。
隨著機器人開始增長到 20 或 30 臺服務者時,我覺得讓我的電腦一直開著不是一個好的解決方案,所以我把它轉移到了它們最便宜的 DigitalOcean 計劃上。我已經在執行一個名為未知硬幣的加密貨幣的根節點了,這是我在一年前 14 歲時建立的。後來,我轉向了 Hetzner,因為 RAM 更多價格也更便宜,我目前仍在使用它。
剛開始的時候,我不得不在 discord.js 和 discord.py 之間做出選擇。我以前曾設法使用 Python 來完成小任務和自動化,並且我曾設法用 JS 列印了“Hello World”,因此 Python 是明確的選擇。Discord.py 相對易於使用。在機器人的前六個月裡,我使用了 discord.py,直到它被棄用,這給我留下了兩個選擇:Pycord 或 Hikari。
我之所以選擇 Pycord,是因為它與 discord.py 有很多相似之處。(事實上,Pycord 是 discord.py 的一個分支。)也是在這個時候,我得到了一位名叫 Sid 的程式設計師的幫助,他做了一些提交,建立了我們現在使用的流行的離職系統(也不小心第二次刪除了我們所有的使用者資料)。(經過一番說服,我在本文中添加了這個故事。)
Sid 時不時地會帶來一些有用的提交和反饋。也是在這個時候,我們邀請機器人的人數激增。它在一週內爆炸了,這導致了資料丟失的問題(即使 Sid 沒有刪除它)。
JSON 檔案最初被用作資料庫。回想起來,這是一個糟糕的想法,根本不應該發生,但當時我只是一個 14 歲的孩子,以前從未有過需要長期儲存資料的專案。JSON 似乎很容易使用。問題是,如果兩個不同的伺服器試圖同時訪問 JSON 檔案,其中一個或兩個伺服器都會被覆蓋。
當然,這不是我想要的,所以我學習了 SQLite3,由於它非常簡單可靠,我強烈推薦它。我相信你們中的一些人可以看到這裡的問題。如果你做不到,不用擔心——我花了幾個月的時間才意識到這一點。SQLite3 是阻塞的,而不是非同步的(阻塞與非阻塞)。如果計數系統變得更受歡迎,這有可能會減慢機器人和響應時間。
這導致我重寫了我們所有的資料庫呼叫來使用 aiosqlite。Aiosqlite 仍然是一種 SQLite 資料庫,就像 SQLite3 一樣。不同之處在於,Aiosqlite 是一個同一型別資料庫軟體的不同庫和實現。
求值問題求值是一個一直令人頭疼的問題。一開始,我只是在使用 Python 內建的 eval() 函式,直到我在 Discord 上看到有人說“eval 是邪惡的”,然後我搜索了一下。事實證明,我建立了一個安全漏洞,計數通道中的任何有效 Python 程式碼都將被執行。
幸運的是,在有人利用它之前,我們很快就注意到了這一點。我的第一個想法是將讀取的字串過濾為數字和 – + ! * / < >。然而,這裡有兩個問題:
1.它將不再計算二進位制、十六進位制等。(這不是一個大問題,因為我可以重新實現它們。)
2.透過計算大量的數字,機器人可能會崩潰。
事實證明,如果你在 Python 中執行 eval(10 10 10),它將會使程式崩潰。(一個有趣的事實:我瞭解到這是一些公共機器人的問題。我確實嘗試聯絡了一些人來讓他們瞭解這一情況。)在嘗試了一些解決方案後,我決定使用庫來保證安全並阻止溢位錯誤。
最後一個與計數有關的大事件是 base69。我上了一堂關於八進位制和十六進位制的計算機科學課,我的一個朋友說:“你知道,如果有一種使用 base69 的方法,那就太有趣了。”半小時後,我在午休時間釋出了一個 Python 包,然後那天晚上,我決定將其實現到 Simplex 計數系統中。
大多數人在看到 Simplex 中的檔案和資料庫的數量時,會問兩個問題:
1.“為什麼要建立這麼多資料庫檔案,而不是在一個數據庫檔案中建立所有表?”
2.“為什麼有這麼多的 Python 檔案?”
每個 Python 檔案都是一個 Cog。Cog 是“一個類中的命令、監聽器和一些狀態的集合”(discord.py 文件)。
採用模組化設計有以下幾個原因:
-
除錯:有時很難弄清楚到底是什麼導致了機器人崩潰,或者所有的儲存都到哪裡去了。Cog 可以在機器人執行時載入和解除安裝。
-
開發:在我的筆記型電腦上工作時,我沒有所有資料庫的副本,所以我可以在一個 Cog 及其相應的資料庫上工作,而無需進行大量設定。
-
開源:這允許人們只需從 GitHub 下載一個 Cog 檔案,就知道它能工作。
我們很早就遇到了兩次資料丟失的情況。可能有一些服務非常能理解我們,他們知道我們是兩個 14 歲的孩子在網際網路上釋出程式碼。
在編寫程式碼時,一些空白資料庫檔案被推送到了 GitHub。當我被告知一切都已被清除時,我運行了一個我新增到機器人中的命令,以拉取檔案並重新啟動機器人。不幸的是,Sid 的測試資料庫仍在儲存庫中。
關鍵教訓:
-
管理開源不僅僅是編寫程式碼。
-
為成功做準備與為失敗做準備同樣重要。
-
我深入學習了 Python,發現了它的怪癖和力量。
原文連結:
https://blog.michaelrbparker.com/post/
AICon 2025 強勢來襲,5 月上海站、6 月北京站,雙城聯動,全覽 AI 技術前沿和行業落地。大會聚焦技術與應用深度融合,匯聚 AI Agent、多模態、場景應用、大模型架構創新、智慧資料基建、AI 產品設計和出海策略等話題。即刻掃碼購票,一同探索 AI 應用邊界!

今日薦文
