单KEY
当数据量越来越大时，需要多用户中心进行水平切分，常见的水平切分算法有“范围法”和“哈希法’。

范围法
优点

  • 切分策略简单，根据uid，按照范围，user-center很快能够定位到数据在哪个库
    上。
  • 扩容简单，如果容量不够，只要增加user-db3即可：
    缺点
  • uid必须要满足递增的特性。
  • 数据量不均，新增的user-db3，在初期的数据会比较少。
  • 请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-
    db1负载要高，导致服务器利用率不平衡。

哈希法
优点

  • 切分策略简单，根据uid，按照hash，user-center很快能够定位到数据在哪个库
    上。
  • 数据量均衡，只要uid是均匀的，数据在各个库上的分布一定是均衡的。
  • 请求量均衡，只要uid是均匀的，负载在各个库上的分布一定是均衡的。
    缺点
  • 扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移，如何平
    滑的进行数据迁移，是一个需要解决的问题

1对多KEY
在数据量较大，并发量较大的时候，通常通过元数据与索引数据分离的架构来满足不同类型的需求

索引表法
思路：建一个只有索引的表
缓存映射法
思路：访问索引表性能较低，把映射表放到缓存里
1. 如果数据量过大，可以通过login_name进行cache水平切分
潜在不足：多一次cache查询

基因法

++ 潜在问题一：同一个uid发布的tid落在同一个库上，会不会出现数据不均衡？

  • 回答：只要uid是均衡的，每个用户发布的平均帖子数是均衡的，每个库的数据就是均衡的。

++ 潜在问题二：最开始分16库，分库基因是4bit，未来要扩充成32库，分库基因变成了5bit，那怎么办？

  • 回答：需要提前做好容量预估，例如事先规划好5年内数据增长256库足够，就提前预留8bit基因。

多KEY
订单中心是一个非常常见的“多key”业务，主要提供订单的查询与修改的服务，其核心元
数据为：
Order(oid, buyer_uid, sellerLuid, time, money, detail.);其中：

  1. oid为订单ID，主键
  2. buyer_uid为买家uid
  3. seller_uid为卖家uid
  4. time, money, detail,….等为订单属性

前台访问，最典型的有三类需求：

  • 订单实体查询：通过oid查询订单实体，90%流量属于这类需求。
  • 用户订单列表查询：通过buyer_uid分页查询用户历史订单列表，9％流量属于这类需求。
  • 商家订单列表查询：通过seller_uid分页查询商家历史订单列表，1%流量属于这类需求。

多对多KEY
对于像订单中心一样复杂的“多key"类业务，在数据量较大，需要对数据库进行水平切分
时，对于后台需求，采用”前台与后台分离”的架构设计方法

数据冗余的方法有很多种：

  1. 服务同步双写。
  2. 服务异步双写。
  3. 线下异步双写（上图所示，是线下异步双写）。

最终一致性，是高吞吐互联网业务一致性的常用实践。保证数据最终一致性的方案有三种：

  1. 冗余数据全量定时扫描。
  2. 冗余数据增量日志扫描。
  3. 冗余数据线上消息实时检测。

shardingJDBC 使用
文档