现在互联网的信息量爆发，单个数据库的容量、读写性能，很快就达到了瓶颈，那怎么办呢，那就得扩展啊...
垂直扩展（向上扩展）
即堆砌硬件，512G内存，32核CPU，厉害不！
特点：
- 最简单（如果是云服务器，买买买就行了）
- 贵！！！
- 性能很快到天花板，花一倍的钱，可能只提升20%的性能（-。-）
- 适合短期提升性能解决问题，后期再水平扩展
水平扩展
即所谓的横向扩展、向外扩展，就是平时听到的分库分表分片啦
策略：复制、拆分、数据分片（Sharding）
- 复制
就是前一章讲的复制，一主多备，互为主备，读写分离
- 拆分
- 按功能拆分
比如一个大型应用，把论坛、新闻、支持，拆分成三个部分，三个不同的数据库（很少这么干）
- 数据分片
想要扩展写容量，就必须切分数据，目前用于扩展MySQL最成功的方案！把数据分割成一小块，储存到不同的节点中！
- 选择分区键
选分区键，决定了数据怎么存，怎么查询；
- 分配数据、分片和节点
分片和节点不一定是一对一的关系，应该尽可能的让分片的大小比节点容量小得多，这样就可以在单个节点上储存多个分片
- 在节点上部署分片
多种方式，比如按数据库名，表名，bookclub_23.comments_23，后面的数字是分片号
- 固定分配
比如哈希和取模，分到不同的“桶”中
- 动态分配
类似建立一个记录<->分片号的索引表，先找到分片号，再去读写数据
- 显式分配
把分片号和id都放在同一列中，比如高8位代表分片号，后8位用来储存id的值
- 生成全局唯一ID
- 使用自增字段，比如两台服务器，一台按奇数自增，一台按偶数自增，这样两台服务器就不会重复（不推荐这种，维护难）
- 在全局节点中创建一个表专门用来获取自增id
- 使用mamcached、redis这种生成自增数字并返回
- 批量分配数字：比如批量生成10万个id，不够了再来申请
- 使用复合id，比如分片号+自增id
- 使用GUID值，这个不方便复制（不推荐！）
- 分片工具
数据分片这种麻烦的事情，肯定不能硬编码啦，必须使用抽象层，需要解决以下几个问题：
- 连接到正确的分片并执行查询
- 分布式一致性校验
- 跨分配结果集聚合
- 跨分片关联操作
- 锁和事务管理
- 创建新的分片、重新平衡分片
牛逼的Sharding-JDBC了解一下！！！
