场景十二:从电商架构演进看互联网高可用架构设计--数据缓存架构
分布式数据架构
缓存为王的世界,流量峰值比较明显,要考虑系统对峰值流量的承载能力,也就是系统的可伸缩性。如果按照峰值设计,那么系统在90%的情况下是浪费的,如何设计良好的架构既能满足峰值需求又不浪费资源,这就是伸缩性,而缓存又是伸缩性中一个重要技能。
image.png
缓存类型
CDN:静态缓存
分布式缓存:redis等
本地缓存:如JVM
把静态资源放在离用户最近的地方,用户体验最好。需要进行计算的资源需要放在离cpu最近的地方,性能最好。
image.png
分布式缓存
memcache
以内存作为缓存区,每个进程最大为2G
缓存策略:最近最少使用,每条数据必须有过期时间
各个memcache不共享、不通信
内存管理模式,不存硬盘。
性能很高。
可作为热点缓存使用。
image.png
redis
基于内存、多数据结构存储系统,可用作数据库、缓存、消息中间件。
image.png
redis复制原理
基于内存快照。
需要谨慎使用,尤其是数据量较大时,复制的性能波动是比较大的。
image.png
image.png image.png
几种常见的分片策略
客户端分片技术。
image.png
按照指定维度取模
image.png一致性哈希进行分片
缺点:节点较少时,分布不均衡。
通过虚节点的机制改进均衡性,一个真实节点对应多个虚节点,虚节点均衡的放到环上。
image.png image.png
Redis与Memcache比较
网络IO模型
memcache多线程、非阻塞IO复用的网络模型。
Redis单线程IO复用模型。
都是基于事件处理机制的框架。
Redis的性能表现略优于Memcache。
memcache需要同时满足两个条件,有峰值流量处理不均匀、并且业务处理流程耗时较大。如果业务处理流程仅仅是单纯的io操作时,线程切换会消耗性能成本较高。
image.png
image.png image.png
内存管理方面
Memcache预分配内存,缺点空间浪费。
Redis现场申请内存的方式来存储数据,缺点会有内存碎片 。
image.png
存储方式及其他方面
image.png关于不同语言的客户端支持
image.png总结
image.png购物车使用Redis最佳实践讲解分析
购物车特点:1流量大、2峰值明显、3数据量大
Redis作为内存DB使用,无持久化
(购物车数据对数据安全性要求不高,极端情况下购物车丢一条数据相对可以接受的。性能要求比较高,持久化会影响性能。使用用户维度作为分片,无主从,全量内存。)
主备(备库只做热备)采用双写(避免主从复制问题),同步写主异步写备(最终一致性),主出问题备顶上(有损设计
(单节点断点的应对方案,增加1:1的双主结构同步双写,读的时候只读内存节点,外层节点作为备份,外层节点做持久化。内层节点断点,自动切换到外层节点)
存储结构,登录用户使用cookie+pin作为key,非登录用户使用cookie作为key
部署结构,双机房两套一样的Redis集群(双环)
就近读写、异步同步
大数据分析时一定不要读线上的数据库、缓存等。
作业:
Body结构应该怎么去设计?list?set?
本地缓存
应用内部的缓存,不需要走网络,性能非常快。标准的分布式系统,一般与多级缓存构成,本地缓存是离应用最近的缓存,一般可以将数据缓存到硬盘活内存。
硬盘:批量
内存:随机
image.png
缓存冗余如何设计?
系统一般由多级缓存构成,数据多层冗余
image.png
举例:我的足迹
image.png微服务架构缓存一致性如何保证?
image.png任何一次修改保证数据一致性?最终一致性的保证
分布式事务(DTS)
主从同步
异步消息通知
定向轮询更新
image.png
多次数据修改的一致性?分布式锁服务
image.png常用算法
image.png
实现方式
image.png
Zookeeper实现分布式锁服务
zookeeper 树形结构,解决分布式一致性的产品。
临时顺序节点
image.png
乐观锁实现
image.png微服务架构缓存命中率如何保证
image.pngimage.png
案例一:商家中心
最佳实践-商家中心(300W/分钟调用)
场景特点决定架构设计
峰值明显
核心业务要求TP999,SLA 5ms
双机房双活 多级监控 动态降级 三级缓存
Redis集群全量缓存(20ms)+本地Redis 热点缓存(1小时有效期)(从20ms降到12ms)+应用内JVM缓存(缓存时间1分钟)(从12ms降到3ms)
image.png
部署情况
image.png案例2
最佳实践-10亿海量商品sku存储
特点:
数据量大
实时性较高
数据比较频繁
中心访问量比较大,日均2亿,峰值平稳
网友评论