软件架构读书笔记2

第二部分：计算机功底

主要讲解的是术。计算机功底、语言、框架、网络、数据库、操作系统等。

印象最深刻的是框架那一章。作者提到，熟悉一个框架之后，更多的是应该去关注它的缺点，而不是优点。更应该关注它不能做什么，而不是它能做什么。 它不能做什么往往是别的框架的改进点。

细想，如果你不关注它不能做什么，在你们拍板决定使用框架时，做了一半发现， 核心的一块需求它支持不了，这时候只能欲哭无泪了。

第三部分：技术架构之道

主要讲解的是道。 里面分为:

• 高并发问题
• 高可用与稳定性
• 事务一致性
• 多副本一致性
• CAP理论

因为这一部分主要是关于道方面的，所以很多地方是抽象化的。读者在读这一部分时候，针对一些问题的解决方案，需要自行去思考部分细节。

我主要分享高并发和事务一致性的笔记。其他读者可以自行查看。

高并发问题

要让各种各样的功能和逻辑在计算机系统中实现，只能通过读和写两个操作。

基于这个基础，在高并发问题上，书中对问题进行了分类。

侧重"高并发读"的系统

比如,搜索引擎、电商的商品搜索、微博热点、知乎热点等。

侧重"高并发写"的系统

比如，广告系统计费等

两者兼顾。

比如，电商的库存系统、秒杀系统、IM、朋友圈等。

之所以这样区分，是因为处理的策略会不同。

如果是侧重高并发读的，一般可以采取以下策略。

策略1:加缓存

案例一:本地缓存或Memcached/Redis

对应的加缓存需要考虑以下问题，

• 单点问题
• 缓存雪崩
• 缓存穿透
• 缓存击穿

单点问题，那么就需要多节点集群部署，通过类似心跳、哨兵模型等能自动剔除挂掉的节点机制。

后面三个问题一般和回源策略有关。

一种是不回源，只查询缓存。缓存没有，响应空。这种一般需要主动更新缓存，并且不设置过期时间，不会存在缓存击穿，大量key过期问题。

一种是缓存失效，需要回源。就需要考虑上面的问题。 对应缓存雪崩的问题，一般我们会在缓存本身时间的基础上，加上随机值，不让大批key同一时间失效。 对于缓存穿透的问题，一般上游做参数的校验，防止恶意请求。

对于符合规则的key，如果数据库没有， 一般会直接把这个key缓存起来，设置一个短暂的时间，值对应设置空。当然还可以通过布隆过滤器来实现，这时候，数据量已经很大了。

对应缓存击穿问题，一般我们采取的方式是保证同一时刻只有第一个请求打到db层，剩下的等待第一个同步结果即可。

案例二:Mysql的Master/Slave

上面提到的是简单的<key,val>缓存，还有一些场景会涉及到多表关联查询(如果避不开的话)，如果直接查业务库，高并发访问肯定顶不住的。 一般情况下，往往是通过主从部署，业务直接查从库关联就行了。分摊主库的压力(前提是没有进行分库)。

当前这种情况，高并发下还是会有问题，从库的压力还是太大了。这时候也可以把查询的结果缓存起来，下次直接从缓存拿。不过需要注意的是， 当关联的数据发生变化的时候，缓存就得更新了。

案例三:CDN静态文件加速

这个不用再描述了吧。

策略2:并发读

案例1:并发调用

核心思想就是，如果一个请求需要调用不同的三个服务a,b,c,且这三个服务相互之间不存在依赖关系，也就是请求c不依赖a或者b的结果， 那么请求就可以并发调用。总时间从(a+b+c)到max(a,b,c)。

案例2：Google 的"冗余请求"

假设一个用户的请求需要100台服务器同时联合处理，每台服务器有1%的概率发生调用延迟(假设定义响应时间大于1s为延迟)， 那么响应时间大于1s的概率是63%(计算规则可以自行查看) 咋么解决这个问题？ 冗余请求。简单点就是客户端同时向多台服务器发送请求，哪个返回的快就用哪个，其他丢弃。