一、分库分表
1.分库分表坚持两点原则
一个库的表不超过300
同一板块的数据在一个库里
2.主库主要存放
用户相关表
版块信息表
id生成表
评论帖子关系表等
users_1
......
users_16
3.分库
分库主要存放评论相关表
reply_1
...
reply_16
4.数据库配置
主库+3从库+1备库
分库一+从库+备库
分库二+从库+备库
5.数据较多的版块
对于数据较多的版块需要再分表。
二、拆分
1.根据模块id找库（分库一、分库二），再根据评论所在的版块id找表（reply_1--reply_16），从而确定库名表名。
2.拆分的优点：
a.将数据库压力/故障分散
b.易扩展
c.查询，更新及维护表结构速度更快
3.拆分后的问题
a.评论等需要一个专门的id生成表来生成唯一的自增id
b.拆分后不能进去join查询，这样就需要对用户信息，评论信息等进行缓存，这里选择了memcache。
三、拆分细则
1.查询切分
将ID和库的Mapping关系记录在一个单独的库中。
优点：ID和库的Mapping算法可以随意更改。
缺点：引入额外的单点。
2.范围切分
比如按照时间区间或ID区间来切分。
优点：单表大小可控，天然水平扩展。
缺点：无法解决集中写入瓶颈的问题。
3.Hash切分
四、id生成表
利用数据库自增ID
优点：最简单。
缺点：单点风险、单机性能瓶颈。利用数据库集群并设置相应的步长（Flickr方案）
优点：高可用、ID较简洁。
缺点：需要单独的数据库集群。Twitter Snowflake
优点：高性能高可用、易拓展。
缺点：需要独立的集群以及ZK。一大波GUID、Random算法
优点：简单。
缺点：生成ID较长，有重复几率。
5.时间戳+用户标识码+随机数
优点：
a.方便、成本低。
b.基本无重复的可能。
c.自带分库规则，这里的用户标识码即为用户ID的后四位，在查询的场景下，只需要订单号就可以匹配到相应的库表而无需用户ID，只取四位是希望订单号尽可能的短一些，并且评估下来四位已经足够。
d.可排序，因为时间戳在最前面。
缺点：长度稍长，性能要比int/bigint的稍差。
