系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
前面的七篇文章，从思路和方法论的角度介绍了微服务中的粒度、高可用、高并发、负载均衡以及微服务的重要组件连接池的一些基本问题。
在系统架构中，最容易先成为瓶颈的往往是持久层，后续的文章将会对如何进行数据库的架构进行思路上的梳理。
本篇的内容主要是数据库读性能的提升和引出数据库设计要考虑哪些问题。
数据库如何设计
沈老师常说的一句话：“任何脱离业务的架构，都是耍流氓”。
数据库的设计主要就是两个方面：库表设计、索引设计，而它们的设计指导：
- 根据“业务模式”，设计库表结构
- 根据“访问模式”，设计索引结构
读性能如何提升
提升读性能，最先想到的就是建立索引，但它也有潜在的问题:
- 写性能降低，每多建立一个索引，就会多一棵B+树，那么写操作的时候，就会涉及到更多的B+树，物理层面就是更多的数据页
- 索引占用内存大（如果建立了过多的索引，有些还是不常用的），buffer命中率降低，读性能降低
为不同实例，建立不同的索引
如图就是，主库只负责写入，所以不需要索引，对线上提供服务的索引，建立了uid的索引，为线下操作（比如简单的统计分析，后台访问等）提供服务的还要建立一些其它的索引。
当然，这会造成运维上的成本，不同的实例不同的索引设计需要额外的管理成本。
增加从库
这是首先很容易想到的方式，读写分离的主从架构的目的就是为了扩展读性能，这一方案已经在前面的文章多有提及，这里就不再重复了。需要明确的就是对于一个问题的解决方案要追问：它解决什么问题、它没有解决什么问题，它带来了什么新问题。 对于主从架构而言：
- 解决什么问题：读性能水平扩展的问题、读库高可用
- 没有解决什么问题：写高可用、写扩展
- 带来了什么新问题：主从一致性问题
增加缓存
缓存是提升性能万金油的方法，但是引入缓存也会带来一系列的新问题，这会在后续缓存的章节里再详细说明，这里先简单的讲一下带缓存的持久层的读流程：
- 上游先访问缓存，如果缓存里面有数据，则取得数据后直接返回
- 如果缓存里没有数据则访问数据库
- 再把取到的数据放入缓存
至于缓存的不一致性问题后续再讨论。
缓存的设计我们要考虑的是不“雪崩”，不雪崩可以做缓存高可用，也可以做缓存分片，分片的粒度就是某一分片不可用的时候不至于就打崩数据库。
数据库的工程架构设计必须考虑的内容：
- 读性能提升
- 高可用
- 一致性保障
- 扩展性
- 垂直拆分
这五个方面也是后续数据库章节的主要内容了。
微服务合集：
【成为架构师3-1】服务化：微服务架构，究竟解决什么问题
【成为架构师3-2】服务化：微服务的粒度，究竟要细到什么程度
【成为架构师3-3】服务化：必须保证高可用
【成为架构师3-4】服务化：必须支持高并发
【成为架构师3-5】服务化：必须搞定负载均衡
【成为架构师3-6】服务化：连接池，微服务的基础组件
【成为架构师3-7】服务化：连接池，高可用、可扩展、负载均衡都离不开它
下一篇更精彩：持续更新中…