采用twitter的snowflake 思想 生成一个自增(趋势自增 不连续)的id生成算法
Twitter的分布式自增ID算法snowflake 结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第1位 正负标记 id一般为正数 为0
接下来的41位为毫秒级时间，不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
41位的长度可以使用69年（ (1 << 41) / (1000L * 60 * 60 * 24 * 365) = 69 ）
接下来5位datacenterId和5位workerId，代表分布式节点(10位的长度最多支持部署 (1<<10=1024)个节点）
最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生(1<<12=4096)个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)
分库分表
一对一情况
这个没啥好说的 最简单的方法 按照id来取模即可
一对多情况
例如 一个用户 user(uid) 发表多个帖子 topic(tid,uid)
当帖子数据量过多时，topic需要分表(分库也是同样的原理)
- 如果按照uid来分表 则根据tid要快速查看一个帖子的详细时候，需要扫描全部的表
- 如果按照tid来分表 则要查看某个用户所有的帖子时候 需要扫描全部的表
上述两种方案都不完美，虽然可以新增一张表(或索引)来快速定位，但需要经过两次查询，影响效率
这里给出种权衡的方案：
- 假设topic分为16张表(最好为2的幂次方)
- 当用户id为 uid=12345 发表一个帖子的时候，对uid=12345 取16模 得9，二进制为mod=(1001)
- 生成tid的时候，根据上面的 snowflake 算法生成前60位数据，后四位为mod(1001)，得到tid
- 这样 根据uid 可以定位到表，根据tid也能定位到表
- 数据均衡度 每个用户发表的topic数均衡，每个表中的数据一般都是均衡的
多对多情况
这种情况就比较复杂了，还是要根据具体业务来分表
比如说订单系统中，有买家表 buyer(bid),卖家表 seller(sid),订单表 order(oid,bid,sid)
一般不会根据oid来分库，因为根据oid来查询数据的实际情况很少(买家，卖家至少都会登入一个)
可以适当的数据冗余，根据bid维度，存一个库，同时根据sid维度来存一个库
优势：卖家，买家要查自己订单时候，都能快速定位到具体的库中；
劣势：数据冗余
