用空间换性能
该类型的两个方案都是用来应对高负载的场景，方案有以下两种：分布式缓存、一主多从。
与其说这个方案叫用空间换性能，我认为用空间换资源更加贴切一些。因此两个方案的本质主要通数据冗余、集群等方式分担负载压力。
对于关系型数据库而言，因为他的ACID特性让它天生不支持写的分布式存储，但是它依然天然的支持分布式读。
分布式缓存
缓存层级可以分好几种：客户端缓存、API服务本地缓存和分布式缓存。
咱们这次只聊分布式缓存。一般我们选择分布式缓存系统都会优先选择 NoSQL 的键值型数据库，例如 Memcached、Redis，如今 Redis 的数据结构多样性，高性能，易扩展性也逐渐占据了分布式缓存的主导地位。
缓存策略也主要有很多种：Cache-Aside、Read/Wirte-Through、Write-Back，咱们用得比较多的方式主要 Cache-Aside，具体流程可看下图：
我相信大家对分布式缓存相对都比较熟悉了，但是我在这里还是有几个注意点希望提醒一下大家：
避免滥用缓存
缓存应该是按需使用，从 28 法则来看，80% 的性能问题由主要的 20% 的功能引起。
滥用缓存的后果会导致维护成本增大，而且有一些数据一致性的问题也不好定位。
特别像一些动态条件的查询或者分页，key 的组装是多样化的，量大又不好用 keys 指令去处理，当然我们可以用额外的一个 key 把记录数据的 key 以集合方式存储，删除时候做两次查询，先查 Key 的集合，然后再遍历 Key 集合把对应的内容删除。
这一顿操作下来无疑是非常废功夫的，谁弄谁知道。
避免缓存击穿
当缓存没有数据，就得跑去数据库查询出来，这就是缓存穿透。
假如某个时间临界点数据是空的例如周排行榜，穿透过去的无论查找多少次数据库仍然是空，而且该查询消耗 CPU 相对比较高，并发一进来因为缺少了缓存层的对高并发的应对，这个时候就会因为并发导致数据库资源消耗过高，这就是缓存击穿。
数据库资源消耗过高就会导致其他查询超时等问题。
该问题的解决方案也简单，对于查询到数据库的空结果也缓存起来，但是给一个相对快过期的时间。
有些同行可能又会问，这样不就会造成了数据不一致了么？
一般有数据同步的方案像分布式缓存、后续会说的一主多从、CQRS，只要存在数据同步这几个字，那就意味着会存在数据一致性的问题，因此如果使用上述方案，对应的业务场景应允许容忍一定的数据不一致。
不是所有慢查询都适用
一般来说，慢的查询都意味着比较吃资源的（CPU、磁盘I/O）。 举个例子，假如某个查询功能需要 3 秒时间，串行查询的时候并没什么问题，我们继续假设这功能每秒大概 QPS 为 100，那么在第一次查询结果返回之前，接下来的所有查询都应该穿透到数据库，也就意味着这几秒时间有 300 个请求到数据库，如果这个时候数据库 CPU 达到了 100%，那么接下来的所有查询都会超时，也就是无法有第一个查询结果缓存起来，从而还是形成了缓存击穿。
一主多从
常用的分担数据库压力还有一种常用做法，就是读写分离、一主多从。
咱们都是知道关系型数据库天生是不具备分布式分片存储的，也就是不支持分布式写，但是它天然的支持分布式读。
一主多从是部署多台从库只读实例，通过冗余主库的数据来分担读请求的压力，路由算法可有代码实现或者中间件解决，具体可以根据团队的运维能力与代码组件支持视情况选择。
一主多从在还没找到根治方案前是一个非常好的应急解决方案，特别是在现在云服务的年代，扩展从库是一件非常方便的事情，而且一般情况只需要运维或者 DBA 解决就行，无需开发人员接入。
当然这方案也有缺点，因为数据无法分片，所以主从的数据量完全冗余过去，也会导致高的硬件成本。
从库也有其上限，从库过多了会主库的多线程同步数据的压力。
选择合适的存储系统
NoSQL 主要以下五种类型：键值型、文档型、列型、图型、搜素引擎。
不同的存储系统直接决定了查找算法、存储数据结构，也应对了需要解决的不同的业务场景。
NoSQL的出现也解决了关系型数据库之前面临的难题（性能、高并发、扩展性等）。
例如，ElasticSearch 的查找算法是倒排索引，可以用来代替关系型数据库的低性能、高消耗的 Like 搜索（全表扫描）。而 Redis 的 Hash 结构决定了时间复杂度为 O(1)，还有它的内存存储，结合分片集群存储方式以至于可以支撑数十万 QPS。
因此本类型的方案主要有两种：CQRS、替换（选择）存储，这两种方案的最终本质基本是一样的主要使用合适存储来弥补关系型数据库的缺点，只不过切换过渡的方式会有点不一样。
CQRS
CQS（命令查询分离）指同一个对象中作为查询或者命令的方法，每个方法或者返回的状态，要么改变状态，但不能两者兼备
讲解 CQRS 前得了解 CQRS，有些小伙伴看了估计还没不是很清晰，我这里用通俗的话解释：某个对象的数据访问的方法里，要么只是查询，要么只是写入（更新）。
而 CQRS（命令查询职责分离）基于 CQS 的基础上，用物理数据库来写入（更新），而用另外的存储系统来查询数据。
因此我们在某些业务场景进行存储架构设计时，可以通过关系型数据库的 ACID 特性进行数据的更新与写入，用 NoSQL 的高性能与扩展性进行数据的查询处理，这样的好处就是关系型数据库和 NoSQL 的优点都可以兼得，同时对于某些业务不适于一刀切的替换存储的也可以有一个平滑的过渡。
从代码实现角度来看，不同的存储系统只是调用对应的接口 API，因此 CQRS 的难点主要在于如何进行数据同步。
数据同步方式
一般讨论到数据同步的方式主要是分推和拉：
推指的是由数据变更端通过直接或者间接的方式把数据变更的记录发送到接收端，从而进行数据的一致性处理，这种主动的方式优点是实时性高。
拉指的是接收端定时的轮询数据库检查是否有数据需要进行同步，这种被动的方式从实现角度来看比推简单，因为推是需要数据变更端支持变更日志的推送的。
而推的方式又分两种：CDC（变更数据捕获）和领域事件。对于一些旧的项目来说，某些业务的数据入口非常多，无法完整清晰的梳理清楚，这个时候 CDC 就是一种非常好的方式，只要从最底层数据库层面把变更记录取到就可。
对于已经服务化的项目来说领域事件是一种比较舒服的方式，因为 CDC 是需要数据库额外开启功能或者部署额外的中间件，而领域事件则不需要，从代码可读性来看会更高，也比较开发人员的维护思维模式。
替换（选择）存储系统
因为从本质来看该模式与 CQRS 的核心本质是一样的，主要是要对 NoSQL 的优缺点有一个全面认识，这样才能在对应业务场景选择与判断出一个合适的存储系统。
这里我给大家介绍一本书马丁.福勒《NoSQL精粹》，这本书我重复看了好几遍，也很好全面介绍各种 NoSQL 优缺点和使用场景。
当然替换存储的时候，我这里也有个建议：加入一个中间版本，该版本做好数据同步与业务开关，数据同步要保证全量与增加的处理，随时可以重来。业务开关主要是为了后续版本的更新做的一个临时型的功能，主要避免后续版本更新不顺利或者因为版本更新时导致的数据不一致的情况出现
。在跑了一段时间后，验证了两个不同的存储系统数据是一致的后，接下来就可以把数据访问层的底层调用替换了。
如此一来就可以平滑的更新切换。
最后说一句
本文到这里就把八大方案介绍完了，这八个方案里，大部分都存在数据同步的情况，只要存在数据同步，无论是一主多从、分布式缓存、CQRS 都好，都会有数据一致性的问题导致，因此这些方案更多适合一些只读的业务场景。
当然有些写后既查的场景，可以通过过渡页或者广告页通过用户点击关闭切换页面的方式来缓解数据不一致性的情况。
最后，在这里再次提醒一句，每个方案都有属于它的应对场景，咱们只能根据业务场景选择对应的解决方案，没有通吃，没有银弹。
