《阿里云运维架构实践秘籍》读书笔记

食之有味

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. 缓存五分钟法则:

即如果一条记录被频繁访问,就应该考虑放到缓存里。否则的话客户端就按需要直接去访问数据库,而这个临界点就是五分钟

余味回甘

使用缓存牺牲了什么?

书中一直有一个说法:「缓存是一种典型的以牺牲数据时效性换取访问性能的技术」,我不太赞成这种说法。因为这样的表达是在说:使用缓存的缺点是没有或者减少了数据的时效性,我觉得这没有结合实际业务中使用缓存的前提——开发者肯定是在需要使用缓存的业务情景下才使用缓存的,也就是说我们为某个数据使用了缓存是知其可用性的,并没有牺牲什么实质性的时效性,这不算作是使用缓存的一种牺牲,缓存,就是临时存储在内存中的一组数据,该用时用,不该用时不用。

updatedupdated2021-10-232021-10-23
fix: tag name "运维" to "DevOps"
加载评论
点击刷新