用Redis做缓存，购物车响应速度能快多少你知道吗？

“用Redis做缓存，购物车响应速度能快多少你知道吗？”这个问题的答案，其实没有一个固定的数字，快10倍”或“快100倍”，因为快多少取决于你原来用的技术有多慢，我可以告诉你，这种速度的提升是数量级的，是从“能感觉到卡顿”到“几乎无感”的质变，这就好比把你从骑自行车上下班，换成了乘坐高铁,速度的提升是颠覆性的。

要理解为什么能这么快，我们得先看看不用Redis的时候，购物车是怎么工作的，根据京东和淘宝等大型电商平台公开的技术分享，在早期或者一些传统架构的网站中，用户把商品加入购物车或者查看购物车时，应用程序会直接去查询后台的关系型数据库，比如MySQL，每一次点击“加入购物车”按钮，服务器就需要执行一次数据库的“写入”操作；每一次刷新购物车页面，就需要执行一次“读取”操作，数据库要把这些数据安全地写入硬盘，确保不会丢失，这个读写硬盘的过程，相对于直接操作内存来说，是非常慢的，当同时有成千上万的用户都在进行加入购物车、查看购物车的操作时，数据库就会不堪重负，成为整个系统的“瓶颈”，用户就会明显感觉到页面加载转圈圈，点击按钮后要等一会儿才有反应,体验非常差。

Redis是如何解决这个问题的呢？根据Redis官方网站的介绍，它的核心原理非常简单粗暴：把所有数据都放在服务器的内存里，内存的读写速度，比硬盘要快几个数量级，有技术资料做过类比，从内存中读取数据可能只需要100纳秒，而从机械硬盘读取则需要10毫秒，这中间差了十万倍！虽然实际应用中因为网络传输等因素不会达到这么极致的差距,但性能的提升依然是惊人的。

具体到购物车这个场景，当引入Redis作为缓存层后，流程就变成了这样：用户第一次操作购物车时，数据还是会写入数据库以保证持久化，但更重要的是，它会同时被写入Redis的内存中，之后，当这个用户再次查看购物车，或者继续添加商品时，应用程序就不再需要去麻烦速度慢的数据库了，而是直接向速度极快的Redis请求数据，因为Redis是内存数据库，这个响应速度是微秒级别的，对于用户来说，点击“加入购物车”按钮，商品几乎是瞬间就出现在了侧边栏的购物车里，没有任何延迟感，查看购物车列表也是一样,页面瞬间就加载完成了。

除了纯粹的内存速度优势，Redis本身的数据结构也非常适合存储购物车信息，根据Redis的命令文档，它可以用Hash这种结构来完美模拟一个购物车，一个用户的购物车就是一个Hash，商品ID是字段名，购买数量是字段值，这样的结构使得对某个商品进行增、删、改、查数量等操作都非常高效,几乎也是瞬间完成。

像天猫这样的电商网站在技术文章中提及，面对“双十一”这种海量并发的情况，Redis还可以通过搭建“集群”的方式，将数据分布到多台服务器的内存中，从而轻松应对数千万甚至上亿用户的同时访问,这是传统数据库很难直接做到的。

为了确保数据安全，Redis也会通过一些机制定期将内存中的数据备份到硬盘上，但这通常是在后台异步完成的,不会影响前端的读写速度。

回到最初的问题：“用Redis做缓存，购物车响应速度能快多少？” 虽然无法给出一个精确的毫秒数，但我们可以肯定地说，它能将响应时间从几百毫秒甚至秒级（用户可感知的延迟），降低到几毫秒甚至亚毫秒级（用户无法感知的即时响应），这种提升，对于提升用户体验、增加用户粘性、最终促进交易转化率来说，是至关重要的，在当今这个用户耐心极其有限的时代，快那么一点点,可能就是留住用户和失去用户的区别。