食之有味
P73. CAP 定理：
CAP 定理（CAP theorem）指出，对于一个分布式系统来说，其不可能同时满足以下 3 点：
- Consistency（一致性）：所有节点在同一时间具有相同的数据。
- Availability（可用性）：保证每个请求不管成功或者失败都得到响应。
- Partition tolerance（分区容错性）：系统中任意信息的丢失或失败不会影响系统的继续运作。
这里推荐阮一峰的 《CAP 定理的含义》协助理解，各数据库模型的实现其实就是对 CAP 定理三个特性的不同取舍。
P79. SQL 语句优化：
- 80% 的数据库性能问题都出在 SQL语句上。
- 80% 的 SQL 语句性能问题都是由索引引起的。
这让我又想起曾经遇到的业务问题，事出正是慢查询，而处理这个性能问题时也正是通过先优化 MongoDB 的查询语句——前置业务查询条件及分页查询条件，再优化数据库索引得以缓解。这属实是慢查询的最佳实践了🎉。
P192. 存储引擎与服务器配置：
由于 MongoDB 存储引擎基于内存映射，因此高内存的配置能有效提升 MongoDB 的性能。
P254. K8S 部署应用：
在使用容器编排技术时，为了让对应容器高可用，也为了让机器性能的利用率更高，因此容器会根据状态是否存活，以及机器性能使用高低的情况，在不同的节点之间调度漂移。加上本身 K8S 就会消耗机器性能，所以总体来说，K8S 不适合部署对性能配置依赖很高的应用。这就间接说明了为什么我们一般很少将数据库部署在应用中，而是把业务代码部署在容器中，因为这样可以实现快速部署。
P278. 云端 DevOps 最佳实践：
GitLab + Jenkins + K8S + 微服务是云端 DevOps 的最佳实践。
没错，正是我们当下在做的！
P333. 缓存五分钟法则：
即如果一条记录被频繁访问，就应该考虑放到缓存里。否则的话客户端就按需要直接去访问数据库，而这个临界点就是五分钟。
余味回甘
使用缓存牺牲了什么？
书中一直有一个说法：「缓存是一种典型的以牺牲数据时效性换取访问性能的技术」，我不太赞成这种说法。因为这样的表达是在说：使用缓存的缺点是没有或者减少了数据的时效性，我觉得这没有结合实际业务中使用缓存的前提——开发者肯定是在需要使用缓存的业务情景下才使用缓存的，也就是说我们为某个数据使用了缓存是知其可用性的，并没有牺牲什么实质性的时效性，这不算作是使用缓存的一种牺牲，缓存，就是临时存储在内存中的一组数据，该用时用，不该用时不用。