本文給大家分享一下當swoole數據庫消失了之后的處理方式

問題背景：物聯網項目saas，為分布式＋集群模式．swoole(worker+task+協程)+web+mysql(pool) ＋客戶server(記為cserver，設備的數據最終會往cserver發送一份)．有個法蘭克福客戶有三千臺設備，想著該地區暫時沒有新客戶，所以只是單機部署，想著4核8g配置肯定夠用了．周五收到通知，客戶的3k設備集體掉線，緊忙分析＋處理，此處記下筆記！

解決方案：

根據模擬場景的慢日志，添加一些平時未注意的索引

調整mysql max_connection參數，默認未224，我此前設置的為1000．當并發太大的時候，1k明顯不夠用了．

調整mysql　innodb_buffer_pool_size參數(數據和索引緩存的地方)，當你的server只做mysql時，此值設置為內存的70%~75%．因為我是單機設備，設置為40%.

適當加大了mysql　 innodb_log_file_size參數值

增大swoole中max_coroutine參數值，按常理，單worker能理想分配1g內存的時候，max_coroutine能設置成1w  乃至10w，因為一個coroutine默認為8k內存．

增大swoole中task_worker_num，理想情況下，tasknum可設置為1000．根據你的task處理速度看著調整，我此處設置為50來應對突如其來的高并發．

調整swoole中的worker_num，默認該參數為cpu核數，我平時也是這么設置的，明顯，當我task_worker_num增大的時候，worker的壓力也變大，所以我設置為cpu核數的2倍．

swoole_table的初始內存調整，這個設置不能在程序中動態調整，而每個連接id我這邊都是在sw_tb中記錄，所以初始化的大小需要大于未來幾年設備最大量．

新增managerStart和managerStop的回調，使得我們能更直觀地觀測manager的生命周期．

對數據庫連接池程序進行修改，盡量在拋出異常后妥善退出，而非導致worker/task的exit．

保證連接池程序內部參數以接口的形式暴露給swoole，從而我們在可視化界面了解每個task的連接池情況

對channel的errcode進行追蹤，當errcode為-1的時候，打印error日志，-2的時候發送短信通知/微信魔板通知

swoole程序中對數據庫連接池進行死鏈接排查

增大mysql的連接最長空閑時間，保證它大于swoole程序中連接池的最長空閑時間．

增加應急處理方案，即cserver宕機＋swoole掛掉．此處我們的解決方案是，引導設備切換server到另一集群．（此處雖然是單機部署，但是也有個中央服務器是留作調控的．　不過周五此服務器未起作用是因為，中央服務器我這有個調控程序，使得符合條件在若干時間后自動切換到相應服務器x，而此時x不是掛了嗎？　所以就有個循環，設備一直處于離線狀態！后面我們進一步完善了這個機制）

以上就是“swoole連接池案例之消失問題的處理方案”的詳細內容，想要了解更多swoole教程歡迎關注編程學習網