4.7 小结

以上方案可以顺利解决读数据请求压垮数据库的问题，目前互联网架构也基本是采取这个方案。

分布式缓存系统上线后，商品详情页的大部分数据存到了Redis中，并且一些数据的读取改为异步请求，优化效果非常明显：打开详情页基本只需要1秒；而后台监控这个详情页的API（从缓存中取数据的那个API），平均响应时长变为10毫秒以内；监控数据中，从首页到搜索再到详情页的平均时长变成了4秒左右，这个改善幅度还是很大的。

IT部门在当时一次例会中讨论最近的工作亮点，有人问道：“咱们要不要提一下这个缓存方案？它对业务的帮助很大。”另一个同事就说：“可是缓存这个技术很普通，万一被问到，这个方案有什么创新的地方，我们要怎么回答？”然后大家都沉默了。

但是后来还是把这个方案放到了部门汇报内容里，只写了一句话：“利用缓存技术和异步加载技术将商品详情页的平均响应时间从十几秒缩短到1秒。”这在会议上并没有引起什么反响，只是后来有一次聚餐时，CEO也在场，他说过这样的话：“其实我们不要老是追求新技术，能帮到业务的技术就是好技术。”CTO就接话说：“比如上次你们把商品详情页的打开时间大幅度缩短了，这就是好事，这种好事以后多做。”

接下来说说不足吧。

这个方案主要针对读数据请求量大的情况，或者读数据响应时间很长的情况，而不能应对写数据请求量大的场景。也就是说写请求多时，数据库还是会支撑不住。针对这个问题，下一章会给出对应的解决方案。