然後將 ES 裡面所有的景點全部再重跑一次 index (將資料儲存至 ES 裡面)。在重跑 index 前,Funliday 會用一些 NLP 的技術來判斷原本在 ES 裡面的景點是中文或日文。如果是日文的話,我們會再丟入中文詞庫裡面判斷詞性,如果是名詞的話,我們就會把這個景點名稱也認定為是中文。
graph TD;
A[開始] --> B{判斷景點名是中文或日文};
B -->|中文| C[儲存到中文欄位];
C --> END[結束];
B -->|日文| D[儲存到日文欄位];
D --> E{丟入中文詞庫判斷詞性};
E -->|名詞| F[可能是中文];
F --> C[儲存到中文欄位];
E -->|非名詞| END[結束];
最近 Funliday 常發一些精選旅遊回憶的 App 通知給使用者,在去年十一二月的時候發通知 Server 還能撐的了瞬時大流量的 request。
但今年開始發這類通知,總共發了三次,三次都造成 Server 被打掛,而且重開 AP 還緩解不了,瞬間手足無措。大概都要等過了十分鐘左右,Server 才將這些 request 消化完。
這裡就來簡單整理一下時間軸,順便分享一下 Funliday 是如何解決這個問題。
1/6 1900:系統排程發送精選旅遊回憶的 App 通知
1/6 1900+10s 開始:Server 收到極大量的 request
1/6 1900+20s:Nginx 出現錯誤訊息 1024 worker not enough,並回傳 http status code 503
1/6 1900+25s:PostgreSQL 出現錯誤訊息 could not fork new process for connection (cannot allocate memory)
1/6 1900+38s:Node.js 收到 PostgreSQL 的 exception。There was an error establishing an SSL connection error
1/6 1900+69s:PostgreSQL 出現錯誤訊息 database system is shut down
1/6 1900+546s:PostgreSQL 出現錯誤訊息 the database system is starting up
看了時間軸就覺得奇怪,先不論 10s 的時候發了極大量 request,造成 20s 在 Nginx 出現 worker not enough 的錯誤訊息。而是要關注 25s 時的 PostgreSQL 出現 could not fork new process for connection 的錯誤訊息。
這邊來分享一下自己程式碼的寫法,上面是原始寫法,在每個 API 都 create 一個 db client instance 來處理該 API 層的所有 db request。這是蠻單純的做法,也是 day 1 開始的處理方式。但有個小問題,就是每個 API 層都要自己 create instance,不好管理,且浪費資源。