在胖狮工作一个多月了，记录一下，这次记录数据库相关问题。。。

        胖狮的数据库是主从备份，分别在一个城市的两个不同的地方，这样做的目的就是为了减少延迟，减少数据库数据不一致的问题。

        当然数据库主从备份有很多方式，

   第一：只有一个机房（所谓的allinone）

   第二：两个机房分别在城市的不同位置，这样做可以减少中从不一致，毕竟网络传输可能有波动，光纤也需要成本；

    第三：两个机房在两个两个城市的不同位置，这样的话就做了一个灾备，好处就是安全提高一点，毕竟两个城市都出问题的概率小于同一个城市的二个地方，饿了吗好像就是采用这种方式，一个机房在上海一个机房在北京，这样坏处也是同样对比出来看出，延迟可能会高，成本也相对较高；

    第四：两个机房在不同的国家，这个优缺点道理是相同的，但是吧，凡是都要有个度，你特码外国没有业务装这个逼干嘛，为了装逼而装逼吗？

            话说回来，胖狮采用的是第二种方案，毕竟干什么都要有成本，要落地，第二种显然主适合，因为最大程度上保证了数据一致性;既然有了主从数据库，使用方面目前市场基本使用mycat来完成对数据的分发落盘，mycat落盘规则有很多，

        1. 时间类：按天分片、自然月分片、单月小时分片）（缺点：数据可能过于集中，所谓干的干死，例如双11，在这段时间内大量数据全部落在一个位置）

        2. 哈希类：Hash固定分片、日期范围Hash分片、截取数字Hash求模范围分片、截取数字Hash分片、一致性Hash分片

        3. 取模类：取模分片、取模范围分片、范围求模分片

        4. 其他类：枚举分片、范围约定分片、应用指定分片、冷热数据分片

其他方式的问题就在于相同一段时间内的查询有点麻烦。

        存也存了，查也能查了，现在的问题是对于互联网来说，数据库总量是固定的，但是数据是一直不停的在增加，所以慢慢的数据库性能就相对变差，所以要提高优化；

        优化方式：

1. 数据归档：数据归档又有很多方式，可以把数据存到hbase,也可以把数据存到es等等；归档后，还有问题，如果客户发生退换货，则需要把归档的数据拉回；

2. 数据重组：我们在使用mysql 的时候，每次delete数据的时候，其实数据表空间并不会被释放，所以我们要手动释放；这个时候问题就来了，每次释放表空间，总不能在主库上操作吧？所以这个时候就是从库展示价值的时候了；每次执行操作，在从库上执行，那问题又来了 ，怎么只在从库上执行呢？

   这就涉及主从切换问题了:数据库是主备方式，简单来说：主库每次操作，会产生binlog ,从库会捞取到主库的日志，写到中继日志（relay log），然后在写进从库；原理基本上市这个原理，但是操作有点麻烦，你想切换主从，如何保证数据一致性，因为中继日志获取到写入是有个时间差的，最简单的实现方式就是：把主库设置成read-only=true 只读状态，只要从库主库在某一时刻保持一致，就可以切换，然后对从库进行操作；