資料庫選取之路

    公司的一個專案需要搭建一套伺服器，伺服器部署Tomcat+資料庫一套環境。伺服器的功能不是很複雜，將獲取的請求下發到RabbitMQ（佇列，一個開源軟體），並將請求插入資料庫。有個監聽器持續監聽RabbitMQ，如果有返回值，就將其插入資料庫。在此過程中，會有執行緒呼叫伺服器的介面查詢資料庫，直到有結果返回。資料庫設計也很簡單，只需要一張表格。

    一開始考慮到資料量不大，而且需要的表結構不復雜，所以一開始選用的是SQLite輕型資料庫。它是一個檔案型資料庫，資料都儲存的一個檔案裡面，操作簡單，效率高。開發測試通過之後，提供給內部使用者試用。但很快就發現問題了。使用者請求量大的時候會有資料丟失的現象。查詢了一些資料，預設狀態下，SQLite執行在自動提交模式下，在完成SQL語句的執行後，並沒有像標準的JDBC那樣直接把資料寫入到資料儲存檔案中。如果在insert操作進行的中途，有一個select操作到來，並且出現異常，就可能導致剛才insert的資料被丟失。本來是考慮在程式碼里加同步鎖來規避這個問題。但經過討論覺得這樣效率太低了，最後決定臨時更換資料庫。

    專案在開發的時候，是將資料庫操作寫在一個工具類裡面的，所以只是修改工具類，其他的程式碼不用變動，所以很快就改好了。安裝MySQL，測試，果然併發問題解決了。但在試用了一段時間之後，出現問題了，資料庫連線預設在8小時後自動斷開連線，導致了請求運算元據庫時報錯。一開始，是在資料庫連線路徑加個autoReconnect=true，讓其自動連線，但並沒有生效。查詢了資料，應該是資料庫版本造成的。最後，只能在my.cnf裡將interactive_timeout和wait_timeout時間延長，這個問題才算解決了。在試用了一段時間之後，又出現了一個問題，是有關max_allowed_packet ，由於請求返回值過大，MySQL根據配置檔案會限制server接受的資料包大小。大的插入和更新會被max_allowed_packet 引數限制掉，導致失敗。這個錯誤，一開始以為很容易解決，就在my.cnf裡將max_allowed_packet配置大一點，但是試了以後發現還是報錯了。這下就懵了，啥情況，配置的max_allowed_packet沒有生效，還是報錯。找了好久資料，終於在網上一個旮旯的角落找到了一個和我出現同樣的問題的帖子。最後他是將表的儲存引擎修改為MyISAM，我試了一下確實是解決了，但是原因，帖子最後還是沒有人給出個滿意的回答來。

    伺服器的資料庫選擇真是一波三折，前前後後花了我近2個月的時間才將這個伺服器搞穩定。