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