月饼网站建设,上海高新技术企业名单查询,怎么学wordpress,企业网站开发需要大数据时代 Memcached 经典问题
随着互联网的快速发展和普及#xff0c;人类进入了大数据时代。在大数据时代#xff0c;移动设备全面融入了人们的工作和生活#xff0c;各种数据以前所未有的 速度被生产、挖掘和消费。移动互联网系统也不断演进和发展#xff0c;存储、计…大数据时代 Memcached 经典问题
随着互联网的快速发展和普及人类进入了大数据时代。在大数据时代移动设备全面融入了人们的工作和生活各种数据以前所未有的 速度被生产、挖掘和消费。移动互联网系统也不断演进和发展存储、计算和分析这些海量数据以满足用户的需要。在大数据时代大中型互联网系统具有如下特点。 首先系统存储的数据量巨大比如微博系统每日有数亿条记录历史数据达百亿甚至千亿条记录。 其次用户多访问量巨大每日峰值流量高达百万级 QPS。 要存储百千亿级的海量数据同时满足大量用户的高并发访问互联网系统需要部署较多的服务实例不少大中型互联网系统需要部署万级甚至十万级的服务实例。 再次由于大数据时代社会信息获取扁平化热点事件、突发事件很容易瞬间引爆引来大量场外用户集中关注从而形成流量洪峰。 最后任何硬件资源都有发生故障的概率而且存在 4 年故障效应即服务资源在使用 4 年后出现故障的概率会陡增由于大中型互联网系统的部署需要使用大量的服务器、路由器和交换机同时部署在多个地区的不同 IDC很多服务资源的使用时间远超 4 年局部出现硬件故障障、网络访问异常就比较常见了。
由于互联网系统会大量使用 Memcached 作为缓存而在使用 Memcached 的过程中同样也会受到前面所说的系统特点的影响从而产生特有的经典问题。
容量问题
第一个问题是容量问题。Memcached 在使用中除了存储数据占用内存外连接的读写缓冲、哈希表分配、辅助线程处理、进程运行等都会占用内存空间而且操作系统本身也会占用不少内存为了确保 Mc 的稳定运行Mc 的内存设置一般设为物理内存的 80%。另外设置的内存也不完全是存储有效数据我上一节课讲到每个 Item 数据存储在 chunk 时会有部分字节浪费另外 key 在过期、失效后不是立即删除而是采用延迟淘汰、异步 LRU 队尾扫描的方式清理这些暂时没有淘汰的、过期失效的 key 也会占用不少的存储空间。当前大数据时代互联网系统中的很多核心业务需要缓存的热数据在 300~500GB 以上远远超过单机物理内存的容量。
性能瓶颈
第二个问题是性能瓶颈问题。出于系统稳定性考虑线上 Mc 的访问最大 QPS 要在 10~20w 以下超过则可能会出现慢查的问题。而对中大型互联网系统核心业务的缓存请求高达百万级 QPS仅仅靠简单部署单个物理机、单个资源池很难达到线上的业务要求。
连接瓶颈
第三个问题是连接瓶颈的问题。出于稳定性考虑线上 Mc 的连接数要控制在 10w 以下。以避免连接数过多导致连接占用大量内存从而出现命中率下降、甚至慢查超时的问题。对于大中型系统线上实例高达万级、甚至十万级单个实例的最小、最大连接数一般设置在 5~60 个之间。业务实例的连接数远超过单个机器的稳定支撑范围。
硬件资源局部故障
第四个问题是硬件资源局部故障导致的缓存体系的可用性问题。由于任何硬件资源都有一定故障概率而且在使用 4 年后故障率陡增。对于数以万计的硬件设备随时都有可能出现机器故障从而导致 Mc 节点访问性能下降、宕机海量访问穿透到 DB引发 DB 过载最终导致整个系统无法访问引发雪崩现象。
流量洪峰下快速扩展
第五个问题是在流量洪峰的场景下如何快速扩展的问题。大数据时代由于信息扩散的扁平化突发事件、重大活动发生时海量用户同时蜂拥而至短时间引发巨大流量。整个系统的访问量相比日常峰值增大 70% 以上同时出现大量的极热 key 的访问这些极热 key 所在的 Mc 节点访问量相比日常高峰增大 2~3 倍以上很容易出现 CPU 飙升、带宽打满、机器负荷严重过载的现象。
Memchcaed 经典问题及应对方案
为了解决大中型互联网系统在使用 Mc 时的这些问题。我们可以使用下面的解决方案。
Memcached 分拆缓存池
首先对系统内的核心业务数据进行分拆让访问量大的数据使用独立的缓存池。同时每个缓存池 4~8 个节点这样就可以支撑足够大的容量还避免单个缓存节点压力过大。对于缓存池的分布策略可以采用一致性哈希分布和哈希取模分布。
一致性哈希分布算法中首先计算 Mc 服务节点的哈希值然后将其持续分散配置在圆中这样每个缓存节点实际包括大量大小各异的 N 个 hash 点。如下图所示在数据存储或请求时对 key 采用相同的 hash 算法并映射到前面的那个圆中从映射位置顺时针查找找到的第一个 Mc 节点就是目标存取节点。 而哈希取模分布算法则比较简单对 key 做 hash 后对 Mc 节点数取模即可找到待存取的目标 Mc 节点。
系统运行过程中Mc 节点故障不可避免有时候甚至短期内出现多次故障。在 Mc 节点故障下线后如果采用一致性 hash 分布可以方便得通过 rehash 策略将该 Mc 节点的 hash 点、访问量均匀分散到其他 Mc 节点。如果采用取模分布则会直接导致 1/N 的访问 missN 是 Mc 资源池的节点数。
因此对于单层 Mc 缓存架构一致性 hash 分布配合 rehash 策略是一个更佳的方案。通过将业务数据分拆到独立 Mc 资源池同时在每个资源池采用合适的分布算法可以很好的解决 Mc 使用中容量问题、性能瓶颈问题以及连接瓶颈问题。
Master-Slave 两级架构
在系统的访问量比较大比如峰值 QPS 达到 20w 以上时如果缓存节点故障即便采用一致性 hash也会在一段时间内给 DB 造成足够大的压力导致大量慢查询和访问超时的问题。另外如果某些缓存服务器短期多次故障反复上下线多次 rehash 还会产生脏数据。对此可以采用 Master-Slave 的两级架构方案。
在这种架构方案下将业务正常访问的 Memcached 缓存池作为 master然后在 master 之后再加一个slave 资源池作 master 的热备份。slave 资源池也用 6~8 个节点内存设置只用 master 的 1/2~1/3 即可。因为 slave 的应用主要是考虑在 master 访问 miss 或异常时Mc 缓存池整体的命中率不会过度下降所以并不需要设置太大内存。
日常访问对于读操作直接访问 master如果访问 miss再访问 slave。如果 slave 命中就将读取到的 key 回写到 master。对于写操作set、touch 等覆盖类指令直接更新master 和 slave而 cas、append 等以 master 为准master 在 cas、add 成功后再将 key 直接 set 到 slave以保持 master、slave 的数据一致性。
如下图在 master 部分节点异常后由 slave 层来承接。任何一层部分节点的异常不会影响整体缓存的命中率、请求耗时等 SLA 指标。同时分布方式采用哈希取模方案mc 节点异常不rehash直接穿透方案简洁还可以避免一致性 hash 在 rehash 后产生的脏数据问题。 Master-Slave 架构在访问量比较大的场景下可以很好得解决局部设备故障的问题。在部分节点异常或访问 miss 时多消耗 1ms 左右的时间访问 slave 资源实现以时间换系统整体可用性的目的。
M-S-L1 架构
20世纪初意大利统计学家帕累托提出来一个观点在任何特定群体中重要的因子通常只占少数而不重要的因子则占多数因此只要能控制具有重要性的少数因子即能控制全局。这个理论经过多年演化就成为当前大家所熟悉的 80/20 定律。80/20 定律在互联网系统中也广泛存在如 80% 的用户访问会集中在系统 20% 的功能上80% 的请求会集中在 20% 的数据上。因此互联网系统的数据有明显的冷热区分而且这个冷热程度往往比 80/20 更大比如微博、微信最近一天的数据被访问的特别频繁而一周前的数据就很少被访问了。而且最近几天的热数据中部分 feed 信息会被大量传播和交互比其他 大部分数据的访问量要高很多倍形成明显的头部请求。
头部请求会导致日常大量访问被集中在其中一小部分 key 上。同时在突发新闻、重大事件发生时请求量短期增加 50~70% 以上而这些请求又集中在 突发事件的关联 key 上造就大量的热 key 的出现。热 key 具有随机性如果集中在某少数几个节点就会导致这 些节点的压力陡增数倍负荷严重过载进而引发大量查询变慢超时的问题。
为了应对日常峰值的热数据访问特别是在应对突发事件时洪峰流量带来的极热数据访问我们可以通过增加 L1 层来解决。如下图所示L1 层包含 2~6 组 L1 资源池每个 L1 资源池用 4~6 个节点但内存容量只要 Master 的 1/10 左右即可。 如图读请求时首先随机选择一个 L1 进行读取如果 miss 则访问 master如果 master 也 miss最后访问 slave。中途只要任何一层命中则对上一层资源池进行回写。
写请求时同 Master-Slave 架构类似对于 set 覆盖类指令直接 set 三层所有的资源池。对于 add/cas/append 等操作以 master 为准master 操作成功后将最后的 key/value set 到 L1 和 slave 层所有资源池。
由于 L1 的内存只有 master 的 1/10且 L1 优先被读取所以 L1 中 Memcached 只会保留最热的 key因为 key 一旦稍微变冷就会排到 COLD LRU 队尾并最终被剔除。虽然 L1 的内存小但由于 L1 里永远只保存了 系统访问量 最大最热的数据根据我们的统计 L1 可以满足整个系统的 60~80% 以上的请求数据。这也与 80/20 原则相符合。
master 存放全量的热数据用于满足 L1 读取 miss 或异常后的访问流量。slave 用来存放绝大部分的热数据而且与 master 存在一定的差异用来满足 L1、master 读取 miss 或异常的访问流量。
这里面有个可以进一步优化的地方即为确保 master、slave 的热度让 master、slave 也尽可能只保留最热的那部分数据可以在读取 L1 时保留适当的概率直接读取 master 或slave让最热的 key 被访问到从而不会被 master、slave 剔除。此时访问路径需要稍做调整即如果首先访问了 master如果 miss接下来只访问 slave。而如果首先访问了 slave如果 miss接下来只访问 master。
通过 Master-Slave-L1 架构在流量洪峰到来之际我们可以用很少的资源快速部署多组L1资源池然后加入 L1 层中从而让整个系统的抗峰能力达到 N 倍的提升。从而以最简洁的办法快速应对流量洪峰把极热 key 分散到 N 组 L1 中每个 L1 资源池只用负责 1/N 的请求。除了抗峰另外还可以轻松应对局部故障避免雪崩的发生。
本课时讲解了大数据时代下大中型互联网系统的特点访问 Memcached 缓存时的经典问题及应对方案还讲解了如何通过分拆缓存池、Master-Slave 双层架构来解决 Memcached 的容量问题、性能瓶颈、连接瓶颈、局部故障的问题以及 Master-Slave-L1 三层架构通过多层、多副本 Memcached 体系来更好得解决突发洪峰流量和局部故障的问题。
可以参考下面的思维导图对这些知识点进行回顾和梳理。
