评论系统的分库策略

一、分库分表
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切分

Hash切分
四、id生成表

1. 利用数据库自增ID
   优点：最简单。
   缺点：单点风险、单机性能瓶颈。

2. 利用数据库集群并设置相应的步长（Flickr方案）
   优点：高可用、ID较简洁。
   缺点：需要单独的数据库集群。

3. Twitter Snowflake
   优点：高性能高可用、易拓展。
   缺点：需要独立的集群以及ZK。

4. 一大波GUID、Random算法
   优点：简单。
   缺点：生成ID较长，有重复几率。

5.时间戳+用户标识码+随机数
优点：
a.方便、成本低。
b.基本无重复的可能。
c.自带分库规则，这里的用户标识码即为用户ID的后四位，在查询的场景下，只需要订单号就可以匹配到相应的库表而无需用户ID，只取四位是希望订单号尽可能的短一些，并且评估下来四位已经足够。
d.可排序，因为时间戳在最前面。
缺点：长度稍长，性能要比int/bigint的稍差。