很多人觉得在小公司做开发太难了，不管是技术，还是硬件，都不配套，所以技术进阶，往大公司升迁，是必然的。

大公司跟中小公司的技术差距，只有体验过的人才知道。就拿商品详情页架构的要求来说吧，大中小公司就有不同的针对性的方案。

很多中小型的电商商品详情页，可能因为一分钟都没有一个访问，就谈不上什么并发设计，一个tomcat 就能搞定。

还有的公司虽然不大，但也有几十万日活，几百万用户，他们采取的方案可能是全局的一个静态页面。把商品详情页直接做成静态页面，每次全全量的更新，把数据全部静态放到nginx,里面，每次数据变化的时候，我们就通过一个Java服务去渲染这个数据，然后把这个静态页面推送到nginx服务器。

缺点也很明显：

1. 如果商品很多，那么渲染的时间会很长，达不到实时的效果。
2. 只能处理一些静态的东西，如果动态数据很多，比如有库存的，你不可能说每次去渲染，然后推送到nginx服务器，那不是更加慢？

再看一张图，这才是真正做到了高可用，高性能，高并发。

 

是不是瞬间秒了前面的操作。看图说话，分解一下步骤：

• 第一步是用户通过一个首页，进入到了首页，然后看到了一个商品，这个时候用户只能看到这个商品的部分信息对吧，那要看详细信息，那么得点进去，此时就是请求了一个url 。随便举个例子，就比如说：www.hqjy.com/goods/10086;
• 第二步，这个url，首先会经过lb lvs,然后到nginx集群，然后nginx 找到这个商品详情页的静态模板，然后里面有一个lua脚本，这个脚本可以去nginx本地去查看 id为 10086这个商品的动态数据，如果说这个10086商品没有nginx 缓存那么此时lua 就可以请求redis，如果说redis中也没有，就直接调用商品的缓存服务（tomcat）,然后商品服务查mysql es 等db 查到数据之后再缓存到redis，然后再缓存到nginx中，这样形成一个链路闭环。

优点看出来没？不用全量更新，并且做到n级缓存，可以做到高可用，高性能，高并发。

其实上面的商品详情页方案成功的关键在哪里呢？没错就是我们Redis的架构，你Redis的qps 每秒能到几十万，然后能到做数据的实时备份，并且保证服务的99.99%可用。

 

Redis这块，有些公司用的云服务，一般要是自己做的话，搭建一个企业级的怎么去考虑他的持久化方案，持久化的真实意义

其实这块就是Redis相关的知识，但是在高并发的场景Redis是必须的，对于Redis的用法，高可用、读写分离的架构，就是Redis是高并发的基石。

相比于传统关系型数据库磁盘读写的速度慢、并发低， Redis非关系型内存存储不可谓不彪悍。

支持异步持久化达到容灾：速度快、并发高。官方号称支持并发11万读操作，并发8万写操作。惊了吗？

支持数据结构丰富：string（字符串），list（链表），set（集合），zset（sorted set - 有序集合））和Hash（哈希类型）。惊了吗？

当前最热门的NoSql数据库之一,大公司都在用Redis实现高并发快速响应比如：微信点赞、收藏与标签基于Redis实现 ，微博与微信朋友关注模型基于Redis实现，以及电商业务的分布式锁，购物车等。

如果你对Redis的认知过于浅显的话，怎么可能通过得了面试，尤其是想要进入一线大厂的面试？

下面就给大家分享关于Redis的相关资料，都整理成PDF文档了，需要的可以后台私信【电子书】即可！

 

 

其他互联网面试题命中90%：

扫描下面二维码即可领取！

Redis还是Redis，碰上亿级流量别慌

原文：https://www.cnblogs.com/xiaogeng88/p/13031057.html