第五周学习总结
本周介绍了缓存、消息队列、负载均衡和分布式数据库相关的特性及应用实践。
缓存
缓存和缓冲是不一样的:
缓存是为了解决多读性能问题，保护后端数据库不被压垮；
缓冲一般只读一次，是为了解决短时间处理速度达不到请求速度，会导致请求超时的问题。
缓存影响命中率的三个重要因素：1）Key集合大小；2）内存大小；3）缓存生命周期；
缓存分为通读缓存和旁路缓存：
通读缓存：读操作每次都从缓存获取数据，不会访问数据库；
旁路缓存：读操作先访问缓存，如果不存在，就访问数据库，并将获取到的数据加入缓存；
分布式缓存中间件：
redis: 分为多个桶存储数据，每台服务器存储数据不重叠，桶之间分享key和桶之间的关系，每个桶都知道任意key在哪个桶；
MapReduce：采用一致性哈希寻找服务器，服务器之间不通讯，架构更加简单，扩容更加方便，影响也小；
缓存在互联网系统中无处不在，通过层层缓存分担，将大量请求在业务服务、数据库上游消化掉。
缓存管理时，需要考虑缓存穿透防护、缓存雪崩（主要通过规范运维过程和使用一致性hash算法）、缓存预加载等问题。
缓存一般不做主动更新，当数据变更时，删掉缓存旧数据，下次读操作时，再写入缓存；
消息队列与异步架构
同步和异步：
同步会一直占用客户端线程，直到服务处理完之后才能释放；
异步可以再服务器收到请求后就返回，然后服务器处理完之后再通知客户端，客户端可以通过接收回调消息获得返回结果；
消息队列模型：
点对点模型：采用队列的数据结构，先进先出。特点是只会有一个消费者消费。
发布订阅模型：逻辑上相当于每个订阅者都有一个消息队列，MQ服务每收到一条消息，都会复制多份添加到订阅者队列中，所以每个订阅者都会收到消息。
消息队列服务的好处
异步处理，提高服务处理性能
更好的伸缩性
削峰填谷
解耦，服务间不依赖，只依赖消息队列服务
负载均衡
焦点：
把请求发送给哪个服务器；
如何把请求发送给服务器；
负载均衡方案：
HTTP重定向：每次请求都要重定向，性能较差。对外暴露服务器的公网IP也有安全问题。
DNS服务：一般一个客户端只解析一次，然后缓存使用。相对于HTTP重定向要好。
反向代理：由于HTTP包比较大，负载均衡服务器每次都需要拆包、装包，性能压力较大。小规模集群情况可以使用。
IP负载均衡：在TCP/IP层做负载均衡。TCP包相对于HTTP包，拆包、装包性能压力小。但是还是存在请求、返回两个方向都要经过负载均衡服务器，大规模集群下，网卡压力依然比较大。
数据链路层负载均衡：通过修改mac地址方式，请求经过负载均衡服务器，但是返回，可以直接返回到客户端，降低网卡压力。
负载均衡算法：
轮询
加权轮询
随机数
最少连接
源地址散列
session管理：分布式服务中，有些业务需要对session进行管理，保证业务服务能拿到用户的会话上下文。session管理方案有：
session复制：基本不会使用，反而增加带宽、存储压力；
session绑定（会话粘滞）：服务变成有状态的了，应用升级、伸缩变换时，用户就批量受到影响。
利用Cookie记录session：增加网络带宽
session服务器：适用于较大集群
分布式数据库
主从复制：主要解决并发读和高可用问题，可以分摊负载，数据热备。写库一般不支持读。
注意，涉及到DDL操作，需要人工干预，新增字段提前再各个写库和读库中新增。删除字段，要所有应用都不使用字段后，再执行。
主主复制：解决写库不是高可用的问题，通过虚IP+哨兵机制，做到动态切换。同一时刻只能有一个写库对外提供服务。
还未添加个人签名 2018.03.15 加入
还未添加个人简介
评论