写入请求量大会造成性能和可用性的问题，如何应对呢？ 采取对数据进行"分片"，这是一种思想，在数据库中就是分库分表，Kafka中是分区，ES中是分片
分库分表的思想是根据某种分配策略把数据尽量均匀的分到多个数据库节点或多个表中，这样每个数据库节点和表都只存储部分数据，这样对数据的存储、读和写都有意义 存储:因为分库分表后每个节点和表只存储部分数据，这样就能解决数据存储的瓶颈 读:因为每个节点和表存储部分数据，数据量变小，可以提升查询性能 写:数据写入被分摊到多个节点和表，写入性能提高
分库分表有两种方式:垂直拆分和水平拆分 垂直拆分的关注点在业务相关性，原则是按照业务拆分，核心思想是专库专用，将业务耦合度高的拆分到单独库中 水平拆分是把单一数据库按照某种规则拆分到多个数据库和多个数据表中，关注点在数据的特点
水平拆分的两种方法 1.根据某个字段的hash值拆分 比如想把用户表拆成16库64表，方案如下 先对id进行hash操作hash(id)，这样有助于打散数据 然后对16取余 hash(id)%16，这样就得到了分库后的索引 最后对64取余 hash(id)%16%64，这样就得到了分表后的索引值
2.根据某个字段的区间或范围拆分 可以根据时间拆分
引入分库分表确实有很多优点，但也会引入新的问题 1.引入了分区分表键，也叫分区键 因为我们需要对分区键进行hash进行索引，这样就导致我们查询都要带上该分区键，比较好的解决办法是用id做分区键，但是如果有根据用户昵称查询的需求怎么办呢？ 解决办法就是建立一个昵称和id的映射表 2.一些数据库的特性的实现变得困难 (1)夸库join不可用 解决办法是在业务代码中做处理 (2)求count 采取第三方组件例如redis实现
引用
本文为学习笔记，原文为极客时间《高并发系统设计40问》第9讲，原文链接为time.geekbang.org/column/arti…