[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(成本可以忽略)