我们在上一篇文章里面详细讨论了缓存的架构方案，它可以减少数据库读操作的压力，却也存在着不足。比如写操作并发量大时，这个方案并不奏效，那该怎么办呢？我们先来看一个具体的业务场景。一、业务场景五有一个这样的场景：一场超低价预约大型线上活动，在某天9：00-9：15期间，用户可以前往预约详情页半价预约抢购一款热门商品。根据市场部门的策划方案，这次活动运营目标是几十万左右的预约量。面对如此之大的预约量，如何防止涌进来的请求压垮数据库？之前，公司给系统做个一次压测：并发量保持在8000左右时，系统响应速度最高

在前面的四篇文章中，我们从数据持久化层来聊了一些架构设计方案，来处理数据量大读写缓慢的问题。但是架构设计并不是只有这一方面的设计思路，本篇开始我们来从缓存层面来一起看看如何设计。一、业务场景四在一个电商系统中，存放了50000多条商品数据，每次用户浏览商品详情页时，需要先从数据库中读取数据，再进行数据拼装和计算，耗费的时间有时长达1秒。这就导致每次点击商品详情页时，页面打开速度慢，此时该如何减少数据库读操作的压力呢？在项目时间紧张，赶进度的时候，没更多的精力关注此类问题。但是当系统流量起来之后，这.