为了节约成本，也是为了顺应去IOE这个大时代的发展，项目的数据库从最初的Oracle切到了MysqL。
开始切到MysqL的时候项目才上线时间不长，当时数据不多，而且当时预计在较长一段时间内数据也不会发生爆炸式的变化，考虑到大部分是读的请求所以考虑用主从架构。
注：存储引擎用的是InnoDB，当时主要是考虑事物的需求，其实在选择存储引擎的时候没有特殊需求都应该选择InnoDB，关于InnoDB和MyISam的区别可参考：MySQL存储引擎之MyISAM、InnoDB详细对比。
市面上目前开源且比较有名字的中间件主要有3种，分别是360的atlas、阿里巴巴的Cobar(目前也有叫MyCat，其实应该都是说同一个东西)、淘宝的TDDL。
Atlashttps://github.com/Qihoo360/Atlas/wiki
我们将Atlas作为主从架构的中间件，之所以选择Atlas是因为其简单只是做个纯转发的操作，所以对sql语句的支持度也是很好的，且具有以下特性能满足我们的需求：
1、实现读写分离；2、实现分表；
3、主库宕机会被自动摘掉不影响从库的读，从库宕机也会被自动摘掉不影响应用；
4、通过管理接口，简化管理工作，DB的上下线对应用完全透明，同时可以手动上下线；
5、所有MysqL支持的sql，Atlas都支持。换句话说：并不分析，只是把语句路由到对应数据库节点；
6、支持事物：事物内全部走写节点；
7、为了解决读写分离存在写完马上就想读而这时可能存在主从同步延迟的情况，Altas中可以在语句前增加/*master*/就可以将读请求强制发往主库；
8、能通过client-ips参数对有权限连接Atlas的ip进行过滤；
9、日志中记录所有通过Atlas处理的sql语句，包括客户端IP、实际执行该语句的DB、执行结果以及耗费的时间。
Atlas架构图：
缺点：
1、Atlas在主库或者从库宕机摘掉后不会自动恢复，需要自己手动去或者写心跳脚本去处理；
2、不能实现分布式分表，所有的子表必须在同一台的同一个database里。
Cobar
随着接入应用的激增，token表数据在未来可预计的时间内会发生重大变化，单表数据太大主从明显已经力不从心，故而考虑了分库分表，对于此种业务场景cobar是不二的选择。我们使用cobar的一个很重要的考量是团队中有人阅读过并具有修改相关代码的能力，且公司中其他团队有相关的成功使用经验。
cobar架构图：
1、Mycat支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分；
2、Mycat支持将不同的表放入不同的库。
2、分库字段不能UPDATE3、查询条件中尽量带分库字段，否则扫描所有分库节点合并结果集。
4、数据库中新增表后，Mycat中必须修改配置文件，增加表配置。
7、分库情况下，insert语句必须包含拆分字段列名。
8、分库情况下，update语句不能更新拆分字段的值。
