第五周笔记

本周概要

本周主要讲述了分布式缓存的基本概念，基本原理，缓存的种类和应用场景，分布式缓存的一致性 hash 算法原理；然后是通过消息队列来实现异步架构，并讲述了异步架构带来的好处；最后部分讲解的是负载均衡架构，以及各种负载均衡实现原理和应用场景，以及相关的算法。

我的理解：

通过本周的学习，我对当今互联网架构师所需要掌握的基础方法，原理、线路有了更加清晰的认识，也渐渐深入到更加基础的技术原理和实现，以及针对解决的问题，不过我觉得要想成为一个优秀的架构师，光听老师的课程远远不够，老师的课程只是指明了一条道路和方向，而具体的路则需要自己脚踏实地的一步一步走完，过程中遇到的种坑和问题都需要自己亲自去解决，有了老师的指引，我想我能更快更好的走下去。

分布式缓存架构

基本概念和原理、衡量指标

什么是缓存

• 介于数据访问者与数据源之间的一种高速存储，用于加快读取的速度

• 缓存和缓冲的区别

缓存主要是从高速存取设备中读取

缓冲主要是用于高速设备向低速设备中读和写

我的理解：

缓存最核心的作用就是提升性能，减少网络请求步骤，最近节点返回数据，从而节省流量，降低成本。

缓存数据存取（Hash 表）

我的思考：

利用 Hash 读取的算法复杂度只 O(1),从而根据 Key 快速找到物理地定位到 Value，这是软件算法层面的实现。

而硬件层面上，直接把低速的硬盘中的数据复制到高速的内存中直接返回，从而几十上百倍提升读取速度

缓存的关键指标

• 缓存命中率

• 缓存键集合大小：缓存键数量越小，缓存的效率越高

• 缓存可用内存空间：物理上能缓存的对象越多，命中率就越高

• 缓存对象生存时间：对象生存时间越长，对象被重用的可能性越高

我的思考：如何提升缓存命中率，需要从业务角度去仔细分析数据的变化和读取频率。一种是频繁读，写得小的数据作为热点数据，命中率自然要高；另一种是读写取频率少的数据刚作为冷数据；最后一种是写多读少的数据尽量不放缓存。

各种介质数据访问延迟

缓存的各种形式和应用

代理缓存

反向代理缓存

多层反向代理缓存

CDN 缓存

通读缓存

旁路缓存

浏览器对象缓存

本地对象缓存

本地对象缓存构建分布式集群

远程分布式对象缓存

Memcached 分布式缓存

• Share-Nothing 模型

• 由客户端实现路由算法去匹配对应的缓存服务器

• 这种本地路由算法存在增加节点后，缓存不均匀的问题

我的理解：以上各种缓存的应用场景是不一样的，实现的机制和原理也有差异，充分理解场景和原理差异是掌握好各种缓存应用的关键，这需要自己花更多的时间和实践中去学习掌握。

分布式缓存的一致性 Hash 算法



我的实现思路:

1 一个 SortedMap 保存所有的虚拟结点，以虚拟结点的 hashcode 为 Key Value 直接就服务器 IP

2 三个核心方法

添加服务器

删除服务器

根据 Key 查找服务 IP

缓存的常见问题和解决方法

数据不一致与脏读

缓存雪崩

缓存穿透

缓存预热

Redis VS Memecached

• Redis 支持复杂的数据结构

• Redis 支持多路复用异步 I/O 高性能

• Redis 支持主从复制高可用

• Redis 原生集群与 share nothing 集群模式

redis 集群重点分享一个分布式缓存 redis 集群的部署维护方案(我自己的工作)

分布式缓存发现问题检查项

1)   业务报错分布式缓存无法创建更多连接

优先检查分布式缓存集群所有节点的连接数,使用 info client 命令，如果连接数接近或者已经无法通过后台登陆服务节点，说明连接数已经满额，解决方法如下：

A.在可以登录的情况下，使用 client list 命令 查看当前链接的具体信息，信息中 idle 参数为空闲时长，如果大部分的连接空闲时长都超长，那么可以在线修改 timeout 参数，辅助释放长时间不用的空闲连接

B. 如果已经后台已经无法登录缓存节点，说明此时已无空闲连接可用，需要重启服务节点。

2)   备节点报错，无法从主节点同步数据

1.  优先检查主机内存、磁盘空间、网络带宽等基础信息，查看是否有资源不够的现象，资源不足的话可以选择性释放资源，例如硬盘不足，可以优先删除一些无用备份以及一些日志。

2.  然后删除备节点下 aof、rdb 文件，重启备节点，重新全量同步数据。

3)   节点报错，aof 文件或者 rdb 文件无法正常落盘，磁盘忙

1.  检查磁盘空间是否有空余

2.  监控磁盘 io，并检查 aof 或者 rdb 文件的大小，节点内存上限合理情况下，aof 文件不应该超过 6G。

解决方法如下：

A.磁盘无空余空间，优先选择性删除可删除的任何文件，其中包括一些数据备份文件，nmon 监控日志以及一些不重要的日志文件。

B.Aof 文件或者 rdb 文件超大，磁盘 io 始终处于超载状态，需要扩容增加当前集群的主节点数量，分摊数据，可以有效降低 aof 以及 rdb 文件大小，降低数据量大小后还可以增加数据恢复速度。

4)   错误 No route to host

检查防火墙是否开启，导致无法进行正常路由。

解决方法：/etc/init.d/iptables stop

5)   缓存在正常应用的状态下，丢失部分数据

检查每个服务节点的内存使用峰值，如果峰值已经与最大内存上限基本重合，那么就是缓存服务节点启用了内存超限的自我保护机制，把先内存中的数据淘汰然后存放新数据。

解决方法：

A.在线扩充单个节点的数据内存上限，如果单个服务节点的内存上限低于 5G，那么就临时上调 1G。

B. 在非忙时扩容增加主节点数量，分摊数据总量，降低单个服务节点的内存上限。

6)   集群有部分主节点槽位损坏，或者状态不正常导致无法使用

使用 cluster info 命令 查看所有槽位状态，有槽位处于不正常状态则说明有损坏。

解决方法：

执行 redis-trib.rb fix ip:port 来修复槽

7)   cluster nodes 时  槽出现错乱信息

解决方法：

执行 redis-trib.rb fix ip:port 来修复槽

8)   使用 ruby 用 redis-trib.rb rebalance --use-empty-masters ip:port 重新分配槽位时

报错信息：指定槽位无法 MIGRATE，此时该节点处于 fail 状态，槽位被锁定。

解决方法：

执行 CLUSTER SETSLOT 247(槽位号) STABLE 解除槽位分配状态，然后重新执行均衡命令。

缓存发现问题排查步骤

1.确认业务侧的报错，报错中出现 redis err 或者 jedis err 等字样则有可能是缓存系统出现问题。

2.登录主机，优先检查一下主机资源，包括内存剩余量、磁盘空间情况以及磁盘 io 使用情况等。

3.找到相关服务节点，查看日志迅速分析问题，有出现过的问题则根据问题解决预案，迅速解决。

4.临时解决问题后，发现整体主机整体资源不足时，提出集群迁移方案。

分布式缓存部署前提条件

1.    安装操作系统：centos，Red Hat EnterpriseServer64 位企业版本 6.5 以上。

2.    各个主机间需要完成 ssh 无密码访问。

3.    主机名由字母和数字组成，必须以字母开头，不允许有其他特殊字符。主机名可设置为 redis01、redis02 等。

4.    安装目录各个主机保持一致。

5.    分布式缓存客户端系统需要安装（the Oracle Java Development Kit(not OpenJDK),安装 jdk1.7.0_45 以上的版本。

6.    所有主机需要统一的用户名及密码。

7.    6*1024*1024/ulimit -c 65536

8.    系统安装 gcc v4.4.5 以上

9.    安装 ruby 维护工具

分布式缓存服务部署限制条件

1.  单节点内存最大上限 7G。

2.  单个主机的缓存服务节点个数（包括主备节点总数），不超过 cpu 总核数。

3.  对于数据量较大的、开启持久化的集群较多的主机，申请主机时应该申请固态盘，或者直接使用非本机的磁盘存储结构。

4.  有多套分布式缓存主机集群时，将写持久化的集群与不写持久化的缓存服务集群分散开部署，降低磁盘 io。

5.  分布式缓存服务部署时最少需要 3 台主机，生产环境无特殊需求，必须配备物理机（如果在任何情况下都完全允许一台主机宕机，则至需要 5 台主机）。

6.  部署分布式缓存服务的主机磁盘空间至少是内存上限的 3 倍。

7.  分布式缓存应用在生产环境时，原则上无特殊情况必须配备密码。

8.  主机数量较多时，应尽量分散在不同机柜（机柜总数大于 3），每个机柜的机器总数小于主机数量的 1/2，在设计部署方案时直接考虑机柜级别的容灾。

分布式缓存服务使用限制条件

1. 分布式缓存必须遵循 redis 的开发接口协议，redis 是 K/V 访问方式。

2. 分布式缓存集群服务不支持数据的批量操作接口，如：mset,mget 等。

3. JedisCluster 没有针对 byte[]的 API，需要自己扩展。

4. 业务在应用缓存服务时，不能开启大型延迟操作，类似 keys *，flushdb 等。

5. 业务在应用缓存服务时，做好数据管理工作，例如，对于会有使用期限的 key 做数据超期设置，以免数据会越写越大。

业务在应用缓存服务时，除 session 类可以通过重新登录重新获取的 K/V 外，其他业务都需要配备额外的全量数据源。