[TOC] ## 分片 ### 范围：range 优点：简单，容易扩展 缺点：各库压力不均（新号段更活跃） ### 哈希：hash 优点：简单，数据均衡，负载均匀 缺点：迁移麻烦（2库扩3库数据要迁移） ### 路由服务：router-config-server 优点：灵活性强，业务与路由算法解耦 缺点：每次访问数据库前多一次查询 > 大部分互联网公司采用的方案二：哈希分库，哈希路由 ### 分组 **分组解决“可用性”问题**，分组通常通过主从复制的方式实现 > 互联网公司数据库实际软件架构是：又分片，又分组 ## 数据库架构设计思路 两主,两从,一主当备份,防止数据冲突 ### 扩展读性能 1. 第一种方式 : 建立索引 不同的库可以建立不同的索引 **写库** 不建立索引； **线上读库** 建立线上访问索引，例如uid； **线下读库** 建立线下访问索引，例如time； 2. 第二种方式 : 增加从库 1. 从库越多，同步越慢 2. 同步越慢，数据不一致窗口越大（不一致后面说，还是先说读性能的提高） 3. 第三种方式 : 增加缓存 ## 保证一致性 ### 方式一 1. 读cache，如果cache hit则返回 2. 如果cache miss，则读从库 3. 读从库后，将数据放回cache > 在一些异常时序情况下，有可能从【从库读到旧数据（同步还没有完成），旧数据入cache后】，**数据会长期不一致** ## 方式二:"缓存双淘汰"(推荐): 为解决第一个问题 1. 淘汰cache 2. 写数据库 3. 在经验“主从同步延时窗口时间”后，再次发起一个异步淘汰cache的请求 这样，即使有脏数据如cache，一个小的时间窗口之后，脏数据还是会被淘汰。带来的代价是，多引入一次读miss（成本可以忽略）