商品详情页系统架构-笔记4-商品详情页多级缓存

目录

redis在实践中的一些常见问题以及优化思路

阶段性总结

电商系统中的商品详情页多级缓存

---

redis在实践中的一些常见问题以及优化思路

（1）fork耗时导致高并发请求耗时

方案：一般redis内存控制在10G以内

（2）AOF阻塞问题

为什么阻塞：redis写入数据AOF缓冲区，会单独开一个线程fsync，每秒一次。但是Redis 会检查两次的fsync时间，距离上一次fsync超过2秒会写阻塞。

方案：采用SSD硬盘

（3）主从复制延迟

在info replication中看offset,看差值，如果有延迟报警

（4）主从复制风暴

master-slave星形改为树状结构

星形：

树状：

（5）Linux 命令 设置保障

vm.overcommit-memory :

0:没有足够的内存事保

1：内存用完位置

2：内存空间不能超过swap+50%

（6）swapness 

Linux 内核版本 <3.5   swapness =0    

Linux 内核版本 >= 3.5swapness =1

 

阶段性总结

单机：

数据不大

replication(哨兵)：

数据10G以内，写QPS几万，读QPS十万，基本99.99%，slave可以扩展。

redis cluster:

国内排前三的 XX宝、X东、X宁。QPS几十万。数据在1T以上，QPS几十万。

    

电商系统中的商品详情页多级缓存

（1）用的是三级缓存：nginx本地缓存+redis分布式缓存+tomcat堆缓存的多级缓存架构

（2）时效性要求高：库存

时效性要求低：商品的基本信息（名称、颜色、版本、规格参数，等等）

（3）多级缓存架构中每一层的意义

nginx本地缓存 

抗的是热数据的高并发访问，一般来说，商品的购买总是有热点的（大量热点数据），比如每天购买iphone、nike、海尔等知名品牌的东西的人，总是比较多的

这些热数据，利用nginx本地缓存，由于经常被访问，所以可以被锁定在nginx的本地缓存内。

redis分布式大规模缓存

抗的是很高的离散访问，支撑海量的数据，高并发的访问，高可用的服务

tomcat jvm堆内存缓存

抗redis大规模灾难的，如果redis出现了大规模的宕机，导致nginx大量流量直接涌入数据生产服务，那么最后的tomcat堆内存缓存至少可以再抗一下，不至于让数据库直接裸奔

同时tomcat jvm堆内存缓存，也可以抗住redis没有cache住的最后那少量的部分缓存

三层的架构如下：