爲了節約成本，也是爲了順應去IOE這個大時代的發展，項目的數據庫從最初的Oracle切到了MySQL。
開始切到MySQL的時候項目才上線時間不長，當時數據不多，而且當時預計在較長一段時間內數據也不會發生爆炸式的變化，考慮到大部分是讀的請求所以考慮用主從架構。
注：存儲引擎用的是InnoDB，當時主要是考慮事物的需求，其實在選擇存儲引擎的時候沒有特殊需求都應該選擇InnoDB，關於InnoDB和MyISam的區別可參考：MySQL存儲引擎之MyISAM、InnoDB詳細對比。
市面上目前開源且比較有名字的中間件主要有3種，分別是360的atlas、阿里巴巴的Cobar(目前也有叫MyCat，其實應該都是說同一個東西)、淘寶的TDDL。
Atlas https://github.com/Qihoo360/Atlas/wiki
我們將Atlas作爲主從架構的中間件，之所以選擇Atlas是因爲其簡單只是做個純轉發的操作，所以對SQL語句的支持度也是很好的，且具有以下特性能滿足我們的需求：
1、實現讀寫分離；2、實現分表；
3、主庫宕機會被自動摘掉不影響從庫的讀，從庫宕機也會被自動摘掉不影響應用；
4、通過管理接口，簡化管理工作，DB的上下線對應用完全透明，同時可以手動上下線；
5、所有MYSQL支持的SQL，Atlas都支持。換句話說：Atlas並不分析SQL，只是把SQL語句路由到對應數據庫節點；
6、支持事物：事物內SQL全部走寫節點；
7、爲了解決讀寫分離存在寫完馬上就想讀而這時可能存在主從同步延遲的情況，Altas中可以在SQL語句前增加 /*master*/ 就可以將讀請求強制發往主庫；
8、能通過client-ips參數對有權限連接Atlas的ip進行過濾；
9、日誌中記錄所有通過Atlas處理的SQL語句，包括客戶端IP、實際執行該語句的DB、執行結果以及耗費的時間。
Atlas架構圖：
缺點：
1、Atlas在主庫或者從庫宕機摘掉後不會自動恢復，需要自己手動去或者寫心跳腳本去處理；
2、不能實現分佈式分表，所有的子表必須在同一臺DB的同一個database裏。
Cobar
隨着接入應用的激增，token表數據在未來可預計的時間內會發生重大變化，單表數據太大主從明顯已經力不從心，故而考慮了分庫分表，對於此種業務場景cobar是不二的選擇。我們使用cobar的一個很重要的考量是團隊中有人閱讀過並具有修改相關代碼的能力，且公司中其他團隊有相關的成功使用經驗。
cobar架構圖：
優點：
1、Mycat支持將一張表水平拆分成多份分別放入不同的庫來實現表的水平拆分；
2、Mycat支持將不同的表放入不同的庫。
缺點：
1、支持標準SQL99語法，不支持部分Mysql特定的SQL。
2、分庫字段不能UPDATE。
3、查詢條件中儘量帶分庫字段，否則掃描所有分庫節點合併結果集。
4、數據庫中新增表後，Mycat中必須修改配置文件，增加表配置。
5、對事物的支持不夠好,不支持SAVEPOINT操作。
6、不支持跨庫情況下的join、分頁、排序、子查詢操作。
7、分庫情況下，insert語句必須包含拆分字段列名。
8、分庫情況下，update語句不能更新拆分字段的值。