架构师训练营第五周总结
跳出技术本身，体会背后的架构思想。一个技术被淘汰了，思考为什么被淘汰了？
缓存架构
缓存指标
缓存关注的指标是缓存命中率。
缓存命中率取决于缓存对象生存时间(TTL)，key集合大小，缓存可使用的内存空间。
缓存种类
通读缓存(read-through) 例子：反向代理缓存，CDN缓存。
旁路缓存(cache-aside) 例子：Memcached often used in this manner
Memcached分布式对象缓存
路由选择算法：consistent hashing （非常经典）
基于虚拟节点的一致性哈希算法，实战时一定需要虚拟节点。（150-200）目的：负载均衡。
实现的数据结构：TreeMap
一条数据：
Redis: 0.5ms
Database with index: 50ms 差了100倍,简单，性能提升显著。
为什么这么快：
内存比磁盘访问快
缓存存储数据的最终结果形态，不需要中间计算，减少CPU资源消耗
缓存降低数据库，磁盘，网络的负载压力，使这些I/O设备更responsive
注意：
频繁修改的数据：一般来说，数据的读写比在2:1以上，缓存才有意义。
没有热点的访问：如果应用系统访问数据没有热点，不遵循二八定律，那么缓存就没有意义，因为大部分数据没有被再次访问就已经被挤出缓存了。
数据不一致与脏读：对缓存的数据设置失效时间。因此应用要容忍一定时间的数据不一致。（比如提示：数据正在审核中）还可以使用失效通知。
缓存雪崩：当缓存服务崩溃的时候，数据库会因为完全不能承受巨大的压力而宕机，导致整个网站不可用。
缓存预热: 事先从数据库加载元数据到缓存进行预热。
缓存穿透：如果不恰当的业务或者恶意攻击持续高并发的请求某个不存在的数据，击穿缓存，给数据库大压力。一个简单的对策是将不存在的数据也缓存起来(value is null)，并设定一个较短的TTL。
Redis vs Memcached
基本用Redis。
Redis 支持复杂的数据结构。
Redis 支持主从复制高可用。
消息队列和异步架构
提升写场景的性能。
提升伸缩性。
削峰填谷。
失败隔离和自我修复
解耦
在异步处理时， 写入消息队列后异步接受响应通常不返回结果，比如下单，可以返回已经下单。因为我们无法保证消息队列里的消息可以成功处理。
例子：阿里的RocketMQ，Kafka, ActiveMQ, RabbitMQ
负载均衡架构
Web服务器集群可以是用内网域名。安全。当服务器宕机时，只要在负载均衡服务器上改配置就好。
DNS负载均衡
域名解析的结果会缓存在本地，所以性能问题不大。而且域名解析是需要的。（Geographical load balancing)
安全性问题？（TODO）一般后面加一层负载均衡。
反向代理负载均衡
反向代理服务器本身就是处理HTTP的服务器。所以太多请求会让反向代理服务器负载压力很大。所以一般用于中小集群比如20多态服务器。
IP负载均衡（第三层）
性能远高于反向代理负载均衡（应用层的负载均衡）。原IP地址和目标IP地址在负载均衡服务器都会改。
数据链路层负载均衡
IP没有被修改过，TCP/IP链路是通的。这是大型网站最常用的。
分布式数据库架构
复制：
增加系统的读并发能力，而不是写并发能力
更新表结构会导致巨大的同步延迟
MySQL主从复制
从服务器不能写数据，提供只读操作。分摊负载，增加系统的读并发能力，而不是写并发能力。
专机专用。（比如数据分析团队使用一个从库）
高可用。
备份
MySQL主主复制
不能同时向两个主库写数据。两个数据库不能并发写入。只能在一台上写操作，当一台宕机时，让另外一台成为写操作的库。
还未添加个人签名 2019.09.17 加入
还未添加个人简介
评论